[alsa-devel] snd-fireworks requires larger period sizes than FFADO

[Stefan Richter]

(adding Cc: Takashi Sakamoto who is currently working within
snd-firewire-lib)

On Nov 23 Clemens Ladisch wrote:
> Dominic Sacré wrote:
> > I'm trying to use an Echo AudioFire 4 with the snd-fireworks driver.
> > With FFADO the device works reasonably well at a period size of
> > 64 samples (on a PREEMPT_RT kernel), whereas with snd-fireworks the
> > lowest possible period size seems to be 256 samples.
> >
> > The lowest achievable analog roundtrip latency seems to be around 19ms
> > (at 2x256 frames), as opposed to 8.3ms with FFADO (at 2x64). Are there
> > any known limitations of the snd-fireworks driver in this regard?  
> 
> At the moment, the driver uses a minimum period size of 5 ms.
> 
> You could try reducing INTERRUPT_INTERVAL and the parameter to
> snd_pcm_hw_constraint_minmax() in sound/firewire/amdtp-stream.c, and
> recompiling the driver.

Dominic:
I have not tried it myself yet and I am not familiar with ALSA's
requirements, but perhaps a first step would be to reduce both the
INTERRUPT_INTERVAL and the third argument in the call to
snd_pcm_hw_constraint_minmax() to half of the original value.

Some background:

The IEEE 1394 (FireWire) packets, in which the inbound and outbound audio
streams are encapsulated, are transmitted at an average period of 125 µs.  

The driver instructs the OHCI-1394 controller to generate an interrupt
every N packets.  snd-firewire-lib currently chooses N = INTERRUPT_INTERVAL
= 16, giving an average period of 2000 µs between interrupts.

For reasons that escape me, snd-firewire-lib limits ALSA's period to 5000
µs minimum and unspecified maximum.  This way, two or sometimes three
FireWire interrupts happen within each ALSA period.

Actual FireWire packet processings deviates from the average of 2000 µs
because
  - there is a small jitter in the IEEE 1394 isochronous period,
  - there may be a delay between when the OHCI signals an interrupt to the
    CPU, the CPU performs the "top half" of the interrupt handler (just
    prepares the "bottom half" for execution and clears the OHCI's
    interrupt register), and when the CPU actually processes the packet
    buffer (in the "bottom half" of the interrupt handler, a.k.a.
    "tasklet").  Tasklets of other kernel drivers could defer execution of
    snd-firewire-lib's tasklet for some time.  (A PREEMPT_RT kernel
    replaces tasklets by threads which can preempt each other, thus I
    guess an RT kernel could reduce this part of jitter if the threads are
    prioritized accordingly.)

Clemens,
is there a strict requirement that the ALSA period is more than double of
the FireWire interrupt period?  Or could the ALSA period be less than
double, at least on PREEMPT kernels (let alone PREEMPT_RT kernels)?

Also, I believe to remember that you once said that instead of relying on
periodical interrupts from the OHCI, it might be better to switch to a
kind of polling scheme (i.e. process the IEEE 1394 packet buffer on an
own period = ALSA period?).  I suppose this would automatically allow for
very small ALSA periods.
-- 
Stefan Richter
-=====-===== ==-- ----=
http://arcgraph.de/sr/