Re: [FFADO-devel] Some minor patches

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

Hi Phil

On Wed, Sep 25, 2013 at 08:23:16AM +0200, Philippe Carriere wrote:
> > On checking the code against the DICE documentation I could find online, it
> > is not clear what the original intent of this code was.  There is in fact 8
> > audio ports flowing out of and into the router from the ARM core.  I can
> > think of two options.
> > 
> >  1) The "i<0" was a typo and should have been "i<8".  This would set routes
> >     up to the 8 router outputs connected to the ARM core.  It doesn't
> >     explain what the deal is with the 8 router inputs from the ARM core
> >     though.
> 
> i<0 was effectively a typo as I implemented and i<8 would have to be
> written instead.

Fair enough.  The code I substituted therefore would seem to be ok, at least
in the first instance.

> Refering to the doc I enclosed, for instance, it is doubtful that "ARM"
> audio port is intended to be either a source or a destination, at least
> for Dice Jr and mini.

It's clearly part of the design in those two systems.  I was using the DICE
mini user's guide as a reference and the links to the ARM core to and from
the router block are still very much present.

> And whatever EAP is not available on DiceII (the
> comment is a little bit vague; Extended Application Protocol only
> involves Dice Jr and mini; for DICE II, the protocol, different from
> EAP, is unknown).
> 
> So, probably, "ARM" audio port should not appear in dice_eap. Now,
> possibly, other developers might have a different point a view ?

The ARM audio ports are a part of the DICE mini - at lease according to the
DICE mini users guide.  This would appear to be an argument for including
them.  What I don't know is what these might be used for.  I expect it could
be used for onboard DSP of some kind.  However, since this would have to be
implemented as part of the firmware, the actual functionality would be
interface specific and control of it could well utilise vendor-specific
commands.  Whether this means we are best to not include these routes, I'm
not sure.

> Finally, recall that the specific function under consideration,
> setupDefaultRouterConfig_low(), is intended to be used only when a reset
> of the router configuration is required (typically when an invalid
> config. has been set using a too old version of ffado), without
> returning to Windows or MacOS. While the customized config. for Saffire
> Pro, Presonus or M-Audio are known to work, the status for another
> unspecified DICE EAP device is unknown.

Good point.  So this means that the change to this function will not affect
devices in normal use.  Only when someone resets the routing  will we find
out what the effect of the change might be.  My gut feeling is that it
should be ok to leave the code as-is, but I'm willing to be convinced by
someone who actually works with these devices. :-)

Thanks also for the reference links.  They could be useful in future.

Regards
  jonathan