Ticket #315 (new bug)

Opened 8 years ago

Last modified 7 years ago

ffado-mixer: hardware mixing not working for Echo AudioFire 2 / Pre8

Reported by: roos Assigned to: arnonym
Priority: waiting for device info Milestone: Indeterminant (need device info)
Component: ffado-mixer Version: FFADO SVN (trunk)
Keywords: ffado-mixer, audiofire Cc:
The device the bug applies to:



Discovering devices...


14164760210: Warning (ieee1394service.cpp)[ 328] initialize: Could not set SPLIT_TIMEOUT to min requested (1000000)


14164760312: Warning (ieee1394service.cpp)[ 332] initialize: Set SPLIT_TIMEOUT to min requested (1000000) did not succeed


14164886245: Warning (fireworks_device.cpp)[ 134] discover: Using generic ECHO Audio FireWorks? support for unsupported device 'Echo Digital Audio AudioFire?2'


Starting DBUS service...


Running... (press ctrl-c to stop & exit)


screenshot-ffado-mixer-AudioFirePre8.png (59.6 kB) - added by wvengen on 05/04/12 16:19:56.

Change History

11/12/10 01:49:08 changed by roos

  • version changed from FFADO 2.0.1 to FFADO SVN (2.0 branch).

This is my firmware atm:

WDM driver 4.8 ASIO driver 4.8 Console 4.8 ARM firmware 4.8 FPGA 3.0.2

Maybe the firmware it to new (which is then also a bug in ffado) and maybe the FPGA should also be on 4.8 on my device...

11/15/10 05:51:55 changed by roos

Others report that the mixer works for them, at least with: Old firewire-stack, FFADO version 2.0.0-karmic~ppa1 (Ubuntu)

for example

11/20/10 02:51:17 changed by roos

The one who got this working on Ubuntu 9.10 (see previous commment) has firmware version 4.8. I have the same firmware, using Debian testing, new stack, but it isn't working yet.

11/20/10 02:52:36 changed by roos

BTW regarding the firmware (See previous messages) FPGA on version 3.0.2 seems to be normal and good.

12/09/10 14:45:09 changed by roos

ffado-mixer works on Ubuntu Lucid 10.04 (OLD STACK), same ffado version.

Difference seems to be old stack (Working) vs new stack (Not working)

03/02/12 04:00:10 changed by wvengen

I'm using Linux 3.0.0 which doesn't have the old stack. I'd still like to get the mixer working. Is there anything I could do to help with this?

03/02/12 04:22:19 changed by stefanr

I can't see how the version of kernel drivers would make any difference at all to ffado-mixer. ffado-mixer uses only very basic asynchronous I/O which is not sensitive to driver implementation details like the realtime isochronous audio I/O.

Most notably the version of kernel drivers won't cause a normally supported device model to be wrongly recognized as an unsupported model of the same class of devices. When the newer kernel drivers were introduced, there were trivial configuration issues on some distributions (and alas still exist on some distributions with some devices but AFAIK not with Audiofire devices) which would prevent recognition of the device _altogether_. But that wouldn't match the initial description of this ticket.

03/02/12 04:28:19 changed by wvengen

Hi, thanks for your reply! That clears up some rumours.

I'm using an Echo AudioFire? Pre8 and see the same behaviour (though I haven't tested with the old stack yet). These two 'min' warnings disappear when I run ffado-mixer as root. Setting the mixer values appears to work, and when I close and rerun the mixer the same values appear, so some state is remembered somewhere. But the device's response doesn't change at all (i.e. no changes hardware mixing that I can find).

I'll see if I can test the old stack with a 2.6 kernel to try if my hardware works at all.

05/04/12 04:47:13 changed by jwoithe

Has there been any further progress on this?

When you say that you (wvengen) see the same behaviour, could you describe this in a little more details? As I understand it, the problem is that ffado-mixer starts and you can do things with controls, but the device itself seems unaffected. Is that as it is?

I note that the configuration file doesn't explicitly mention an "AudioFire? Pre8". Could it be that part of the problem is that we need to add an entry for this device? To do that we need to determine the so-called model ID of the device. The easiest way to obtain this is to run

ffado-test ListDevices

and post the device list given.

05/04/12 16:18:37 changed by wvengen

  Node id  GUID                  VendorId     ModelId   Vendor - Model
   0       0x001486075b67dbdf  0x00001486  0x00000AF9   Echo Digital Audio - AudioFirePre8

There is actually an entry for this VendorId/ModelId? combination in /usr/share/libffado2/configuration called "AudioFire?8a". It also seems that the correct mixer interface is being displayed (I'll attach a screenshot later).

When I start ffado-mixer, the gui is shown correctly with sensible defaults (all sliders maximum, pan alternating, each input channel unmuted just to its own output channel).

Changing the sample rate results in a small click in on the device's output, so it reacts. Same for selecting the clock source.

When playing an output stream over Jack, pressing the 'Output' 'Pad' buttons turn down the volume. When playing an output stream over Jack, the volume 'Output' sliders work. When playing an output stream over Jack, the 'M'ute buttons do not work.

Depressing a 'Pad' button on the 'Input' tab makes the input level drop. 'Identify Device' on the 'Input' tab does not seem to do anything. 'Save Settings to Device' on the 'Input' tab does not seem to do anything. It does not make changes permanent.

When I change controls (sliders, mute buttons, pan controls), disconnect the device, kill ffado-dbus-server, and reconnect the device, I find that the control values (as changed) are visible. That means that controls are read and written to the device properly. The problem is that all of this gives no output. Only where mentioned do controls seem to have any affect. When starting jack and connecting input 1-2 to output 1-2, I do hear something, but that's software mixing.

This is all I can think of in testing right now. If there's anything more I can do to help, please let me know.

05/04/12 16:19:56 changed by wvengen

  • attachment screenshot-ffado-mixer-AudioFirePre8.png added.

05/04/12 16:27:02 changed by wvengen

To clarify: "The problem is that all of this gives no output" is about audio output, so I cannot get audio output using hardware mixing.

06/01/12 04:00:08 changed by jwoithe

Thanks for the additional information and sorry for the delay in getting back to this. Based on the most recent description, it seems that at least some of the ffado-mixer controls have an effect on the device (which is good). Audio sent to/from software using jackd also works. What doesn't seem to work is the hardware mixer, whereby one routes a physical input to a physical output inside the device using controls from ffado-mixer.

The attached screenshot shows the mixer settings for out 1/2. All inputs have their levels at maximum which I would assume should route all inputs to out 1/2 at maximum volume (given the pan settings, odd inputs go to out 1 while even inputs go to out 2). And yet despite these settings you get no output.

It is my understanding from past posts made to ffado-devel that this device should work, so that suggests one of two possibilities. The first is a hardware fault, but I don't really believe that given the symptoms reported. The second is that there's some mixer setting that needs to be activated which isn't. Unfortunately I don't own an Audiofire-2 which means I am not in a position to test this out or even comment on whether there is an obscure ffado-mixer setting that needs to be made. If there are any Audiofire-2 owners reading this, could you provide any feedback our guidance on these issues: to get hardware mixing from input 1 to output 1 is it only necessary to turn up that one fader in ffado-mixer, or is there a requirement that other things also be done?

There's one further thing which bothers me about all this, and that is related to the vendor/model IDs reported by your device. You say that you have the AudioFire?2; this should have a vendor/model ID of 0x1486/0xAF2. However, in comment 10 you report that instead the model ID is reported to be 0xAF9, which is a actually a second model ID we've seen associated with the AudioFire?8 interface. So for some reason your AudioFire?2 is claiming to be a late model AudioFire?8. At face value this doesn't really make sense and I can't really understand any way that this could happen unless for some reason your device was running the wrong firmware (which seems rather unlikely).

06/04/12 06:49:56 changed by wvengen

Hi jwoithe, thanks for replying. I'm not the original submitter of this ticket, but someone who sees a similar issue on his AudioFire? Pre8. So if anyone has an Echo AudioFire? device with working hardware mixing, please let us know! Especially when you're using the 'new' firewire stack.

06/04/12 07:10:49 changed by wvengen

  • summary changed from ffado-mixer: not working with supported device Echo Audiofire 2 to ffado-mixer: not working with supported device Echo AudioFire 2 / Pre8.

06/04/12 07:12:14 changed by wvengen

I plan to contact Echo support for this. Would it be useful to wait so that some (more) ffado developers can have a more in-depth look at this ticket?

06/04/12 07:43:48 changed by jwoithe

<cite> I'm not the original submitter of this ticket, but someone who sees a similar issue on his AudioFire? Pre8</cite>

Ah right, yes, I see. Thanks for clarifying.

Here's an attempt at summarising what this ticket actually refers to.

  • Recording from the interface works
  • Playback from the computer works
  • ffado-mixer presents a sensible interface which makes sense for the device, and control changes appear to be sent correctly to the device
  • Although controls appear to be set correctly, it doesn't appear possible to get the device to route inputs to outputs internally

That last point essentially summarises the bug that's the focus of this ticket. At least this is my understanding; please feel free to correct anything that's not true.

Prior to anyone contacting Echo I think we need to determine precisely which interfaces are implicated here (if for no other reason than to allow us to formulate sensible questions to ask). Are all AudioFires? affected, or just some? More importantly, is the existing FFADO code expected to work with the AudioFire?2/8, or are those interfaces sufficiently different to those the code was originally written against (which, if memory serves me correctly, were the AudioFire?4 and AudioFire?12) such that more work is needed to get the 2/8 working. To resolve these questions we need further feedback about the AudioFire? devices.

As far as developers looking into this ticket, I'm not sure who this might be. The people who originally wrote the driver have other real life things on their plate at present which prevents them having a lot of time for FFADO. It's difficult for me to investigate this at present because I have neither an AudioFire? device or documentation about them. But we're probably getting ahead of ourselves a bit here. Let's see if further reports come in about the AudioFire? devices and take things from there.

06/04/12 08:18:18 changed by wvengen

@jwoithe: thanks for your correct summary. I seem to have taken over the role as bug reporter (roos' last comment is from 2010), and narrowed it down to internal routing/hardware mixing. That has indeed become the focus of this bug.

Thanks for explaining the current development status. I hope to have a some time to look into this deeper somewhere in the next months. Gathering more information from other users seems like a good idea to me.

06/04/12 08:19:15 changed by wvengen

  • summary changed from ffado-mixer: not working with supported device Echo AudioFire 2 / Pre8 to ffado-mixer: hardware mixing not working for Echo AudioFire 2 / Pre8.

06/09/12 04:58:14 changed by wvengen

Just tried it with the old firewire stack on a 2.6.36 (-020636-generic) kernel. Exactly similar behaviour with ffado-mixer: controls work, internal hardware mixing doesn't appear to have any effect.

My firmware version is reported (by ffado-dbus-server) as: ARM version 0x05030000. I guess that means I have firmware version 5.3. I plan to test with other firmware versions (if I can get PCI passthrough working in a Windows VM).

06/09/12 05:35:31 changed by jwoithe

wvengen: thanks for your on-going testing. Your results with the old stack on 2.6.36 are certainly consistent with what Stefan said in comment 7. Like Stefan I cannot see any way in which the nature of the kernel stack could be causing the internal mixer to seemingly ignore the control values it's set to and your latest results back this up. The only remaining question is how to reconcile this with comment 5, where the tests results there seemed to imply that the only difference between a working and non-working setup was the kernel stack.

It's interesting you should bring up firmware versions, because as I was reading the first part of your message that's the first thing which came to my mind. Is there perhaps a device firmware dependency here, where some work and (for some unknown reason) some don't. Alas, testing is the only way to determine this and I'm grateful that you're willing to run through this for us.

08/24/12 05:24:26 changed by jwoithe

  • priority changed from minor to waiting for device info.
  • version changed from FFADO SVN (2.0 branch) to FFADO SVN (trunk).
  • milestone set to Indeterminant (need device info).

As eluded to previously, this ticket can only be solved with more information about the device. In practice this means more testing and experimentation. I'll adjust the priority and milestones to reflect this. The ticket remains open so it can be picked up on as further information comes to hand.

I've set the version to svn-trunk (was 2.0) since the problem affects svn-trunk in the same way, and at the end of the day it's trunk that will end up getting fixed.