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

[Takashi Sakamoto <o-takashi@sakamocchi.jp>]

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#gad5f640f1d836b532b1c18d7604a90bad

Regards


Takashi Sakamoto