I'm recording from a sound device using ALSA in Parallels (not sure if that makes a difference). Anyway I'm getting overflow callbacks despite 100% definitely always reading the maximum number of samples available, with plenty of CPU to spare.
Here is the output of my program (explanation below):
I'm not sure what is going on with the ALSA errors at the top. In the main chunk of output, the lone integers 1..10 are just the number of seconds that have passed. The Read, min: 0, max: 8192, actual: 8192 lines are in the read callback, printing the minimum, maximum and actual number of samples read. I have a 30 second ring buffer so can easily always read the maximum. Avail: xxx is something I added to alsa.c here:
At the end of the above output avail is equal to -32 (-EPIPE). I'm not sure why it doesn't print Avail: -32 but whatever. This means it calls instream_xrun_recovery(is, -32) which is as follows:
static int instream_xrun_recovery(struct SoundIoInStreamPrivate *is, int err) {
struct SoundIoInStream *instream = &is->pub;
struct SoundIoInStreamAlsa *isa = &is->backend_data.alsa;
if (err == -EPIPE) {
err = snd_pcm_prepare(isa->handle);
if (err >= 0)
instream->overflow_callback(instream);
} else if (err == -ESTRPIPE) {
while ((err = snd_pcm_resume(isa->handle)) == -EAGAIN) {
// wait until suspend flag is released
poll(NULL, 0, 1);
}
if (err < 0)
err = snd_pcm_prepare(isa->handle);
if (err >= 0)
instream->overflow_callback(instream);
}
return err;
}
In that function it calls snd_pcm_prepare() which returns 0, and hence calls my overflow callback. The thing is, the documentation for snd_pcm_prepare() say 0 means success.
Can you confirm that this code is correct? And do you have any idea why it is overflowing? These are the details for the device I was trying to use (at 48 kHz stereo LE16).
Intel 82801BA-ICH2, Intel 82801BA-ICH2: Direct hardware device without any conversions
id: hw:CARD=I82801BAICH2,DEV=0
channel layouts:
Stereo
sample rates:
8000 - 48000
formats: signed 16-bit LE
min software latency: 0.000166667
max software latency: 0.341333
As I said this is running through Parallels, which I know does funky things with isochronous USB. Maybe it does similar crazy things with on-board sound cards. Still I feel like I shouldn't be getting overflows.
I'm recording from a sound device using ALSA in Parallels (not sure if that makes a difference). Anyway I'm getting overflow callbacks despite 100% definitely always reading the maximum number of samples available, with plenty of CPU to spare.
Here is the output of my program (explanation below):
I'm not sure what is going on with the ALSA errors at the top. In the main chunk of output, the lone integers 1..10 are just the number of seconds that have passed. The
Read, min: 0, max: 8192, actual: 8192lines are in the read callback, printing the minimum, maximum and actual number of samples read. I have a 30 second ring buffer so can easily always read the maximum.Avail: xxxis something I added toalsa.chere:At the end of the above output avail is equal to -32 (-EPIPE). I'm not sure why it doesn't print
Avail: -32but whatever. This means it callsinstream_xrun_recovery(is, -32)which is as follows:In that function it calls
snd_pcm_prepare()which returns 0, and hence calls my overflow callback. The thing is, the documentation forsnd_pcm_prepare()say 0 means success.Can you confirm that this code is correct? And do you have any idea why it is overflowing? These are the details for the device I was trying to use (at 48 kHz stereo LE16).
As I said this is running through Parallels, which I know does funky things with isochronous USB. Maybe it does similar crazy things with on-board sound cards. Still I feel like I shouldn't be getting overflows.