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

[Marco <mar...@ma...>]

Well... thank you Takashi, really, I have now some work in front of me, ;-)

This week I have no time for a windows installation and the mixer test,
I will give a try next this week-end probably.

Marco

Il 23. 05. 16 16:30, Takashi Sakamoto ha scritto:
> 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