Re: [LAD] RME madi latency

From: Adrian Knoth <adi@email-addr-hidden>
Date: Sat Feb 06 2016 - 18:27:15 EET

On Sat, Feb 06, 2016 at 04:12:39PM +0000, Fons Adriaensen wrote:

> > That, helped thanks.
> > Unfortunately I’m still getting the same huge latency as before..
>
> Looks like a driver problem then...

Not impossible, but I fail to see how. Here is the relevant driver side:

        .channels_min = 1,
        .channels_max = 196,
        .buffer_bytes_max = OUTPUT_DMA_BUFFER_SIZE,
        .period_bytes_min = (32 * 4),
        .period_bytes_max = OUTPUT_DMA_BUFFER_SIZE,
        .periods_min = 2,
        .periods_max = 1024,

and according to some doc on the internet:

--- cut ---
buffer_bytes_max defines the maximum buffer size in bytes. There is no
buffer_bytes_min field, since it can be calculated from the minimum
period size and the minimum number of periods. Meanwhile,
period_bytes_min and define the minimum and maximum size of the period
in bytes. periods_max and periods_min define the maximum and minimum
number of periods in the buffer.

The “period” is a term that corresponds to a fragment in the OSS world.
The period defines the size at which a PCM interrupt is generated. This
size strongly depends on the hardware. Generally, the smaller period
size will give you more interrupts, that is, more controls. In the case
of capture, this size defines the input latency. On the other hand, the
whole buffer size defines the output latency for the playback direction.
--- cut ---

From my understanding, this allows userspace to request a buffer of
1ch*2periods*32samples.

Fokke, do you mind running the attached program?

Cheers

-- 
mail: adi@email-addr-hidden  	http://adi.thur.de	PGP/GPG: key via keyserver


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev

Received on Sat, 6 Feb 2016 17:27:15 +0100

This archive was generated by hypermail 2.1.8 : Sat Feb 06 2016 - 20:15:01 EET