Re: [FFADO-devel] MOTU and the svn1543 probe changes

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

Hi Pieter

> > I noticed the probe change made in rev 1543 to utilise the configuration
> > file now for device probing.  Undoubtedly the reason for not porting MOTU to
> > use this is because the configuration file only includes the vendor and
> > model IDs, while the MOTUs require at least the unit version as well (for
> > some odd reason MOTU use model ID to reflect other information such as
> > firmware version).
> > 
> > Would you like me to add optional unit version support to the configuration
> > file and port MOTU across to this as well?  I figure I'd ask first because
> > you might feel it best to keep this "bloat" out of the configuration file
> > mechanism given that it is likely to only ever be used by one driver.  If
> > however you don't have a problem with this I'll work on this.
> 
> The main reason why I introduced the config file based discovery is that 
> we devices can be added after compiling, which makes sense given the 
> platform based designs that are out there.

For sure.

> The main question is whether this is also applicable to the MOTU code. 
> If you have to hardcode things anyway, there is not much sense in doing 
> this.

Yeah, I was thinking about this myself last night.  The way the MOTUs change
architecturally there's very little chance that an existing model will do
the right thing for anything new which comes along (except perhaps in the
start/stop streaming area, but that's not much good without device control). 
Ergo a "generic MOTU" driver doesn't really make sense - it's far from
obvious, for example, which existing model to call "generic".

> A second advantage is that it allows me to configure the discovery and 
> streaming on a per-device basis, which is also nice.

I missed this - how is the current situation different to the previous one
in this regard?  Haven't we always done things on a per-device basis?  Oh
hang on - you're talking about the streaming parameters such as
xmit_max_cycles_early_transmit and so forth, aren't you?

> I'd like to keep the bloat of the unit version out of the config file as 
> it is a stupid hack. But if there is an advantage in adding it, be my guest.

No worries - I'll let it simmer for a while.

BTW, the same situation crops up with the RME devices - they also use the
unit version to differentiate devices, so the changes in rev 1543 actually
broke detection for RME.  I've fixed this for the moment by simply comparing
the config file's model ID with the unit version from the configrom, but
depending on my mood I may go back to the hard-coded version for RME.  The
situation with RME is similar to MOTU in that there isn't really a "generic
RME" definition.  There are two devices - the fireface 400 and 800
- and they differ in considerable ways.  There's no obvious choice for the
"generic" label so for now I'm taking the view that there is no "generic"
RME driver option.

> PS: The config file based discovery also currently doesn't allow for an 
> optional argument, so you'll have to add that too.

Yes, I thought that might be the case.

Regards
  jonathan