611, 666, 704, 1.9551
> > min, mean, max, stddev: 651, 666, 687, 1.37784
> > min, mean, max, stddev: 650, 666, 689, 1.4738
> > min, mean, max, stddev: 609, 666, 722, 2.2253
> > min, mean, max, stddev: 656, 666, 680, 1.57805
> > min, mean, max, stddev: 643, 666, 683
Robert Bielik wrote:
> It works nicely if I either:
> 3. Pipe capture -> playback with a larger buffer size, such as 64.
It's possible that the hardware does not actually handles size 32 correctly.
> The rendering thread is (pseudo code):
>
> while (true) {
> if(capture_active) {
>snd_
tddev: 656, 666, 680, 1.57805
> min, mean, max, stddev: 643, 666, 683, 1.54424
>
> (which to me looks more than OK)
>
> > -Original Message-
> > From: Robert Bielik [mailto:robert.bie...@dirac.com]
> > Sent: den 15 januari 2018 17:41
> > To: alsa-user@lists
rceforge.net
> Subject: [Alsa-user] Strange i/o problem
>
> I have a strange problem: I'm trying to pipe audio input -> output using a I2S
> device @48000 Hz and 32 frames buffer size and 2 periods, to get as low a
> latency as possible.
>
> It works nicely if I eithe
I have a strange problem: I'm trying to pipe audio input -> output using a I2S
device @48000 Hz and 32 frames buffer size and 2 periods, to get as low a
latency as possible.
It works nicely if I either:
1. Use capture + playback and record capture to a wav file (sounds fine).
2. Use playback onl
