Arecord->FFMPEG works but FFMPEG w/ ALSA stutters?

Question

I am trying to stream audio from my Pi Zero and my I2s MEMS mic. I would like to stream using FFMPEG and ALSA (which I have already compiled) but I'm running into stuttering issues.

1. FFMPEG + ALSA

   ~/special/ffmpeg/ffmpeg -report -f alsa -ar 48000 -ac 2 -acodec pcm_s32le -i mic_sv -f lavfi -i testsrc -c:v h264_omx -c:a aac -ab 32k -bufsize 32k -f flv rtmp://209.85.230.23/live2/KEY

This results in constant stuttering and choppiness.

2. Arecord piped directly to FFMPEG

   arecord -Dmic_sv -c2 -r48000 -fS32_LE | ~/special/ffmpeg/ffmpeg -report -acodec pcm_s32le -i - -f lavfi -i testsrc -c:v h264_omx -acodec aac -ab 32k -bufsize 32k -f flv rtmp://209.85.230.23/live2/KEY

This results in a coherent audio stream, but with skipping every 5 seconds or so.

3. Arecord recorded to a wav file, piped into FFMPEG

   arecord -Dmic_sv -c2 -r48000 -fS32_LE -twav temp.v & ~/special/ffmpeg/ffmpeg -report -re -i temp.v -f lavfi -i testsrc -c:v h264_omx -ac 2 -acodec aac -ab 32k -bufsize 32k -async 2 -f flv rtmp://209.85.230.23/live2/KEY

This results in a perfect audio stream.

I don't know why #3 works but #2 and #1 cause problems. Any suggestions?

Answer 1

The main priority is to determine where the bottleneck applies. It could be with computational load or with excessive total bitstream rate. It would first be a good idea to eliminate the video, especially as you're doing nothing obvious to set its bitrate or framerate. You only have -f lavfi -i testsrc -c:v h264_omx for the video options. You don't say anything about testsrc.

All the video data in the RTMP multiplexed stream needs to be sent over your internet connection in a timely manner and data rate will have a big effect on the quality of your stream playback so you probably need to tune your video encoder. You can find the full list of video encoding options using ffmpeg -h encoder=h264_omx.

Try running ffmpeg without the audio, and then without the video while monitoring the CPU usage and final bitrate to see if either is excessive. Since you want an RTMP stream you should do this by replacing video or audio with a small black frame or with silence so you always have both audio and video in the multiplexed stream.

For example to reduce video load, use options like:

-f lavfi -i color=c=black:s=320x240:rate=10 -pix_fmt yuv420p -c:v h264_omx

This will encode a black 320x240 image at 10fps. To encode silent audio you can add a graph input like this:

-f lavfi -i anullsrc=channel_layout=stereo:sample_rate=44100

Also use the -loglevel debug to see more of what is happening and to check if any slow software format conversion filters are being auto inserted.

To be honest it sounds like a CPU bottleneck because the option that works best for you is to encode the audio and then after that encode the video and stream with the pre-processed audio. Your first two scenarios have the CPU doing both things at the same time. To reduce video encoding load you should look towards reduced frame rate, reduced frame size, lower bitrate, and any other speed setting optimizations on the encoder.