On 03/19/2015 11:46 PM, Takashi Sakamoto wrote:
Hi Takashi
Thanks for elaborating.
[..]
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]
Yes, that's what I was asking about. Can one safely write raw control messages to /dev/fw* without interfering with ongoing streaming?
Instead interfacing via established protocols /dev/snd/control* or rather libasound's snd_mixer_t seems like a no-brainer to me.
Are there any control elements on common 1394 devices that cannot be properly exposed using existing infrastructure?
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.
Agreed. Most of the heavy lifting should probably be done by libasound.
In an aspect of user experience, I cannot find any differences between using alsamixer (or amixer) and using specific-application.
Uhm. It's a huge difference. There is a whole lot of existing infrastructure: from Sys-V init.d and/or SystemD save/restore, dbus hooks, existing mixer GUIs and application integration, not to mention various language bindings (eg pyalsa).
Linux Audio is already fragmented enough as it stands, adding yet another interface/toolchain won't help. One might just as well continue to use ffado. I was under the impression that the whole point of moving 1394 audio into the kernel was to allow seamless integration with the rest of ALSA.
2c, robin