Ticket #361 (new bug)

Opened 8 years ago

Last modified 8 years ago

Echo Audiofire12: sometimes device locks i/o converters.

Reported by: picander 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:


Sometimes it happens that the device completely mutes outputs. Streaming in/out works perfectly (i can read input and send output through jack/baudline) but simply no audio comes out from the device. The strange thing is that front VU leds don't turn on neither input or output, even if jack reads correclty incoming streams.

Can you suggest me some useful info to post when i have the device in "locked mode" ?

Change History

08/31/12 07:13:28 changed by jwoithe

The first thing to do is to try with FFADO trunk. The version reported against (2.0.1) is quite old now and it is likely that the development trunk will behave differently (although it may still not be correct).

Could you also indicate which firmware version is loaded into your Audiofire12?

Note too that the 2.0 branch of FFADO is not under development any more. All attention is (and will remain) on trunk. The up-coming 2.1 version will be based on trunk, as will subsequent versions. This is one reason why testing with trunk for the reported behaviour is required.

Assuming the lockup occurs with trunk, can you deduce any particular sequence of events which leads to the apparent lockup?

08/31/12 12:12:56 changed by picander

  • version changed from FFADO 2.0.1 to FFADO SVN (trunk).

Sorry, forgot to specify i'm using trunk :#)

I'm using latest releases of libavc1394 and libraw1394. There is no sequence I can identify at the moment, it's really random and happens after the device is turned on for days

09/03/12 06:18:57 changed by jwoithe

Thanks for updating the version field and clarifying the FFADO version in use.

Is there any easy way to determine the firmware version in your AF12? We have reports that firmwares any more recent than 4.8 don't work with FFADO (see ticket #360). I don't think this is your problem though because the symptoms of a firmware incompatibility is a complete failure of the streaming system to start. In your case the data streaming appears to be working normally.

In the fault condition, do inputs work correctly? That is, if you put a signal into a device input do you see that audio coming out of jack/FFADO? Put another way, is it only the device outputs which appear muted, or are the inputs also muted?

Once the fault condition occurs, what do you need to do to make the AF12 work correctly? For example, is a power cycle sufficient, or do you need to leave the device for a while before powering it back up again?

In many respects the symptoms appear consistent with an intermittant internal fault in the AF12 itself which is possibly triggered by heat. It may be possible to disprove this though. You mentioned that when the fault condition occurs the front level LEDs stop responding to inputs. So what you could do is turn the unit on and confirm that sending signal into an input of your choice causes the LEDs to function. Then leave the AF12 on for several days without FFADO running, checking periodically that the signal still produces LED activity. If the LED activity ceases at some point we have effectively removed FFADO from the equation.

In the meantime I'll keep thinking about other things we could try to get to the bottom of these observations.

10/01/12 00:05:56 changed by picander

I noticed I can make the device work again without a power cycle simply changing the sampling rate to 96KHz and coming back to 48KHz. This reinitializes the device some way, infact I can hear a strong bump when switching between these two sampling rates. Strangely this doesn't happen when switching between 44.1 and 48.

Can you tell me looking in the code if switching to/from 96KHz changes something special?

10/01/12 01:04:44 changed by jwoithe

In many ways this is surprising - if changing the rate to 96 kHz has this effect I would have expected any sample rate change to do so. Out of interest, what if you try switching to 88.2 kHz: does that reinitialise things in the same way that going to 96 kHz does?

As far as setting the sample rate goes, as far as I can tell all sample rates are treated the same, at least by FFADO. Perhaps the device itself does something behind the scenes but we don't see any of that. I note that going to 96 kHz from 44.1 kHz or 48 kHz amounts to a change to a 2x rate from a 1x rate. Since some things (such as ADAT and AES/EBU) change at 2x rates perhaps the device does do something in this case which has the side effect of unlocking what it is that's locked up.