Re: [FFADO-devel] Firewire bus analysis - Digidesign 003 Rack

[Stefan R. <st...@s5...>]

> Date: Tue, 3 Jul 2012 19:03:02 +1000
> From: Damien Zammit <dam...@gm...>
> To: linux-audio-dev <lin...@li...>
> Subject: [LAD] Firewire bus analysis - Digidesign 003 Rack
> 
> Hi folks,
> 
> I have done some firewire bus analysis on the 003 Rack and posted last
> year some of my findings on ffado.org wiki.
[...]
> Today I got back into it and managed to modify Clemens' snd-dice
> driver to activate the 003R and made a standalone driver to play out
> of 2 channels!
[...]
> 2) I don't know why but the device spits out a request on the bus
> about 10 times per second which interrupts playback for very short
> intervals causing choppy playback.  I had a similar problem when
> trying to make the 003R work under ffado.  I have examined the
> behaviour of the device under windows and it does not generate these
> packets.
[...]

If these are asynchronous request packets, then the mere occurrence of
these packets is not the reason for choppy playback.  1394 bus arbitration
works such that the isochronous cycle period is always 125 µs as a moving
average.  Large asynchronous packets may increase the duration of one
isochronous cycle to more than 125 µs, but the next one or two cycles will
be accordingly shorter.

This isochronous cycle jitter amounts to less than 60 µs in the worst
case.  The jitter is compensated by (a) buffering and (b) timestamping of each
isochronous packet.  Obviously, the order of magnitude of this isochronous
cycle jitter cannot amount to audible gaps.

Instead, one of the following possible reasons could get you choppy
playback, in order of decreasing likelihood:
  - These packets are part of a protocol which the firmware expects you
    to go through and finish before streaming commences.
  - There is a firmware flaw in the 003 Rack.
  - You have got a very seriously bad OHCI-1394 link layer controller.

It is about the following packet dump from
http://subversion.ffado.org/wiki/digi003rack, right?

| dest=0xffc2 (PC), write_block_request, src=0xffc1 (003Rack), offs=0xffff00000040, data=[00007051]
|                                                              offs=0xXXXXXXXXXXXX
| data=[00007058] if the stream dies.
| where XXXXXXXXXXXX is a configurable address using a control packet
| which I have worked out.

AFAICT this is something private; if you cannot derive its meaning by
protocol analysis of the Windows driver, you need to ask Digidesign.
-- 
Stefan Richter
-=====-===-- -=== ---==
http://arcgraph.de/sr/