From: Jonathan W. <jw...@ph...> - 2010-09-09 10:59:39
|
Hi Sorry for the delay in responding. > These are 20 IDs. Quite many, but manageable. But wait, as I already > mentioned in the other post, RME (mis?)uses Xilinx' OUI for their firmwares. Yes, it seems they do. I hadn't noticed that up until now. > Hence we should not match vendor but, for example, vendor_name or > vendor_name/model_name. Model ID may not be suitable due to firmware version > churn. The FFADO developer who implements RME device support should comment > on that. (Jonathan?) I'm not sure whether RME churns Model ID with different firmware versions. I've only ever had the one firmware version in my FF400/FF800. Having said that, RME does use the Unit version to tell the two models apart. In the case of MOTU however I can be more definite: different firmwares for the same device do report different model IDs. To be specific, my Traveler originally reported a model ID of 0x00104800 with firmware version 1.04. After upgrading to version 1.07 this changed to 0x00107800. So we see that the firmware version is communicated in nibbles 5-3. The lowest 3 nibbles equal 0x800 across multiple devices. There doesn't appear to be anything model-specific in the MOTU model ID. It was later discovered that in the case of MOTU the unit directory version field could be reliably used to differentiate MOTU models. > All other vendor IDs look good. What's more, all of these vendors are > unlikely to ever market FireWire storage devices or other non-audio FireWire > devices. So, my suggestion is: Check for vendor ID only --- except in the > three special cases of Xilinx^wRME, Omron^wCME, and Next^wMackie. These three > special cases are alas unavoidable due to firmware authors using bogus IDs. MOTU manufacture firewire-equipped video interfaces which should probably not be matched when identifying "audio" devices. So there may have to be some sort of exception for MOTU as well (or we just ignore this inconvenience and hope it doesn't become a serious problem). > Stefan Richter wrote: > > SUBSYSTEM=="firewire", ATTR{vendor_name}="RME", \ > > ATTR{model_name}="FireFace?00", GROUP="audio", ENV{ID_FFADO}="1" > > Unless these devices have useful specifier:version pairs of IDs. > In that case, an ATTR{units}="...:..." match may be an alternative. Here's the CSR ROM Info for a Fireface-400 as reported by gscanbus: Vendor ID: 0x00000A35 Unit Spec ID: 0x00000A35 Unit SW Version: 0x00000002 Model ID: 0x00101800 Nr. Textual Leafes: 0 I can't conveniently interrogate my FF800 right now to facilitate a comparison. What I can tell you is that the FF400 and FF800 are differentiated using the Unit SW Version field (as for MOTU): the FF800 has a value of 0x00000001 while the FF400 has 0x00000002. > > So matching on "vendor" and "model" does not seem so bad after all? Or > > are some devices incorrectly listed as something else than AV/C devices? > > Also, if the ATTR{model} is missing, the rule will simply not match, > > which is what we want. > > But do all AV/C audio devices follow that AV/C specific 1394 TA specification > for Configuration ROM of AV/C devices? > > Do audio devices which do not comply with AV/C, i.e. > - DICE based devices, > - FireWorks based devices, > - MOTU devices(?), > - RME devices(?) > have the optional Model ID in the root directory? I can't quickly check that for RME or MOTU. However, in the case of MOTU some early code I was using to explore the device tends to indicate that there is no model ID in the root directory (in which case it's only in the unit directory). > The question of Model ID is moot in case of RME Fireface 400/800, > according to the comment in libffado/configuration. Agreed - and for MOTU as well. Regards jonathan |