[LAD] RME madi latency

Adrian Knoth adi at drcomp.erfurt.thur.de
Sat Feb 6 16:27:15 UTC 2016


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 at thur.de  	http://adi.thur.de	PGP/GPG: key via keyserver

-------------- next part --------------
A non-text attachment was scrubbed...
Name: hw_params.c
Type: text/x-csrc
Size: 4986 bytes
Desc: not available
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20160206/85a7802e/attachment.c>


More information about the Linux-audio-dev mailing list