Re: [RFC PATCH 3/4] ASoC: hdac_hdmi: refine hdmi jacks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2019/6/25 下午7:05, Takashi Iwai wrote:
On Tue, 25 Jun 2019 08:02:45 +0200,
Yang, Libin wrote:
Sorry for a long delay for the hdmi jacks. I was busy on another critical issue
last 2 weeks. I have worked out the UCM configuration files. Please check the
attachment. It is a long file, so I use the attachment instead of the patch mode.
Based on my test, it works well. Could you please help review if the
configuration file is OK or not. I will do more test on the meantime, including
DPMST and NON-DPMST.
With some more tests on the new hdmi jack with UCM configuration, I found
that the kernel patch can always notify the jack hotplug event to userspace
correctly. However, the userspace can't set the amixer correctly based on
the UCM configurations sometimes.

Here is the details:
There are 3 PCMs on Intel platforms. Let's call them pcm1, pcm2, pcm3.
And there are 3 pins (pin5, pin6, pin7). For DPMST, and each pin has 3 ports:
port0, port1, port2.

For non-DPMST, we can set pin5 <=> pcm1, pin6 <=> pcm2, pin7 <=> pcm3.
This can always work.

For DPMST, as there are 9 ports using 3 pcms. So we should assign
1 pcm to 3 ports. For example, pin5-port0, pin6-port1 and pin7-port2
are using pcm1;  pin5-port1, pin6-port2 and pin7-port0 are using
pcm2; pin5-port2; pin6-port3 and pin7-port1 are using pcm3.
In this setting, we should setting the ConflictingDevice in UCM.
For example, pin5-port0 is conflicting with pin6-port1 and pin7-port2.
Hui and I found if we set one device conflicting with 2 devices, the
amixer setting will be wrong and it will not following UCM configuration
setting when we are hotplugging the monitors.
How wrong would it behave?  Only one of them is done?

Yes, only the 1st conflicting device is handled.

for example:

pin5-port0 has two conflicting devices: pin6-port1 and pin7-port2,

When pin5-port0 is active in the pulseaudio, I can see the pin6-port1.DisableSequece and pin7-port2.DisableSequence are called according to pulseaudio's log, but it looks like the commands only in the 1st device (pin6-port1.DisableSequence) are executed.

To call conflicting devices' disablesequence, the pulseaudio will call snd_use_case_set(ucm->ucm_mgr, "_disdev", dev_name) twice, but only the 1st time calling takes effect.



Hui and I thought this may be the alsa-lib or pulseaudio issue.
You can try alsaucm directly without PA, too.
But in general the conflicting device management is done in PA, so I'd
begin with tracking the PA UCM code at first.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel




[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux