Hi Robin,
On Mar 20 2015 21:05, Robin Gareus wrote:
$ ./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?
Any userspace applications can destroy packet streaming which kernel driver starts, by transaction to streaming-related register.
In current implementation of ALSA firewire stack and Linux FireWire subsystem, we cannot avoid this.
For example, about Digi 002/003 family, we can destroy kernel streaming in a way below: 1.write/read PCM samples to ALSA PCM character devices (in most case done via alsa-lib PCM API) 2.write transaction with 0x00000003 for 0xffffe0000004 to /dev/fw%u. 3.Applications cannot read/write PCM samples again.
In this case, usually, the process receive EIO from ALSA PCM API.
Instead interfacing via established protocols /dev/snd/control* or rather libasound's snd_mixer_t seems like a no-brainer to me.
As long as being able to send transactions via FireWire character devices, the headache remains, regardless of the place to implement such control functionality.
Are there any control elements on common 1394 devices that cannot be properly exposed using existing infrastructure?
More explaination, please.
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.
I don't think it possible to argue the other ALSA developers for going to include such vendor-specific or model-specific huge codes to alsa-lib... (Except for intel HDA)
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).
Here, I mention about alsa-lib control API to add control elements from userspace and it's eventing mechanism. http://www.alsa-project.org/alsa-doc/alsa-lib/group___control.html#gad5f640f...
Regards
Takashi Sakamoto