Re: [FFADO-user] Aureon 7.1 FireWire ffado-mixer panel

[Takashi S. <o-t...@sa...>]

On May 23 2016 03:00, Marco Brignoli wrote:
> Yes, I have read the mails you have written in the past concerning the
> issues with FunctionBlockEnhancedMixer, etc and I' m aware there is some
> enhancement potential available in the ffadolib...

Yep. But I reccomend not to go to the direction. The most critical issue
is the design of FFADO's D-Bus interface for the function block
(processing).

The function block requires at least four arguments. In detail, see
clause 10.4 of the specification[1]. On the other hand, FFADO's D-Bus
interface for the function block is for Control::Continuous. This type
of interface can get maximum 2 argumetns[2].

According to this restriction (maybe based on misunderstanding of the
specification), FFADO M-Audio driver uses an ugly hack, to multiplex
several arguments into an argument[3].

Changing the type of interface causes backward compatibility issue,
therefore I reccomend not to touch it.

> With "passtrough" I mean a libffado compatible way of communicating
> directly with my device for the mixer function, without incourring in
> the standard problems of having different pieces of software driving one
> device. Maybe this is already ensured by the Firewire protocol stack in
> itself, but as I'm completely new in this field, and I have some
> experiences with other types of bus that are leading me to be really
> prudent, I'm trying to understand which could be a viable approach if I
> would try to use the mixer (assuming it is enabled in the device, I will
> have to revive a Windows box to verify with the official software)

As long as I know, you cannot achieve the 'passthrough'. In FFADO stuff,
'ffado-dbus-server' handles firewire character devices, and messaging is
processed by libffado library mapped to the server process. Applications
should communicate to the server via D-Bus interface. There's no way to
bypass the server and D-Bus interface, as long as you use ffado-mixer
implementation[4].

Several years ago (2013), when realizing this design, I had the same
consideration as you have, because it don't help my work at all. Then, I
concluded to write my own tools[5][6]. The 'hinawa-bebob-parser' is such
a tool and you can see it is quite easy to use and simpler. When you
have some interests, see this ovewview of the library[7].

Anyway, 'firewire-request' command of linux-firewire-utils[8] may be a
help of the beginning of your first work. You can check actual effect
when sending bytes of AV/C commands. You can write rough prototype with
this tool.

[1] AV/C Audio Subunit Specification 1.0 (TA Document 1999008)
http://1394ta.org/wp-content/uploads/2015/07/1998008.pdf
[2]
http://subversion.ffado.org/browser/trunk/libffado/support/dbus/control-interface.xml#L63
[3]
http://subversion.ffado.org/browser/trunk/libffado/src/bebob/bebob_mixer.cpp#L327
[4] clause 4.1 of my report.
https://github.com/takaswie/alsa-firewire-report
[5] libhinawa
https://github.com/takaswie/libhinawa
[6] hinawa-utils
https://github.com/takaswie/hinawa-utils
[7]
https://raw.githubusercontent.com/takaswie/libhinawa/master/doc/overview.png
[8] https://github.com/cladisch/linux-firewire-utils


Regards

Takashi Sakamoto