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) {
>
Yet more info, the output of snd_pcm_hw_params_dump and snd_pcm_sw_params_dump
(they look the same for both capture and playback):
ACCESS: RW_INTERLEAVED
FORMAT: FLOAT_LE
SUBFORMAT: STD
SAMPLE_BITS: 32
FRAME_BITS: 64
CHANNELS: 2
RATE: 48000
PERIOD_TIME: (666 667)
PERIOD_SIZE: 32
PERIOD_BYTES:
Ah, forgot to mention a couple of things, this is on a Raspberry Pi 3 with
Raspbian Stretch, the rendering thread is set to SCHED_RR with max priority,
the timing of the callback is typically (in microseconds):
min, mean, max, stddev: 655, 666, 680, 1.45639
min, mean, max, stddev: 656, 666,
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
