Re: [FFADO-devel] Possible new MOTU UltraLite Model ID?

[Luke Y. <th...@th...>]

On Sun, Aug 01, 2010 at 10:08:03PM EST, Jonathan Woithe wrote:
> That's a little surprising.  The original ultralite has been noted by
> several others to work fine.  Any chance you can email me the python error
> you're seeing? [Ah, I see you included it later - thanks ]
> 
> Also, what version of ffado are you using?

I was using svn revision 1856.

> Unlike other devices, FFADO doesn't use the MOTU's model ID for device
> discovery because it's unreliable (from memory MOTU change the model ID for
> each firmware revision, but I'd have to check my logs to confirm this - it's
> been several years since I dealt with the MOTU device ID logic).  The
> so-called unit-version is more definitive for these devices and it's this
> that we test for.

Makes sense. I am used to dealing with the crazy world of hda audio chip identification, so this kind of stupidity from a hardware manufacturer doesn't surprise me.

> Picking out relevant details from these logs:
> 
> > === 1394 PORT 0 ===
> >   Node id  GUID                  VendorId     ModelId   Vendor - Model
> >    0       0x0001f20000083f85  0x000001F2  0x00115800    - 
> >    1       0x00004c010000455b  0x0000004C  0x00000000   Linux Firewire - 
> 
> Node 0 is the MOTU device.

Yes, I thought as much.

> > printConfigRomDebug: Config ROM
> > printConfigRomDebug: 	Current Node Id:	0
> > printConfigRomDebug: 	GUID:			0x0001F20000083F85
> > printConfigRomDebug: 	Vendor Name:		
> > printConfigRomDebug: 	Model Name:		
> > printConfigRomDebug: 	Node Vendor ID:		0x0001f2
> > printConfigRomDebug: 	Model Id:		0x00115800
> > printConfigRomDebug: 	Unit Specifier ID:	0x0001f2
> > printConfigRomDebug: 	Unit version:		0x0000000d
> > printConfigRomDebug: 	ISO resource manager:	0
> > printConfigRomDebug: 	Cycle master capable:	1
> > printConfigRomDebug: 	Bus manager capable:	0
> > printConfigRomDebug: 	Cycle clock accuracy:	0
> > printConfigRomDebug: 	Max rec:		1 (max asy payload: 4 bytes)
> 
> This summarises the more interesting parts of the MOTU's configROM.  I note
> that "Unit version" is reported to be 0x0000000d which matches the unit
> version identified in Ultralites which have previously worked with FFADO. 
> So thus far there doesn't seem to be any difference between your Ultralite
> and the ones which have worked with FFADO in the past.

Ok, now you mentioned the differing identificatino procedure for MOTU hardware, this all makes sense now.

<Snip>
 
> Ok, here's the reason why ffado-mixer failed for you: there was a typo in
> the python code.  I've fixed this in rev 1873.  Is there any chance you
> could test this revision out?  It should at least allow ffado-mixer to run
> for you.

Tested, and ffado-mixer works a treat. Haven't had time to play with it via jack, but I should hopefully get to do so today. I need to test the new firewire stack for Ubuntu maverick, so this gives me a good excuse. :) If successful, I'll likely take the fix from that revision and put it into the Ubuntu and Debian packages.

> See above.  The confusion is at least partly because in the case of MOTU
> interfaces the numbers being compared are "unit version" numbers, not model
> IDs.  In any case I don't think there's any need for a patch because the
> logs you posted indicated that the low level FFADO code does successfully
> identify your device.  The problem appears to have been a bug in ffado-mixer
> which I have now fixed.

Agreed, and thanks. Much appreciated.

> Because the MOTU mixer module failed to load the upper level ffado-mixer
> module concluded that the device was not found / not identified / etc. 
> Unfortunately there's no differentiation between a crash of the device mixer
> module and a mixer module not supporting a given interface, leading to the
> somewhat misleading error message.
> 
> Note that audio streaming (via jackd) is completely separate from
> ffado-mixer.  There's no need to run one before the other and there are no
> runtime dependencies between them.  Even with the python bug in ffado-mixer
> you should find that jackd starts successfully with your device using
> something like
> 
>   jackd -P70 -R -d firewire -r 48000 -p 1024 -n 4

Do MOTU devices need 4 periods to work properly? I remember reading firewire devices generally worked best with 3. 

Once again, thanks for your assistance.

Luke