sof-hda-dsp: Reverse order and priority of headset and headphone mic #21
Conversation
Headset mic is the analog input source in 99% of the cases compared to headphone mic, so change it's priority higher. Jaska Uimonen <jaska.uimonen@linux.intel.com>
|
@perexg I don't see effect in ubuntu UI with just changing the CapturePriorities, the UI is taking the 1st on the list (I assume). That's why I also flipped around the two mic definitions... The headset mic is much much more common than stereo analog mic. |
|
If it's gnome, you're probably hit this: https://gitlab.gnome.org/GNOME/libgnome-volume-control/-/merge_requests/10 I don't want to modify the configuration just because a tool in the chain is not ready. Headset has already higher priority than Mic2, thus it should be preferred. |
|
@perexg so in pulseaudio smaller value means higher prio or vice versa? And agree that priority should be obeyed... |
|
Higher value means higher priority. In UCM the Headset device has priority 300, Mic2 has priority 200, thus Headset should be selected when something is inserted to "Headphone Mic Jack" . You can verify priorities using Another point is that the "Headphone Mic Jack" is shared with both Headset and Mic2 devices, thus the auto-detection is impossible. In this case, GUI should ask, what was inserted to the jack (the gnome / and the following PA bug). The gnome code is full of thinkos and assumptions. We need to find an abstract way to handle this. |
|
@perexg ok. Yes this was my thinking also. I'm not sure how the selection is done now, but with Dell devices without the pop-up, the default selection is "headphone mic" and it will mute the headset -> really bad user experience. So obviously the priorities in this PR are wrong (they are correct in original), but I would still swap the mic device definitions around. I know it is a "hack", but it would save us from lot of bugs/trouble with this kind of devices without the pop-up. So if there's some stupid UI selecting the first item in the list, it would still give decent experience for most. But if you disagree, still fine. Then we'll close this and give the issue to gnome folks. |
|
I think that gnome should activate the device/port by priority when the available state is unknown from the pulseaudio. The unknown state means that something was inserted, but PA cannot determine the purpose. I don't see PA_PORT_AVAILABLE_UNKNOWN handling in gvc-mixer-control.c (gnome). All tests are only against PA_PORT_AVAILABLE_NO. Edit: It seems that the uknown state is not correct for this case. The active ports by the should be marked as PA_AVAILABLE_YES (https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/blob/4dc73f5167f7d4c2cf1d3e9c8bb7c796f3a35a4e/src/modules/alsa/alsa-ucm.c#L2192). I took this info from https://gitlab.gnome.org/GNOME/libgnome-volume-control/-/merge_requests/10#note_758897 , but it is probably not correct. |
|
Will this PR be merged? I tested this PR on the ubuntu-20.04, it could fix the headphone problem on the Dell machines. (Dell machines have multi-functional audio jack). |
|
It's not related to UCM config. Ask gnome guys to fix the input selection in https://gitlab.gnome.org/GNOME/libgnome-volume-control/-/merge_requests/10 or propose the gnome fix which will use the new pulseaudio interface for the port / jack availability description: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/283 . I did the PA part but I don't have time (and to tell you truth, I don't want to bother with GUI either). In other words: Gnome should invoke a pop-up dialog with the question, what was connected to the shared jack in this case. |
|
ubuntu 20.04 uses gnome, but there are many variants like Lbuntu and Kbuntu, they don't uses gnome at all, even the gnome has the pop-up dialogue, but those variants could not share the fix with the gnome. |
|
Yes, but if those window managers also manage the sound settings, the PA card ports should be selected by the priority (automatic way) or manually (user dialog) not using the creation order. If we don't fix this now, the problem will raise anyway. Ohh, you're the author of the mentioned gnome merge request. If you can fix gnome, it would be nice. |
|
@perexg So should Pulseaudio use currently the priority? or is that broken? If the priority selection would work, we would not have this issue.... or is the idea that UI manager knows the priority? |
|
＠perexg and @juimonen I will try to change the MR for libgvc based on the available_group and type members. |
|
The pulseaudio MR was accepted (although I don't agree with this). It seems that PA implementation of some things is really weak. Closing for now. https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/294 |
Headset mic is the analog input source in 99% of the cases compared to
headphone mic, so change it's priority higher.
Jaska Uimonen jaska.uimonen@linux.intel.com