| Message ID | 20201209124344.219158-1-hui.wang@canonical.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | design a way to change audio Jack state by software | expand |
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. 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. Jaroslav
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? > 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. thanks, Takashi
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
Hi, On Wed, 9 Dec 2020, 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 thanks Hui for the RFC. I do think this is a very tempting capability to add. I understand Jaroslav's concerns as well, but there is clearly a category of issues where user-space functionality is broken due to a mismatch of element names between UCM file and the driver. I.e. the actual jack detection (codec hw and its driver) is working, but due to wrong UCM file chosen, wrong driven is chosen, or errors in either UCM or driver, event does not get parsed right and user ends with no audio. A pure user-space test harness would not catch these, and building full automation of external codec events, is a complex task and coverage of devices is likely limited. The 'edid_override' debugfs interface in i915 is a bit similar. It allows inject EDID content irrespectively of the actual monitor connected. > 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. ++votes on this Br, Kai
On 12/11/20 9:36 PM, Kai Vehmanen wrote: > Hi, > > On Wed, 9 Dec 2020, 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 > thanks Hui for the RFC. > > I do think this is a very tempting capability to add. I understand > Jaroslav's concerns as well, but there is clearly a category of issues > where user-space functionality is broken due to a mismatch of element > names between UCM file and the driver. I.e. the actual jack detection > (codec hw and its driver) is working, but due to wrong UCM file chosen, > wrong driven is chosen, or errors in either UCM or driver, event does not > get parsed right and user ends with no audio. > > A pure user-space test harness would not catch these, and building full > automation of external codec events, is a complex task and coverage of > devices is likely limited. > > The 'edid_override' debugfs interface in i915 is a bit similar. It allows > inject EDID content irrespectively of the actual monitor connected. > >> 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. > ++votes on this OK, got it, am preparing the v2 RFC, will send it out soon. Thanks for your comment. > > Br, Kai