Re: [FFADO-user] Dual ProFire 2626, both with the same GUID, only one interface used

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

Hi Bob

On Wed, Aug 08, 2018 at 06:01:03PM +0100, Bob Ham wrote:
> > I have two ProFire 2626 interfaces on the same bus.  They are both
> > recognised by ffado-test:
> > 
> > $ ffado-test ListDevices
> > ...
> >   Node id  GUID                  VendorId     ModelId   Vendor - Model
> >    0       0x000d6c0404000002  0x00000D6C  0x00000010   M-Audio -
> > ProFire 2626
> >    1       0x000d6c0404000002  0x00000D6C  0x00000010   M-Audio -
> > ProFire 2626
> 
> > 192784286578: Warning (devicemanager.cpp)[ 590] discover: Device with
> > GUID 000d6c0404000002 already discovered on other port, skipping device...
> > 
> > This gives me great concern.  It would appear that I have two devices
> > with the same "GUID" and that FFADO is ignoring one of them because the
> > GUID values are the same.  I don't know what the GUID is or where it
> > comes from.  If the acronym stands for "Globally Unique ID" and it's
> > from the hardware then I'm even more concerned.
> 
> It would appear that M-Audio's engineers have given all of the ProFire
> 2626 units the same GUID.  The user guide??? displays an image of the
> About tab on their Mac OS software (p. 31) and there is a "Device" field
> containing the text "ProFire 2626 (D6C0404000002)", which is the same
> hex ID as the GUID on my units.  Alas.

Wow.  That really isn't helpful since it means there's no way to uniquely
identify a particular unit when you have more than one of them.

> There is an article on the M-Audio website¹ which discusses using more
> than one ProFire 2626 where only one unit is connected to the PC and the
> other units are connected to the first using the optical ADAT ports.
> The article gives instructions on configuring the stand-alone mode.  The
> ffado-mixer application contains similar settings controls for
> stand-alone mode configuration but the controls are greyed out and their
> tooltips read "not implemented".
> 
> Presumably the underlying support is missing from ffado and not just the
> mixer UI.  Can anyone tell me what would be necessary to implement this
> support?

If the controls say "not implemented" then I can only assume that the person
who wrote the code for the ProFile 2626 did not know how to control those
features in the hardware.  I'd say the controls were included in the mixer
GUI because they were known to exist (due to their appearance in the
official control programs).  However, until it can be determined how to make
changes to those settings (as in, what data needs to be sent to the ProFile
2626 to make the changes) then we obviously can't control them.

To implement the support of these controls we would need to know what data
(commands) should be sent to the interface in order for the setting changes
to be made.  Ideally this discovery work would be done by someone who could
also integrate the knowledge into the code, since you really need physical
access to the hardware in order to efficiently debug the work.  Since the
manufacturer hasn't provided protocol documentation, to make progress you'll
have to analyse the protocol when using standard control programs.  There
are numerous posts on the FFADO devel list which cover the process from
various angles.  If you're interested in pursuing this and can't locate the
information let us know and we'll see about filling you in.

In your case I suspect it will be easier to hack FFADO to alter the GUID 
reported to the rest of FFADO by (for example) adding the node ID to it. 
This ensures that FFADO's higher levels will see different GUIDs, and
therefore everything will work as expected.  It's certainly not a generic
solution, but it might be enough to get things going given that the GUIDs of
these devices do not appear to be unique.

Although I have not tested this, this idea could probably be implemented
with the following change.

--- a/src/libieee1394/configrom.cpp	2017-03-22 09:09:58.443209588 +1030
+++ b/src/libieee1394/configrom.cpp	2018-08-09 08:59:43.643444977 +0930
@@ -207,6 +207,8 @@
     m_guid = ((u_int64_t)CSR1212_BE32_TO_CPU(m_csr->bus_info_data[3]) << 32)
              | CSR1212_BE32_TO_CPU(m_csr->bus_info_data[4]);
 
+    m_guid += m_nodeId;
+
     if ( m_vendorNameKv ) {
         csr1212_release_keyval( m_vendorNameKv );
         m_vendorNameKv = 0;

Since there's no assurance of which node IDs a particular interface will be
assigned during bus negotiations, the resulting GUIDs won't necessarily be
consistent across sessions.  For example, in one session interfaces A and B
might have a node IDs of 0 and 1 respectively, while another time they might
be reversed.  You'll have to test it to see if this is happens in practice
in your setup and make appropriate allowances if it does.

Regards
  jonathan