[alsa-devel] snd-fireworks requires larger period sizes than FFADO
Hi,
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.
This is what JACK says when I try to start it with a period size of 128 samples:
configuring for 48000Hz, period = 128 frames (2.7 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: cannot set period size to 128 frames for capture
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?
Thanks,
Dominic
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.
Regards, Clemens
(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 wrote:
is there a strict requirement that the ALSA period is more than double of the FireWire interrupt period?
No. But the ALSA API promises that interrupts arrive at the end of a period (which always has a constant size), and with the FireWire packet sizes varying, this is the easiest way of ensuring that interrupts are delayed by less than half the period size.
The driver should dynamically reduce the interrupt interval for smaller periods.
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?).
This is already implemented by calling fw_iso_context_flush_completions().
It helps with PulseAudio (which predicts the correct time to poll), but is useless when the application relies on the interrupt to wake it up (e.g., Jack).
Regards, Clemens
Hi,
On Dec 01 2015 23:31, Stefan Richter wrote:
(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.)
For technical background, See "9.2 A lack of arrangement for severe latency" of my report written in summer 2014. https://github.com/takaswie/alsa-firewire-report
Users can do what they want and believe as approval. Although, I don't like to propose users just to change the value of INTERRUPT_INTERVAL and reduce the parameter of snd_pcm_hw_constraint_minmax() in sound/firewire/amdtp-stream.c. At a glance, it looks to resolve the issue and users are satisfied with smaller size of PCM buffer, while it may cause implicit and troble, as I've already described. I believe it worse that users are alienated from true issues and satisfied with inappropriate ideas.
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.
Please write patchset, then I'll review them and comment. Currently, my work focuses on enabling more devices to work with ALSA firewire stack, nothing others.
Regards
Takashi Sakamoto
participants (4)
-
Clemens Ladisch
-
Dominic Sacré
-
Stefan Richter
-
Takashi Sakamoto