* Playback underrun recovery
@ 2012-04-21 21:12 Paul D. DeRocco
2012-04-24 14:04 ` Clemens Ladisch
0 siblings, 1 reply; 2+ messages in thread
From: Paul D. DeRocco @ 2012-04-21 21:12 UTC (permalink / raw)
To: Alsa-devel
I've got a synth program outputting directly to the main hw PCM device, with
no intervening plugins. It uses about 75-80% of the time on one core, so it
normally doesn't underrun. Once in a while, other burdens on the system
trigger an underrun, and my program never recovers. My buffer contains two
periods of 256 stereo frames (with 32-bit samples), which at 96KHz comes out
to a little over 5.3ms total. When it fails, its CPU usage goes up to 100%
on that core, and it spits out bursts of 5.3ms of audio (two full periods,
not one), with about 4ms of silence between them. My top level code consists
of a loop that generates one period at a time:
int buf[512];
while (true) {
generate_samples(buf, 256); // generate 256 stereo frames
if (snd_pcm_writei(h, buf, 256) < 0)
snd_pcm_prepare(h);
}
The funny thing is that if I break to the debugger and then restart, I get
exactly one underrun as you would expect, and then it recovers. What could
cause it to get into a state where it fails every other time around the
loop, and then sucks up milliseconds of CPU time before it gets going again,
thus guaranteeing another underrun?
--
Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Playback underrun recovery
2012-04-21 21:12 Playback underrun recovery Paul D. DeRocco
@ 2012-04-24 14:04 ` Clemens Ladisch
0 siblings, 0 replies; 2+ messages in thread
From: Clemens Ladisch @ 2012-04-24 14:04 UTC (permalink / raw)
To: Paul D. DeRocco; +Cc: Alsa-devel
Paul D. DeRocco wrote:
> I've got a synth program outputting directly to the main hw PCM device, with
> no intervening plugins. It uses about 75-80% of the time on one core, so it
> normally doesn't underrun. Once in a while, other burdens on the system
> trigger an underrun, and my program never recovers. My buffer contains two
> periods of 256 stereo frames (with 32-bit samples), which at 96KHz comes out
> to a little over 5.3ms total. When it fails, its CPU usage goes up to 100%
> on that core, and it spits out bursts of 5.3ms of audio (two full periods,
> not one), with about 4ms of silence between them.
When a PCM device is (re)started, the buffer is initially empty, so you
need more CPU to fill it.
What is your start threshold?
> My top level code consists of a loop that generates one period at a time:
>
> while (true) {
> generate_samples(buf, 256); // generate 256 stereo frames
> if (snd_pcm_writei(h, buf, 256) < 0)
> snd_pcm_prepare(h);
> }
Is this the actual code? You should check if snd_pcm_writei() returns
that less than 256 frames have been written, and you should use
snd_pcm_recover(), and you should that one's return value, too.
Regards,
Clemens
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2012-04-24 14:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-04-21 21:12 Playback underrun recovery Paul D. DeRocco
2012-04-24 14:04 ` Clemens Ladisch
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.