MIDI inputs/outputs are shown as audio ports

Is this with jack2 or jack1?

If it is with jack2, it could be related to #234...

Ping. Is it still valid?

This problem still exists in the latest FFADO, and with both JACK versions, as far as I can tell.

Is for the same reason that Echo Audiofire Pre8 shows 17 audio channels, whereas it only has 8 analog I/Os and 8 digital I/Os?

This bug is still valid. The current SVN (1887) still sets 17 Audio channels on the AudioFire? Pre8. The version 2.0 stable release does not do this. This manifests with both the IEEE1394 and Juju kernel stacks. I'll take a quick run through the prev releases to see if I can trace it to a specific point.

Reported on IRC today: Audiofire 2 is affected too. The owner says "I see 5 audio input (one of which I suppose is the midi in) and 7 output (midi out again)".

Up. Same on AudioFire?4 with current (as of Sep 12, 2010) jackmp and ffado. 7 input and 7 output ports and no MIDI.

Also same behavior with "old" jack.

I can confirm this is also happening on my audiofire 12. Works in 2.0.1, but doesn't with trunk.

Diff to correct MIDI Port in Jack

Gotcha!

The fault appears to be with the call to discoverClusterInfo in src/libavc/general/avc_plug.cpp. When this is called without any defined clusters it sets up a default cluster with hardcoded values. When we subsequently try to propagate our true clusters from iPCR0 and oPCR0 (Plug::propagateFromPlug) it sees there is already a configured cluster (if (m_clusterInfos.size()==0))so does nothing.

If we remove the default section as per my patch we correctly propagate our real ports and the MIDI port is correctly passed though to Jack.

Tested on current svn of FFADO and jackmp with AudioFire?4. Works as a charm. Thank you, euan!

I will test that patch the next days. But don't get your hopes too high, this is code that also used for other devices. So what fixes things for the audiofires might break things for others. If so, we will find a different solution...

Note to others: If you have a device, that is not an audiofire, please help test if this patch breaks things.

Deactivating the default-behavior seems rather drastic to me. I propose a different patch (attached to this ticket) to propagateFromPlug that propagates when the first detected cluster-info is from the default-method.

Could you test that and tell me if it works?

BTW: I think fixing this stream-problem could also add names to the in- and outputs because now the default definition with name "Unknown" is overwritten by a detected one. Anyone can confirm this?

I've applied your patch to the clean tree, it works normally. Jack found 6 audio channels named GUID_Unknown#_in and GUID_Unknown#_out. Midi ports also detects normally.

audiofire_alternate_streams_fix.diff fixes it for me as well, the ports still show up as "unknown" however instead of saying "dev0" it now shows up with the GUID as mentioned.

I agree that my patch is a bit drastic. I also agree that your approach is cleaner, however Isn't it a bit risky to trust the name = unknown qualifier. Wouldn't it be better to add another member to the cluster to mark it as auto generated.

As requested by arnonym: your fix is safe wrt my DICE based Alesis io14. IOW, it doesn't break anything.

I think I fixed this in r1899. If it doesn't, please re-open this ticket.

This is not fixed. The fix applied was to assume the m_streamFormat is set to -1. This is not a valid assumption, as the discoverStreamFormat() call that comes immediately after the discoverClusterInfo sets the format to the stream format before we propagate.

clusterInfo->m_streamFormat = streamFormatInfo->m_streamFormat;

BTW: It's also a bit confusing setting/comparing an unsigned u_int8 variable to -1...

Non conflicting fix

As mentioned earlier, the fix proposed does not work, and I have concerns regarding the first proposed fix. I have uploaded an alternate fix, this defines an extra member of clusterInfo, called m_buildSource. This is set to -1 when we instantiate the dummy classes, and is used to determine whether there are candidates for propagating. Once propagated, we set this to 0 to prevent any further propagation. This appears to work correctly with my Audiofire Pre8 device.

arnonym, please review this and apply if you are happy.

Euan.

Do we need to revert r1899 and use euan's latest patch here? If so, I volunteer to do so. ;)

I tested, on two Echo Audiofire Pre8, the latest patch proposed by Euan and I confirm it solves the problem

From my point of view, it would be nice to include it in the trunk.

Yves Grenier

Question remains: have you reverted r1899 or do I simply apply the patch on top of it?

r1899 has not been reverted, this patch works from the current state of the code, including r1899.

I have applied the patch as r1949, but tweaked it a bit. Changed

  m_clusterInfos[0].m_buildSource == 0; // No longer a temp instance...

to

  m_clusterInfos[0].m_buildSource = 0; // No longer a temp instance...

making it an assignment instead of a comparison.

Please check if this breaks something. If so, reopen the ticket. ;)

HTH

I feel like a total idiot... Don't know how that slipped through. Thanks Adi.

I can confirm that the fix you have applied does work on my Audiofire Pre8.