(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.