Alsa Buffer overrun while playback of audio

Question

I have connected IMX board to pc back to back. I am running a binary in board which sends audio frames every 5.7ms with 1024 bytes. The pc receives the frames and writes using

printf("snd_pcm_avail %d \n",snd_pcm_avail (FMWK.FMWK_Handler.playback_handle));

err = snd_pcm_writei(FMWK.FMWK_Handler.playback_handle, OutputPointer, PERIOD_BYTES);

When the playback is happening, after every 6seconds i get broken pipe

Logs when sucessful playback is running

snd_pcm_avail 32 
snd_pcm_avail 17 
snd_pcm_avail 81 
snd_pcm_avail 25 
snd_pcm_avail 89 
snd_pcm_avail 32 
snd_pcm_avail 17 
snd_pcm_avail 81 
snd_pcm_avail 32 
snd_pcm_avail 17 
snd_pcm_avail 81 
snd_pcm_avail 25 
snd_pcm_avail 89 
snd_pcm_avail 32 
snd_pcm_avail 17 
snd_pcm_avail 81 

Approximately it is decreasing by 56 When after 5 seconds the avail increases and the buffer overflows the configured limit of buffer_size=256

Logs:

snd_pcm_avail 89 
snd_pcm_avail 112 
snd_pcm_avail 96 
snd_pcm_avail 120 
snd_pcm_avail 104 
snd_pcm_avail 129 
snd_pcm_avail 153 
snd_pcm_avail 137 
snd_pcm_avail 160 
snd_pcm_avail 184 
snd_pcm_avail 168 
snd_pcm_avail 193 
snd_pcm_avail 176 
snd_pcm_avail 201 
snd_pcm_avail 224 
snd_pcm_avail 209 
snd_pcm_avail 232 
snd_pcm_avail 217 
snd_pcm_avail 240 
snd_pcm_avail -32 
   (AVB Info)     12:26:11 PM.606306  (Slave)               ==> Broken pipe
snd_pcm_avail 256 
snd_pcm_avail 48 

I have set period_size as 128

I am not sure whether iam missing something in initial configuration of snd_pcm? It is 44.1khz audio.

Answer 1

What happens there is, that your program can not keep up with the playback of the PCM data by the device. When the "Broken pipe" happens the audio device it waiting for new samples, but your program didn't deliver them in time.

The situation you ran into is the bane of online audio systems; unfortunately the existing Linux audio architecture (ALSA) does not a very good job; PulseAudio + RealtimeKit tried (IMHO not very successfully) to plaster over the cracks, by doing weird and crazy voodoo to not starve ALSA drivers; things get not better by some drivers being broken and not reporting the position of the playback head properly.

In your case here are two things you can do:

• Use larger frames (more samples in a buffer)
• Queue more frames (queue several buffers) and keep a minimum number of frames in the queue

Answer 2

Audio devices typically have their own sample clock which is not synchronized with the system clock.

So you cannot use the system clock to control how fast to send samples to the device; it will run either too fast or too slow on almost all systems.

To send samples at the correct speed, just try to write your samples as fast as possible; snd_pcm_write* will automatically wait if the buffer is full.

If you cannot control the sender's speed from the receiver (because they are not on the same machine, and you do not have a protocol that provides feedback), you have to measure the relative speeds of the sender and receiver, and resample the data appropriately.