[FFmpeg-user] ALSA buffer xrun. (ALSA_BUFFER_SIZE_MAX overflow)

[Johann Rekowski]

On 03/17/2013 03:35 PM, Nicolas George wrote:
> Can you show the output of the following command:
>
> arecord -D hw:2,1 -f S16_LE -c 2 -r 44100 -v > /dev/null
------------------------------------------------------------------------------------------------------------
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Hardware PCM card 2 'Loopback' device 1 subdevice 0
Its setup is:
   stream       : CAPTURE
   access       : RW_INTERLEAVED
   format       : S16_LE
   subformat    : STD
   channels     : 2
   rate         : 44100
   exact rate   : 44100 (44100/1)
   msbits       : 16
   buffer_size  : 22052
   period_size  : 5513
   period_time  : 125011
   tstamp_mode  : NONE
   period_step  : 1
   avail_min    : 5513
   period_event : 0
   start_threshold  : 1
   stop_threshold   : 22052
   silence_threshold: 0
   silence_size : 0
   boundary     : 6207086186423386112
   appl_ptr     : 0
   hw_ptr       : 0
------------------------------------------------------------------------------------------------------------

Posting full output, just to have everything documented. I have to add 
that I am using a loopback *.asoundrc* script to record the sound that 
alsa produces. I wasn't able to record from hw:0,0 otherwise. Here's 
what *.asoundrc* contains:

------------------------------------------------------------------------------------------------------------
pcm.!default {
   type asym
   playback.pcm "LoopAndReal"
   #capture.pcm "looprec"
   capture.pcm "hw:0,0"
}

pcm.looprec {
     type hw
     card "Loopback"
     device 1
     subdevice 0
}


pcm.LoopAndReal {
   type plug
   slave.pcm mdev
   route_policy "duplicate"
}


pcm.mdev {
   type multi
   slaves.a.pcm pcm.MixReale
   slaves.a.channels 2
   slaves.b.pcm pcm.MixLoopback
   slaves.b.channels 2
   bindings.0.slave a
   bindings.0.channel 0
   bindings.1.slave a
   bindings.1.channel 1
   bindings.2.slave b
   bindings.2.channel 0
   bindings.3.slave b
   bindings.3.channel 1
}


pcm.MixReale {
   type dmix
   ipc_key 1024
   slave {
     pcm "hw:0,0"
     rate 48000
     #rate 44100
     periods 128
     period_time 0
     period_size *1024* # must be power of 2
     buffer_size *8192*
   }
}

pcm.MixLoopback {
   type dmix
   ipc_key 1025
   slave {
     pcm "hw:Loopback,0,0"
     rate 48000
     #rate 44100
     periods 128
     period_time 0
     period_size *1024* # must be power of 2
     buffer_size *8192*
   }
}
------------------------------------------------------------------------------------------------------------
I've been experementing for a long time (already a week) with the 
*period_size* and *buffer_size* numbers.
*period_size 32* and *buffer_size 640* were good values for a good audio 
playback with no noticable delay. Recording with those values though 
produced tons of ALSA buffer xruns and the outcome of the audio was 
screechy and totally disturbed. So I went up by the power of 2 on 
*period_size* (since higher values for buffer_size didn't work anymore) 
and came to a end on *1024* for *period_size* and *8192* for 
*buffer_size*. Higher values caused lag and screechy audio, lower values 
too *ON THE RECORDING*, the playback was normal from alsa, and the game 
I was playing was respoinding normally too, even on *32* and *640*.

arecord output kinda makes me wonder why it shows higher values than my 
values set in .asoundrc...
Why does it show different values?
> Also, the value of buffer_size inside alsa-audio-common.c may be
> interesting. You can get it by just adding:
>
> av_log(0, 16, "buffer_size = %d\n", buffer_size);
>
> at the proper place.

Sorry I am no C expert (yet) and have no idea where the proper place would be. All I know is that this line would log the bufsize number from alsa-audio-common.c.

> What does happen if you run two separate instances of ffmpeg: one for the
> audio, and one for the video, with the video one niced?
>
> Regards,
Recording with 2 seperate instances of ffmpeg seems to have passed my 
routine game run. No ALSA buffer xruns happened in that time. I ran this 
command:
/ffmpeg -f alsa -ac 2 -i hw:2,1 -acodec pcm_s16le -vn out.wav | ffmpeg 
-f x11grab -r 30 -s 1920x1080 -i :0.0 -vcodec huffyuv -an -threads 8 
out.avi/

Well I gotta say that my routine road was at max 5 min long and I 
reached a length of 4 min and 51 seconds. I usually did shorter routines 
since the buffer xruns came earlier than that. I haven't tested a longer 
play yet.
Recording with 2 instances is a bit annoying though, because the audio 
file is a bit out of sync. Matching the video with the audio after every 
part that I record could be a really annoying task that I'd like to 
avoid. Running 2 seperate instances of ffmpeg caused a delay of ~1 second.