I'm not totally sure it's a bug, but I think it's an issue we should take care of. I use the Intel NUC - https://www.intel.com/content/www/us/en/products/boards-kits/nuc.html The problem is this: If I have a headphones set connected to my PC, and I start PulseAudio, I can see 2 sinks which represent: 1. HDMI speakers. 2. The headphones analog output. In contrast, if I already started PulseAudio and I have no sinks but the HDMI, connecting the analog headphones doesn't bring up a new sink for PulseAudio. I would like to be able to add new hardware sinks during runtime. In contrast, the Bluetooth module does bring up a new sink during runtime when there is a newly Bluetooth headset connected to the machine. I Hope someone could tell me what I'm doing wrong or what settings I should change.
This is something that should work just fine. Can you attach the output of "pactl list" (as attachments, not in the comment field) in both cases (i.e. when there are two sinks and when there's only the HDMI sink)?
Here are 4 links to gists of the output of `pactl list` in 4 different modes: - When 1 sink only is connected and no 2nd sink is plugged in: https://gist.github.com/6d79ebda990c3f7ef97abb1a9366624b - When 1 sink only is connected and there is a 2nd sink connected but it doesn't being detected by pulseaudio (as already explained): https://gist.github.com/48526c3bb48749c62aecae2a77d534a4 - When 2 sinks are connected and both active: https://gist.github.com/58c6934571a7a98cdba6e4c42d79571b - When 2 sinks are connected and 1 of them is disconnected: https://gist.github.com/a3e30ae68b8cc6ab18339e27b67a51cc
If you run "amixer -c1 controls | grep Jack", you should get output that looks a bit like this (this is from my own laptop): numid=21,iface=CARD,name='Dock Headphone Jack' numid=19,iface=CARD,name='Dock Mic Jack' numid=22,iface=CARD,name='Headphone Jack' numid=18,iface=CARD,name='Internal Mic Phantom Jack' numid=17,iface=CARD,name='Mic Jack' numid=23,iface=CARD,name='SPDIF Phantom Jack' numid=20,iface=CARD,name='Speaker Phantom Jack' Put the machine in the state where you have the headphones plugged in, but pulseaudio isn't detecting them. Then, for each line in your amixer output, run this command: amixer -c1 cget LINE (replace LINE with the line contents in question) Alsa might not be reporting the jack status correctly. These commands should show what state the jacks have according to alsa.
I've ran the following in my shell: ``` $ for i in `amixer -c1 controls | grep Jack`; do amixer -c1 cget "$i" done ``` And the output was: ``` numid=10,iface=CARD,name='Headphone Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on numid=9,iface=CARD,name='Mic Jack' ; type=BOOLEAN,access=r-------,values=1 : values=on ```
"values=on" means "plugged in", so alsa should be reporting the jack state correctly. By the way, do you have a headset instead of plain headphones? The microphone status seems to be changing too when you plug in your headphones. Can you attach a verbose log from pulseaudio? Start pulseaudio without the headphones plugged in, and then plug them in, and then stop pulseaudio. More detailed instructions for getting the log: First, disable automatic starting of pulseaudio. There are two ways to do this, depending on the distribution. First one uses systemd: systemctl --user stop pulseaudio.socket Other distributions use pulseaudio's own autospawning mechanism. To disable, write this to ~/.config/pulse/client.conf (if the file doesn't exist, create it): autospawn = no Then, stop the running instance: "killall pulseaudio" Then, start pulseaudio: pulseaudio -vv --log-target=file:/tmp/log.txt Then, plug in the headphones and stop pulseaudio with ctrl-C. Finally, you can restore the automatic starting by removing the "autospawn = no" line from client.conf or by running "systemctl --user start pulseaudio.socket".
Created attachment 133094 [details] verbose output for pulseaudio while plugging in undetected headset.
BTW, I have a combined headset and microphone jack like in mobile devices in my PC, and so are my headphones.
The log shows that pulseaudio is detecting the headset, unlike what was indicated in the "pactl list" output. The card profile doesn't seem to get automatically changed, though, so that's still in line with your original problem description. Can you re-check the "pactl list" output (or "pactl list cards" - that prints less uninteresting stuff) after you've plugged in the headset? The interesting part is this: Ports: analog-input-mic: Microphone (priority: 8700, latency offset: 0 usec, not available) Properties: device.icon_name = "audio-input-microphone" Part of profile(s): input:analog-stereo, output:analog-stereo+input:analog-stereo analog-output-headphones: Headphones (priority: 9000, latency offset: 0 usec, not available) Properties: device.icon_name = "audio-headphones" Part of profile(s): output:analog-stereo, output:analog-stereo+input:analog-stereo The "not available" text means that pulseaudio thinks that the headset is not plugged in. I'll try to reproduce this myself (I need to hack the configuration first to make my hardware look more like yours). It looks like the automatic profile changing logic isn't working quite as it should.
I was able to reproduce the bug. I also submitted a fix: https://patchwork.freedesktop.org/patch/169545/
Is the fix to this issue (https://patchwork.freedesktop.org/patch/169545/) was supposed to appear in the release of version 11.1 released on September? I've just installed pulseaudio from my official repositories (Arch Linux - https://www.archlinux.org/packages/extra/x86_64/pulseaudio/) in order to check the status of it and I don't see the issue solved. Perhaps it's a problem in downstream?
The fix was not in 11.1, so you'll have to wait for 12.0 (which will be released hopefully within a month or so).
OK, Thanks a lot :)
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.