Robin and Damien,
On Mar 19 2015 22:59, Robin Gareus wrote:
On 03/18/2015 02:06 AM, Takashi Sakamoto wrote:
Please explain the importance, especially the reason to include the selector into kernel code instead of userspace application.
Can one access the device from userspace while the kernel is using it to stream audio or midi ("Device or resource busy") ?
I can't understand what character devices you mention about. If you mention about ALSA PCM character devices (usually /dev/snd/pcmC%uD%d[p|c]), it's yes. In fact, one ALSA application can use ALSA PCM character device for one direction (playback/capture). So the access by any other applications causes -EBUSY. (here, I ignore alsa-lib's PCM direct mixing layer.)
But, when you utilize kernel control functionality, the character device is not PCM one, it's Control one (/dev/snd/controlC%u).
By the way, we can program any userspace application via FireWire character device (/dev/fw*). Actually, I utilize firewire-request in Linux FireWire utilities (former known as jujuutils), and write my own I/O library, libhinawa.
Linux FireWire utilities https://github.com/cladisch/linux-firewire-utils
libhinawa http://mailman.alsa-project.org/pipermail/alsa-devel/2015-January/086969.htm...
For example, to control the clock selector of Digi 002/003 family, we just execute this command with firewire-request.
$ ./firewire-request /dev/fw1 write 0xffffe0000118 0x0000000[0|1|2|3]
We can perform to control them from userspace.
This is one of the reasons, why USB soundcards expose all settings though the alsa mixer interface. It also offers a standardized interface for userspace apps to build on top and a method to directly link mixer to soundcard for systems with multiple soundcards.
How do you envisage to handle this?
These USB-connected sound devices basically tells their control capabilities by USB descriptor information. This mechanism is standardized and included in USB specification. Thus single parser has a meaning.
On the other hand, IEEE 1394 bus-connected sound devices implements its own way to tell their control capabilities and model-specific way to perform control. Thus we should prepare for model-specific parsers. The idea to include these parsers into kernel-space increases maintaining efforts.
(Actually, USB-connected sound devices includes vendor-specific interface. Such interfaces require own codes and snd-usb-audio includes these code. You can see such codes in sound/usb/mixer_quirks.c and the other USB Audio device class driver codes.)
In an aspect of user experience, I cannot find any differences between using alsamixer (or amixer) and using specific-application. ALSA PCM character devices, ALSA Control character devices and Linux FireWire character devices are completely different and users don't mind the differences. What the users' want is to control their physical devices, to consider about to which character devices they access.
Regards
Takashi Sakamoto