[FFADO-devel] further about Pro 40

[Philippe C. <la-...@or...>]

Hi Clemens,

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 ?

Regards,

Phil
-- 
Philippe Carriere <la-...@or...>