Ticket #310 (closed bug: fixed)

Opened 10 years ago

Last modified 10 years ago

Echo Audiofire Pre8 does not work above 48000 Hz

Reported by: yves.g Assigned to:
Priority: major Milestone:
Component: devices/fireworks Version: FFADO SVN (2.0 branch)
Keywords: Cc:
The device the bug applies to:


Despite the possibility to change the sample rate to 96000 Hz or 88200 Hz (through ffado-mixer or ffado-test SetSamplerate), it is not possible to start jack with these sample rates:

grenier@syrinx:~$ jackd -d firewire -r 96000
jackd 0.120.1
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details

no message buffer overruns
JACK compiled with System V SHM support.
loading driver ..
04761461464:  (ffado.cpp)[  92] ffado_streaming_init: libffado 2.999.0-1913M built Oct 14 2010 13:23:38
jackd: src/libutil/TimestampedBuffer.cpp:1029: void Util::TimestampedBuffer::incrementFrameCounter(unsigned int, ffado_timestamp_t):
Assertion `nbframes == m_update_period' failed.

These test are done with ffado svn rev 1913.


packet_48.txt (2.3 kB) - added by euan on 11/03/10 08:51:40.
ISO Packet received at 48K Data size is 552 Byte
packet_96.txt (3.5 kB) - added by euan on 11/03/10 08:52:21.
ISO Packet received at 96K Data size is 840 Byte
patch_310_hack.txt (1.4 kB) - added by euan on 11/06/10 09:59:07.
Patch to apply a fix for 96000 operation.
Echo Audiofire Pre8 firmware bug.pdf (173.0 kB) - added by euan on 11/06/10 10:00:33.
Description of the problem.
patch_310fix.txt (2.9 kB) - added by euan on 02/08/11 07:29:38.
Fix candidate for Ticket 310

Change History

11/03/10 08:50:39 changed by euan

I have spent some time looking at this, and it looks to me like it is a firmware fault on the Echo device.

I am seeking some advice on how to proceed with this and would appreciate any suggestions.

When the device is used at 48K (or less) the system setup reports 17 In and Out devices. 8 Analog, 8 Digital and 1 MIDI = 17 Ports.

However when it is used at 96K it reports less devices for In and Out. 8 Analog, 4 Digital and 1 MIDI = 13 Ports.

This is the dimension.

Additionally, at 48K, the AmdtpReceiveStreamProcessor::getSytInterval returns 8 and at 96K it returns 16.

Thus, the DBS is calculated in AmdtpReceiveStreamProcessor?.h:

virtual unsigned int getMaxPacketSize() {return 4 * (2 + getSytInterval() * m_dimension);};

For 48K this is 552, and for 96K this is 840.

However, when we receive a Isochronous packet from the Echo Device, IN BOTH CASES the CIP header specifies a DBS value of 0x11 (17). Ultimately this causes the assertion error shown above.

If I make a simple HACK change in AmdtpReceiveStreamProcessor?.cpp:

enum StreamProcessor::eChildReturnValue AmdtpReceiveStreamProcessor::processPacketData(unsigned char *data, unsigned int length) {

struct iec61883_packet *packet = (struct iec61883_packet *) data; assert(packet);

// This is a hack to force the Echo Devices to work at 96000 packet->dbs = 13; unsigned int nevents=((length / sizeof (quadlet_t)) - 2)/packet->dbs;

Which forces the CIP header to 13 then the device will pretty much work correctly at 96K.

This is not a valid fix, as it will no longer work at any other rate - and we sometimes get packets that are only DBS=1 in size.

11/03/10 08:51:40 changed by euan

  • attachment packet_48.txt added.

ISO Packet received at 48K Data size is 552 Byte

11/03/10 08:52:21 changed by euan

  • attachment packet_96.txt added.

ISO Packet received at 96K Data size is 840 Byte

11/03/10 08:55:29 changed by euan

Notes WRT the packet attachments:

The data is printed out from within the putPacket call in StreamProcessor?.cpp and is just a dump of unsigned char *data of size length.

enum raw1394_iso_disposition StreamProcessor::putPacket(unsigned char *data, unsigned int length,

unsigned char channel, unsigned char tag, unsigned char sy, uint32_t pkt_ctr, unsigned int dropped_cycles)

11/03/10 08:58:26 changed by euan

In the example above, the hack fix is actually just this line:

packet->dbs = 13;

My formatting merged this into the comment above.

11/04/10 01:55:18 changed by cladisch

This might be a consequence of the fix of ticket #308: since it is not possible to switch the device to higher sample rates with standard AV/C commands, the device also does not bother to provice proper descriptors for these rates.

The solution would be to ignore the descriptors and use the EfcHardwareInfoCmd? command to read the channel count (m_nb_1394_playback/record_channels, m_nb_1394_play/rec_chan_2x/4x).

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

  • attachment patch_310_hack.txt added.

Patch to apply a fix for 96000 operation.

11/06/10 10:00:33 changed by euan

  • attachment Echo Audiofire Pre8 firmware bug.pdf added.

Description of the problem.

11/07/10 05:25:01 changed by euan

Just an addendum to clarify the patch I submitted yesterday.

This does provide a workable fix, with the patch in place, jackd runs properly at all the required frequencies, and I can successfully record across all 8 channels at 96000 from within Ardour.

02/08/11 07:29:38 changed by euan

  • attachment patch_310fix.txt added.

Fix candidate for Ticket 310

02/08/11 07:32:25 changed by euan

I believe I now have a workable fix for this issue. By determining the nevent value directly from the FDF setting we circumvent the Echo firmware problem completely. This will need to be tested extensively with non-echo devices to make sure it works in all cases.

02/10/11 04:07:32 changed by adi

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

Committed in r1952.

Works on my Alesis io14 (DICE), but we need to roll out the patch to a broader audience. Let's see how many things will break. ;)