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

[Takashi Sakamoto]

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