Re: [FFADO-user] Order of multiple firewire devices in jack

[Jonathan W. <jw...@ju...>]

Hi Thomas

On Sun, Oct 13, 2013 at 01:04:44PM +0200, Thomas Orgis wrote:
> Am Sat, 12 Oct 2013 14:32:00 +0200
> schrieb Thomas Orgis <tho...@or...>: 
> 
> > Simply put (see my other recent post): Have the automatic connection of
> > applications, specifically Ardour, work out, mapping the first 10
> > channels (simply named 1 to 10 in Ardour) to the FA-101
> > [...]
> > guess I need to figure out how to do the routing on the outside and
> > have it (re)stored automatically. Perhaps qjackctl can do that, if
> > Ardour doesn't inhibit this.
> 
> I peeked at this and concluded that this does not work out without some
> really smart scripting. I guess I could try to scan the connections
> after starting Ardour and detect automatically connected hardware ports
> and reconnect those using jack_connect.

I will have to check this later myself, but does Ardour have the option to
interact with port liases rather than names?  If so, the actual ordering of
channels wouldn't matter.  A connection to *_<GUID of FA-101>_<chan 1> would
always refer to channel 1 on the FA-101 regardless of whether the FA-66 was
in place or not.  To me this would appear to resolve the problem, so the
fact that this is evidently not a workable solution suggests that there is
no way to expose the port aliases under Ardour.

> A solution would be to disconnect everything and paint the whole
> connection picture in the patchbay, but: The whole picture includes
> internal routing inside applications, including a varying count of
> channels/buses in Ardour.

Yes, and as you said an external patch manager can't easily deal with this.

> It would make life much easier if this "natural" order (in my case of
> "main" and "secondary" audio interface) could be supported by JACK's
> firewire backend.

I don't have a problem with something like this being added.  Patches are
welcome.  This could be along the lines of an option which provided a
GUID-to-device-index mapping, thus forcing a particular GUID to be processed
before another if it exists.

> I want to add that I am really grateful that device aggregation is
> there and thank you guys for making it possible. I hope I can convince
> you to include a possibility to reorder things. Maybe I could create a
> patch myself (to JACK, I presume, not ffado itself?), but I guess the
> main hurdle is the question if this option should be present, not the
> actual implementation.

At present I don't have time to work on something like this: there are
several disruptive bugs lurking in the ffado/libraw1394/kernel subsystem
which I really want to resolve soon.  I would encourage you to work on a
patch to provide this sort of functionality.  Because of the GUID aliases my
guess is that it won't be needed by many people, but so long as the
functionality stays out of the way unless invoked by the user and it doesn't
pose a major headache for the libffado API I don't have a fundamental
problem with it.

I suspect that both FFADO and the "firewire" jack driver will need patching. 
FFADO is where device discovery and aggregation is done and this is where
the ordering knowledge will be needed.  The jack driver, on the other hand,
is what gets to parse the jack command line.  Since this will require
additional information be passed into libffado from outside (jackd in this
case) the libffado API version will need to be incremented to accommodate
this.  There are set guidelines for doing this to maintain (as much as
possible) compatibility with earlier jackd binaries.  Once you have some
ideas about how you might go about passing the information into libffado we
can talk more about how the API revision might be managed.

Having said that, before proceeding it might be an idea to check out
Takashi's ALSA streaming driver for BeBoB devices.  Takashi posted a call
for testers in the last day or so (subject: "Call for testing: ALSA driver
for Fireworks/BeBoB based devices" on ffado-devel).  This driver should
include support for the FA-66 and FA-101 devices and therefore could be
relevant for you.  This streaming driver is the first example of a planned
movement of the audio streaming layer out of FFADO and into the kernel
(device control like the mixer will remain within libffado for a variety of
reasons).  As such it represents the next generation of the FFADO streaming
engine, so in many respects it's worth considering how this might affect
things in the future.

In particular, the ALSA-based streaming drivers will not automatically
aggregate multiple devices into a single device - instead each device is
seen as a distinct card from the point of view of the PCM (audio) interface. 
Instead, aggregation would be handled in the same way as it is now for
multiple cards under ALSA.  As a result, the question of which device is
used first might simply go away.

A final thought is that over the years, aggregation of ALSA devices hasn't
always been smooth sailing and has presented issues for jackd.  I don't know
if these have been resolved.  However, if you have the time and resources
now would be the ideal time to explore these things with these new streaming
drivers so any potential issues can be identified early (and hopefully fixed
before they become a real problem).

That's a lot to digest in one hit - sorry.  Please let me know if you want
further details about any of these points.

Regards
  jonathan