Paul Adolph wrote:
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.

  
No definitive help.  I don't know the internals, but I have a guess.  It probably leads the
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.
int snd_pcm_sw_params_set_avail_min ( snd_pcm_t pcm,


snd_pcm_sw_params_t params,


snd_pcm_uframes_t  val  

)


Set avail min inside a software configuration container.

Parameters:

pcm  PCM handle

params  Software configuration container

val  Minimum avail frames to consider PCM ready
Returns:
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.
Examples:
/test/latency.c, and /test/pcm.c.

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.