Paul Adolph wrote:
No definitive help. I don't know the internals, but I have a guess.
It probably leads the
For playback I am using the ALSA callback to wake up a thread that
then feeds the ALSA ring buffer with a period-worth of samples using
snd_pcm_writei(). I've set snd_pcm_sw_params_set_avail_min() to one
period. The problem is that most of the time when my thread wakes up
and tries to write the data, snd_pcm_writei() fails with -EAGAIN, and
I must retry until it works.
Presumably this write failure is because there is not enough space in
the ring buffer, but then why did the ALSA callback fire in the first
place? As it stands my retries are eating needless amounts of CPU.
I'm very confused, please help.
amount so that on busy systems, underruns don't occur. You could try
setting it to 2 buffer
min and still writing only a single buffer. That way, you have a
buffer of slack.
You might have better luck trying this on the alsa-devel list. The
developers live there and they
know the internals. It is possible they will answer.
I went and looked at the function you are using.
Set avail min inside a software configuration container.
||Software configuration container
||Minimum avail frames to consider PCM ready
- 0 otherwise a negative error code
Note: This is similar to setting an OSS wakeup point. The valid values
for 'val' are determined by the specific hardware. Most PC sound cards
can only accept power of 2 frame counts (i.e. 512, 1024, 2048). You
cannot use this as a high resolution timer - it is limited to how often
the sound card hardware raises an interrupt.
Are you using a buffer size compatible with your card. It is possible
it is using the closest one and that is less than the buffer size you
have defined. Just a thought.