snd-fireworks requires larger period sizes than FFADO

snd-fireworks requires larger period sizes than FFADO

[Dominic Sacré]

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

Re: snd-fireworks requires larger period sizes than FFADO

[Clemens Ladisch]

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

Re: 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/
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: snd-fireworks requires larger period sizes than FFADO

[Clemens Ladisch]

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

Re: 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel