Ticket #301 (closed bug: fixed)

Opened 10 years ago

Last modified 10 years ago

EAP/Dice -Devices on the new stack don't have playback

Reported by: arnonym Assigned to:
Priority: critical Milestone: FFADO 2.1
Component: devices/dice Version: FFADO SVN (trunk)
Keywords: Cc:
The device the bug applies to:

Description

Somewhere in the combination of the new firewire stack and Dice-based devices that use the EAP, there is a small glitch. Audio gets streamed to the device, but the device remains silent. As if the devices receiver is still switched to dry-running. Recording works fine.

Attachments

nosydump1-linux1394.txt (54.5 kB) - added by stefanr on 10/09/10 05:56:07.
traffic log during first ca. 15 seconds jackd runtime on raw1394
nosydump2-juju.txt (54.0 kB) - added by stefanr on 10/09/10 05:56:55.
traffic log during first ca. 15 seconds jackd runtime on firewire-core
nosydump1-nosydump2.diff (12.0 kB) - added by stefanr on 10/09/10 06:33:07.
diference between the previous two logs (timestamps and transaction labels removed)
nosydump3-nosydump2.diff (10.1 kB) - added by stefanr on 10/09/10 07:10:35.
juju log diffed against another another log from linux1394

Change History

10/09/10 05:56:07 changed by stefanr

  • attachment nosydump1-linux1394.txt added.

traffic log during first ca. 15 seconds jackd runtime on raw1394

10/09/10 05:56:55 changed by stefanr

  • attachment nosydump2-juju.txt added.

traffic log during first ca. 15 seconds jackd runtime on firewire-core

(follow-up: ↓ 2 ) 10/09/10 06:15:03 changed by stefanr

I attached two logs that were gathered with nosy, first from a successful startup of jackd with the older kernel drivers, second from a playback-silent-but-otherwise-successful startup of jackd with the newer kernel drivers.

ffc0: PCILynx card driven by nosy ffc1: Saffire PRO 24 ffc2: XIO2213A card driven by ohci1394 or firewire-ohci, respectively.

Using libffado 2.999.0-1897M, current libraw1394 from git at v2.0.5-18-g7416da6, kernel 2.6.36-rc4.

dest=0xffc0 traffic is only present in the first log because firewire-core does not give libraw1394 a /dev/fw* file for the PCILynx node. The effect for libraw1394 clients like ffado is the same: "" This is unimportant to the issue at hand.

A superficial glance over this does not reveal anything obvious to me, however I am not familiar with the DICE control protocol and audio streaming protocol. Next up: Edit the logs a little to allow for a straightforward diff...

(in reply to: ↑ 1 ) 10/09/10 06:18:15 changed by stefanr

Replying to stefanr:

The effect for libraw1394 clients like ffado is the same: ""

should have read "Could not parse config rom of node 0 on port ..."

10/09/10 06:33:07 changed by stefanr

  • attachment nosydump1-nosydump2.diff added.

diference between the previous two logs (timestamps and transaction labels removed)

10/09/10 06:44:31 changed by stefanr

I am noticing that nosydump's logging is incomplete, alas.

In another log of a successful linux1394 session, the final

dest=0xffc2, tl=...., write_quadlet_request, src=0xffc1, offs=0xffffe0000000, data=0x00000040, ack_pending

is there too. Note that nosydump1-linux1394.txt does actually show the write response to that request, i.e. it did happen but nosy or nosy-dump missed it somehow.

Furthermore, the spurious logging of cycle start and iso data (even though both were supposed to be filtered out in nosy-dump's default configuration) shows that nosy/nosy-dump are somewhat unreliable WRT what is logged and what not.

So, perhaps contents of iso data aside, there is actually no difference between nosydump1-linux1394.txt and nosydump2-juju.txt at all. (Definitely not in the asynchronous traffic.) What now?

10/09/10 07:10:35 changed by stefanr

  • attachment nosydump3-nosydump2.diff added.

juju log diffed against another another log from linux1394

02/13/11 08:17:44 changed by stefanr

I once again browsed the sources (mostly src/dice/dice_avdevice.cpp, src/dice/focusrite/focusrite_eap.cpp, src/libieee1394/ieee1394service.cpp, and libraw1394's read-write related raw1394 and firewire-cdev code) but nothing suspicious stood out. A developer who knows the EAP needs to continue with this bug and review or instrument the relevant code.

(follow-up: ↓ 7 ) 03/02/11 14:50:36 changed by stefanr

Rolf Anderegg found that some non-EAP devices are affected too. http://sourceforge.net/mailarchive/message.php?msg_id=27064854

Clemens identified isochronous buffer queuing problems in libraw1394's firewire-cdev backend to be the cause and submitted fixes. http://git.kernel.org/?p=libs/ieee1394/libraw1394.git;a=commitdiff;h=728f538340cd926ce0d6d757ccee0c165c9e3722 http://git.kernel.org/?p=libs/ieee1394/libraw1394.git;a=commitdiff;h=793b7639cfebc23b1e97bdec5946138e4c73bda2

This got Rolf's device going, also my Focusrite Saffire PRO 24. The libraw1394 fixes are expected to be released in libraw1394 v2.0.7 very soon.

(follow-up: ↓ 8 ) 03/03/11 02:09:49 changed by daniele

I found playback was working on my M-Audio Profire 610 with libraw1394 2.0.6, this is my setup:

  • kernel 2.6.37.1
  • libraw1394 2.0.6
  • libffado SVN rev 1958
  • Ricoh Co Ltd R5C832 IEEE 1394 Controller (rev 05)

(in reply to: ↑ 5 ) 03/03/11 06:09:52 changed by stefanr

Re comment 5: The pending libraw1394 fixes have been confirmed to be required and effective for Saffire PRO 40 too. (Niccolò Belli on ffado-user)

(in reply to: ↑ 6 ) 03/03/11 06:16:20 changed by stefanr

Re comment 6: Strange, M-Audio Profire 610 was said to have been affected by this bug. Seems there were more variables to the issue than we are aware of.

(follow-up: ↓ 10 ) 03/03/11 15:18:46 changed by darkbasic

The pending libraw1394 fixes have been confirmed to be required and effective for Saffire PRO 40 too. (Niccolò Belli on ffado-user)

I point out that 96KHz sample rate still doesn't work.

(in reply to: ↑ 9 ) 03/05/11 06:27:18 changed by stefanr

Re comment 9 by darkbasic:

I point out that 96KHz sample rate still doesn't work.

What does "doesn't work" mean? Muted playback, or can't start or sustain capture and playback, or...? Happens only with newer firewire kernel drivers, or with ieee1394 drivers too?

FWIW, capture and playback work for Saffire PRO 24 with Clemens' libraw1394 fixes also at 96 kHz.

03/05/11 11:25:20 changed by darkbasic

It means jackd doesn't start. I tested only new firewire stack (2.6.38).

03/08/11 13:33:32 changed by stefanr

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

The fixes have been released in libraw1394 2.0.7 now. http://thread.gmane.org/gmane.linux.kernel.firewire.devel/14850