firewire mixer interface -- was Re: [PATCH 11/11] ALSA: digi00x: apply double-oh-three algorism to multiplex PCM samples

[Robin Gareus <robin@gareus.org>]

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