I had a further look and more general look to ffado code since my last email because there are still a lot of improvements required to access a better support of Saffire Pro 40. Now, my knowledge either in C++ or in driver encoding is rather limited so possibly I will write some stupid things in what follows.
I first focused on the router: for the Pro 40 (and presumably for other dice devices) the definitions of "sources" and "destinations" in fact depend on the considered samplerate. Typically, there is 8 ADAT inputs/outputs at 48 kHz and only 4 at 96 kHz; there is also, apparently, something different in 1394 connections depending on the samplerate.
When I searched for a place to modify the code in that sense I was wondering: sources and destinations definitions are fixed in EAP::init() where, if I understand correctly, one just access to a general configuration with possible different choices depending on the samplerate; for instance, there is a call to EAP::updateConfigurationCache() which defines different routing configuration depending on the sample rate.
Then, I imagined one would have to define different router sources and destinations as functions of the three different samplerate (low, mid, high): am I right ? In that case, I do not very well see how it has to be done correctly because it would have many influences (and would require many modifications) further in the code.
Another way would be to define sources and destinations in an other place so that it would only refer to the active router configuration: but is it a right solution ?
The second point I would like to address is the jack ports as they appear for instance in the connections of Qjackctl. jack inputs ports appear as corresponding to the transmitter(s) streams (Analog inputs, Adat, SPDIF and "loop back") while outputs ones correspond to the receiver(s) streams.
The latter is whatever irrelevant for device like Pro 40 which possesses a router: outputs of jack would have to be connected to some of the router entries, the 1394:00, 1394:01 and so on, and indeed they do so (for instance, "Mon 1" and "Mon 2" are effectively 1394:00 and 1394:01 respectively, as I could test modifying the routing). And in fact, this is probably similar for inputs even if, in that case, the routing is such (with no possible modifications, as far as I could test) that effectively the user "see" the right inputs.
Now, it appears that dice_avdevice.cpp implicitly directly refer to the transmitter and receiver streams as input/output for jack. Once again, I am quite wondering on how to change this since it would impliy many fundamental modifications in the coding, to an extent I have some difficulties to evaluate.
What is your opinion about this or am I completely misunderstanding ?