Ticket #335 (new bug)

Opened 9 years ago

Last modified 6 years ago

Channel routing support for Echo Audiofire 2/4

Reported by: artfwo Assigned to:
Priority: waiting for device info Milestone: Indeterminant (need device info)
Component: devices/fireworks Version: FFADO SVN (trunk)
Keywords: Cc:
The device the bug applies to: AudioFire2

Description

AudioFire? 2 and 4 have support for "channel routing" (as it's named in the manual). This feature allows to redirect analog outputs to headphones for example. FFADO does not seem to support it.

I am not sure, but the source code for fireworks driver defines a discrete control called "ChannelMirror?", which looks like the feature i'm looking for. Trying to reach it through d-bus interface results in a error:

$ dbus-send --print-reply --dest=org.ffado.Control /org/ffado/Con
trol/DeviceManager/0014860a68bca89d/ChannelMirror org.ffado.Control.Element.Disc
rete.getValue
Error org.freedesktop.DBus.Error.UnknownMethod: Method "getValue" with signature
 "" on interface "org.ffado.Control.Element.Discrete" doesn't exist

My device doesn't seem to pass the hasMirroring() check, because its flags (0xA1) don't match the EFC_CMD_HW_MIRRORING_SUPPORTED mask. Perhaps, it's a different hardware feature, so I may be wrong here.

I'm going to attach a screenshot from the windows manual, which shows the required controls.

Attachments

af2routing.png (104.7 kB) - added by artfwo on 05/26/11 06:54:01.

Change History

05/26/11 06:54:01 changed by artfwo

  • attachment af2routing.png added.

05/26/11 23:13:21 changed by cladisch

I'd guess that the channel routing is controlled with IsoChannelMap?, which isn't implemented by FFADO.

04/01/12 08:12:11 changed by jwoithe

Is it possible to progress this ticket? Does the support of IsoChannelMap? require information about the device that we don't presently have? Or is it simply a case that someone familiar with the fireworks driver needs to sit down and add the code to support this using the various standards documents as a guide?

04/02/12 12:47:31 changed by cladisch

I've never actually tried to use that command, but it looks simple and obvious enough for the latter.

04/03/12 04:31:22 changed by jwoithe

  • version changed from FFADO SVN (2.0 branch) to FFADO SVN (trunk).
  • milestone set to FFADO 2.x.

Ok, given Clemen's feedback I'll set the milestone for this to 2.x - the timing of its implementation will be determined solely by the arrival of someone with this interface who can do the work.

It would be good to get this re-tested on FFADO trunk too - just in case the chances since the 2.0 branch make a difference. In any case, with development focusing on trunk I'll change the version to trunk since the problem almost certainly exists there too.

04/10/12 06:15:42 changed by jwoithe

  • priority changed from minor to waiting for device info.
  • milestone changed from FFADO 2.x to Indeterminant (need device info).

Set priority and milestone to reflect the reality of this ticket: that progress is only possible with further device information.

04/10/12 20:03:57 changed by artfwo

i'd love to provide any required device information. what is needed and how to get the required data?

04/10/12 22:29:23 changed by jwoithe

Assuming that Clemens is correct in comment 3, what is needed is for someone to sit down with the standards documents which describe this IsoChannelMap? command, determine how it works, work out how it might fit into the FFADO framework (something others could possibly help with once the details are known), and code up support for it in FFADO. I don't know where to get the description of the IsoChannelMap? command, but Clemens may be able to point us in the right direction.

Ultimately the writing of the IsoChannelMap? support would have to be done by someone with an AudioFire?2 device - otherwise debugging will be unworkable.

Before going to this effort though, it would probably be a good idea to determine that the AudioFire?2 really does use IsoChannelMap? for the functionality described in this ticket (and if so, how). This is really the "device information" that's required to advance this ticket. Beyond protocol analysis of the data on the wire (something which would involve a PCILynx firewire card and the nosy utility distributed as part of the Linux kernel source) I'm not sure there's any other way to approach this. Perhaps there are some device capability bits set somewhere as part of the fireworks protocol which could be probed instead - again, Clemens may have some ideas.

I don't own an AudioFire? device myself and I have no direct experience with the protocol it uses, so I can't check this out directly myself.

09/20/13 06:17:44 changed by jwoithe

Following work by Takashi Sakamoto which was concluded in r2408 it is expected that the subject of this ticket is now resolved. It would be good if others could retest with svn r2408 or later and confirm if the expected playback routing controls are now present and functional in ffado-mixer. If no further feedback is received we will assume the ticket to be resolved.