As posted on the mailing list [1], I'm running arch linux x64 and PA8.0. I have - an ALC889 codec - running output:analog-surround-71+input:analog-stereo profile - the 7.1 output is actually a sink-remap to 5.1+2.0 When I plug in my headphones to the front panel, PA correctly switches to headphones. However, restarting the PC with the headphones plugged in result in the analog-surround profile being used instead, and no sound being played on any output. Re-plugging the headphones switches the output correctly again. [1] https://lists.freedesktop.org/archives/pulseaudio-discuss/2016-March/025874.html
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda/hda_codec.c#n3794 for (i = 0; i < ARRAY_SIZE(mout->hp_out_nid); i++) if (!mout->no_share_stream && mout->hp_out_nid[i]) snd_hda_codec_setup_stream(codec, mout->hp_out_nid[i], stream_tag, 0, format); hda-intel only copy front channels to headphone when using multichannel pulseaudio expect headphone use stereo and it should disallow you to select surround when headphone is plugged
(In reply to Raymond from comment #1) > pulseaudio expect headphone use stereo and it should disallow you to select > surround when headphone is plugged module-card-restore will blindly restore the last manually-selected profile. Before that can be fixed, module-alsa-card has to fill in the profile availability information, which it currently doesn't do. I submitted patches some time ago that mark profiles unavailable when all of the ports in the profile are unavailable, but that doesn't help with this bug, because "output:analog-surround-71+input:analog-stereo" has also the input part, which probably is available. I plan to fix this in v10, if nobody else fixes this in time for v9 (I don't target v9 myself, because I'm busy with other fixes, and I don't think this is a regression, so this doesn't warrant a release blocker status).
(In reply to Tanu Kaskinen from comment #2) > (In reply to Raymond from comment #1) > > pulseaudio expect headphone use stereo and it should disallow you to select > > surround when headphone is plugged > > module-card-restore will blindly restore the last manually-selected profile. > Before that can be fixed, module-alsa-card has to fill in the profile > availability information, which it currently doesn't do. I submitted patches > some time ago that mark profiles unavailable when all of the ports in the > profile are unavailable, but that doesn't help with this bug, because > "output:analog-surround-71+input:analog-stereo" has also the input part, > which probably is available. > For those with three jacks at rear panekl, rear mic and line in jacks are already retasked for surround output, this is another bug
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documentation/sound/alsa/HD-Audio-Controls.txt Channel Mode This is an enum control to change the surround-channel setup, appears only when the surround channels are available. It gives the number of channels to be used, "2ch", "4ch", "6ch", and "8ch". According to the configuration, this also controls the jack-retasking of multi-I/O jacks. The defaut channel mode is 2ch, need hook for surround devices to change channel mode
slave.pcm { type hooks slave.pcm { type hw card $CARD } hooks.0 { type ctl_elems hook_args [ { name "Channel Mode" preserve true value "6ch" lock true optional true }
> the 7.1 output is actually a sink-remap to 5.1+2.0 you have to post output of alsa-info.sh http://www.intel.com/content/www/us/en/support/boards-and-kits/desktop-boards/000006687.html for three jacks at rear panel to support 7.1 , you need to retask HP jack as side line out jack for five jacks at rear panel, you need to retask blue line in jack to side jacks
Mine is a 6 jack one, though: green+black+orange+grey+blue+pink, so it's "native" 7.1
Created attachment 122582 [details] output of alsa-info.sh
Created attachment 122583 [details] user default.pa with sink-remap config
what is the purpose of remapping since you can enable multistreaming by early patching using indep_hp=1 https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documentation/sound/alsa/HD-Audio.txt or retask your grey line out/mic jack as another headphone jack http://www.intel.com/content/www/us/en/support/boards-and-kits/desktop-boards/000007156.html
Independent HP When this enum control is enabled, the headphone output is routed from an individual stream (the third PCM such as hw:0,2) instead of the primary stream.
hda-intel already copy front channel to grey jack when playing 5.1 /* surrounds */ for (i = 1; i < mout->num_dacs; i++) { if (chs >= (i + 1) * 2) /* independent out */ snd_hda_codec_setup_stream(codec, nids[i], stream_tag, i * 2, format); else if (!mout->no_share_stream) /* copy front */ snd_hda_codec_setup_stream(codec, nids[i], stream_tag, 0, format); }
The remapping is used to have a 5.1 headset connected at the rear, the 2.0 speakers connected at the rear and a 2.0 headset connected at the front. sink-remap seemed as the easiest way to do it, or rather, the only example of jack retasking on linux I was able to find at that point. I didn't know that the grey jack would function as headphones in 5.1 mode, last time I tried the output was silent (which was quite a while ago). Just tested it and it seems to work the same as my sink-remap setup, meaning leaving the headphones plugged at the front and restarting produces no sound at any output until I re-plug the headphones. The goal with remapping was also me hoping to completely separate the virtual 5.1 and 2.0 devices, so that playing music on one of them would leave the other silent. But that doesn't seem to be possible wiht pulseaudio, at least I got no reply to my mail some months ago. In any case, the misbehavior exists even without retasking.
Not all jacks at rear panel have HP amp Pincap 0x0000373c: IN OUT HP Detect for alc889, omly green, blue, black, pink jacks at rear and those jacks ar front panel
Grey and orange jack does not have HP amp, so you need to use the rear mic or line in
That's good to know, thanks. The 5.1 headset is connected to green+black+orange, the stereo amplifier is connected to the grey jack. The stereo headset is connected to the green front jack. I don't see how that's related to the issue, though?
You have to give up grey jack and retask it as not connected so that the dac and volume control can be used by your retasked hp jack
I think we got sidetracked, this report is about pulseaudio not restoring front panel connection when the card is set to any surround profile by default. I'll post the retasking issue to the mailing list in a bit.
How do pulseaudio controls (e.g. volume, balance, bass and fade) does not allow you to change volume of 7.1 channels?
snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC889: line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x1b/0x0/0x0/0x0/0x0) snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 snd_hda_codec_realtek hdaudioC0D0: dig-out=0x11/0x1e snd_hda_codec_realtek hdaudioC0D0: inputs: snd_hda_codec_realtek hdaudioC0D0: Front Mic=0x19 snd_hda_codec_realtek hdaudioC0D0: Rear Mic=0x18 snd_hda_codec_realtek hdaudioC0D0: Line=0x1a Do the model speaker, dock line out and headphone meet your requirement?
The alternative is to retask your grey jack as internal speaker (this is similar to those thinkcentre )
(In reply to Tanu Kaskinen from comment #2) > (In reply to Raymond from comment #1) > > pulseaudio expect headphone use stereo and it should disallow you to select > > surround when headphone is plugged > > module-card-restore will blindly restore the last manually-selected profile. > Before that can be fixed, module-alsa-card has to fill in the profile > availability information, which it currently doesn't do. I submitted patches > some time ago that mark profiles unavailable when all of the ports in the > profile are unavailable, but that doesn't help with this bug, because > "output:analog-surround-71+input:analog-stereo" has also the input part, > which probably is available. > > I plan to fix this in v10, if nobody else fixes this in time for v9 (I don't > target v9 myself, because I'm busy with other fixes, and I don't think this > is a regression, so this doesn't warrant a release blocker status). It seems it was not fixed in v9, how likely is it going to make it into v10?
Oh dear, has half a year already passed since I made my promises? (In reply to chrno-sphered from comment #22) > It seems it was not fixed in v9, how likely is it going to make it into v10? Not likely at all. New very-high priority bugs have cropped up, and I'm busy fixing those so that we can get v10 out. I still plan to fix this after the critical issues get sorted out, but it's hard to promise anything since the situation is pretty much the same as six months ago.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/286.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.