Ok, just to be clear: I *am* able to get the expected latency using jack (around 3.5ms
with a period=32 and nperiods=256).
but using my own alsa wrapper (and also using zita-alsa-pcmi) the latency is >170ms
here’s the output from hw_params:
Device: hw (type: HW)
Access types: MMAP_COMPLEX
Formats: S32_LE FLOAT_LE
Channels: 52 100 196
Sample rates: 32000 44100 48000 64000 88200 96000 176400 192000
Interrupt interval: 166-128000 us
Buffer size: 42666-256000 us
fokke
On Feb 6, 2016, at 17:27 , Adrian Knoth
<adi(a)drcomp.erfurt.thur.de> wrote:
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(a)thur.de
http://adi.thur.de PGP/GPG: key via keyserver
<hw_params.c>