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 <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: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver > > <hw_params.c> _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev