[RFC][PATCH 0/2] design a way to change audio Jack state by software

Hui Wang hui.wang at canonical.com
Thu Dec 10 02:54:19 CET 2020


On 12/9/20 10:44 PM, Takashi Iwai wrote:
> On Wed, 09 Dec 2020 15:25:42 +0100,
> Jaroslav Kysela wrote:
>> Dne 09. 12. 20 v 13:43 Hui Wang napsal(a):
>>> After we change sth in the userspace audio stack like alsa-ucm or
>>> pulseaudio, we want to perform remote audio auto test to verify if the
>>> change introduce the regression or not, some of the tests are about
>>> the defaut_sink/default_source or active_port switching, this needs
>>> the audio jack state to be changed to trigger the userspace's audio
>>> device switching.
>>>
>>> So far, there is no software ways to change the audio jack state, this
>>> block the auto test.
>> I'm not convinced to pollute the kernel space with this code. You can use
>> LD_PRELOAD and simulate this via a shared library or the alsa-lib may be extended.
> While I understand this argument, I see the merit of having the
> kernel-side injection, too.  Wrapping with LD_PRELOAD (or use alsa-lib
> plugin) doesn't verify whether the whole jack system works.  OTOH, the
> jack injection in kernel simulates the closer path to the real use
> case, which covers also the call paths inside the kernel.
>
> Though, I'm not sure whether the current design is the best choice.
> Basically sysfs is expressed in one value per file (although there are
> many exceptions, of course).  So creating a node per jack object might
> fit better?  Or can it better be in debugfs?
OK, got it, will investigate it.
>
>> Also, the first patch can be omitted if you just create another
>> snd_jack_report() function for the user API and put the common code to the
>> static function in jack.c.
> Fully agreed on this point.

Indeed, it is a better and cleaner way, will think about it and 
implement it.

Thanks.

>
> thanks,
>
> Takashi


More information about the Alsa-devel mailing list