Ticket #233 (closed bug: fixed)

Opened 5 years ago

Last modified 4 years ago

MIDI inputs/outputs are shown as audio ports

Reported by: das Assigned to: arnonym
Priority: major Milestone: FFADO 2.1
Component: Version: FFADO SVN (trunk)
Keywords: MIDI Cc:
The device the bug applies to: Echo Audiofire 2/ 4/ Pre8/ 12

Description

For my Audiofire 4, JACK used to show 6 audio input and output ports, as well as 1 MIDI input and output. With the latest FFADO trunk, I get 7 audio ports instead, and no MIDI. The last audio port of course isn't functional, I can connect (audio) clients but obviously I get no sound out of it.

I did some testing with older versions, and the problems appears to have been introduced somewhere between revs 1534 and 1538 (revs in between don't build).

Attachments

jack_midi_fix.diff (0.7 kB) - added by euan on 09/12/10 08:09:52.
Diff to correct MIDI Port in Jack
ffado-audiofire_alternate_streams_fix.diff (0.5 kB) - added by arnonym on 09/12/10 12:24:49.
ffado-audiofire_midi_fix.diff (1.4 kB) - added by euan on 12/14/10 05:19:32.
Non conflicting fix

Change History

09/22/09 14:34:45 changed by arnonym

  • milestone changed from FFADO 2.0 to FFADO 2.1.

01/01/10 14:48:31 changed by arnonym

Is this with jack2 or jack1?

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

07/21/10 10:20:44 changed by adi

Ping. Is it still valid?

09/02/10 04:21:00 changed by das

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

09/02/10 05:04:26 changed by yves.g

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?

09/10/10 11:06:06 changed by euan

  • device_name changed from Echo Audiofire 4 to Echo Audiofire 4/Pre8.

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.

09/11/10 08:29:56 changed by stefanr

  • device_name changed from Echo Audiofire 4/Pre8 to Echo Audiofire 2/ 4/ Pre8.

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)".

09/11/10 13:34:27 changed by gauss-gs

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

09/11/10 13:59:00 changed by gauss-gs

Also same behavior with "old" jack.

09/11/10 14:58:52 changed by xero

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

09/12/10 03:15:17 changed by stefanr

  • device_name changed from Echo Audiofire 2/ 4/ Pre8 to Echo Audiofire 2/ 4/ Pre8/ 12.

09/12/10 08:09:52 changed by euan

  • attachment jack_midi_fix.diff added.

Diff to correct MIDI Port in Jack

09/12/10 08:14:50 changed by euan

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.

09/12/10 08:41:33 changed by gauss-gs

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

09/12/10 09:45:24 changed by arnonym

  • owner set to arnonym.
  • status changed from new to assigned.

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.

09/12/10 12:24:49 changed by arnonym

  • attachment ffado-audiofire_alternate_streams_fix.diff added.

09/12/10 12:28:19 changed by arnonym

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?

09/12/10 12:53:50 changed by gauss-gs

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.

09/12/10 19:21:14 changed by xero

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.

09/12/10 23:54:30 changed by euan

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.

09/13/10 01:34:04 changed by adi

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

09/16/10 12:39:49 changed by arnonym

  • status changed from assigned to closed.
  • resolution set to fixed.

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

10/09/10 03:23:03 changed by euan

  • keywords set to MIDI.
  • status changed from closed to reopened.
  • resolution deleted.

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...

12/14/10 05:19:32 changed by euan

  • attachment ffado-audiofire_midi_fix.diff added.

Non conflicting fix

12/14/10 05:26:09 changed by euan

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.

01/22/11 07:06:06 changed by adi

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

01/22/11 07:31:47 changed by yves.g

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

01/22/11 13:31:24 changed by adi

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

01/22/11 23:45:44 changed by euan

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

01/23/11 01:57:04 changed by adi

  • status changed from reopened to closed.
  • resolution set to fixed.

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

01/23/11 04:44:18 changed by euan

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

01/23/11 05:11:31 changed by euan

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