Sync issue with varying audio delay progressively getting worse over time of the video

[jawhster]

Thank you for this repository. I am getting varying audio delays. In beginning of video, audio seems fine but audio delays keep getting progressively worse over the time of the video. I tried using itsoffset as referenced in another issue but since the sync issue varies over time, a consistent delay does not work. It can get audio synced in the middle of the video but then audio in beginning is behind and later in video it is ahead. Any ideas? Below is the bash script I use to call picam commands and below that is --dump-hw-params. Please let me know if need any additional information. Thank you again!

Bash script to run 5 minutes of video with a few sleeps before, during, and after

#!/bin/sh
# Record 5 minutes of video

sleep 3

echo ">> starting picam"
./picam --alsadev hw:1,0 --rotation 180 --recordbuf 90 &
sleep 3

echo ">> begin recording"
echo "dir=$1\nfilename=$2" > hooks/start_record
sleep 300

echo ">> finish recording"
touch hooks/stop_record
sleep 1
killall picam
sleep 3
echo ">> done"

Hardware dump
$ arecord --dump-hw-params -D hw:1,0
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:1,0":

ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE
SUBFORMAT: STD
SAMPLE_BITS: 16
FRAME_BITS: 16
CHANNELS: 1
RATE: [44100 48000]
PERIOD_TIME: [1000 5944309)
PERIOD_SIZE: [45 262144]
PERIOD_BYTES: [90 524288]
PERIODS: [2 1024]
BUFFER_TIME: [1875 11888617)
BUFFER_SIZE: [90 524288]
BUFFER_BYTES: [180 1048576]
TICK_TIME: ALL

arecord: set_params:1339: Sample format non available
Available formats:

• S16_LE

[francescovannini]

I have a similar issue when streaming for a long time over HLS. After about a night running uninterruptedly, the next morning Chrome browser refuses to play the stream entirely. ffplay shows an A-V sync of about -150 (meaning video is 150 frames behind audio). In fact, ffplay shows the A-V sync is drifting immediately as soon as picam is started, although the value is very small and unnoticeable in the beginning.
I believe this might be related to the sampling frequency of my cheap soundcard; picam tries 48kHz by default but the soundcard negotiates 44.1kHz (and probably isn't even very stable). It seems that passing
--alsadev plughw:1,0
is improving the situation; when picam requests 48kHz, the ALSA resampler actually provides 48kHz through software resampling even if the soundcard doesn't support it (or if it drifts itself due to a bad hardware clock).

[feacluster]

Anyone found a workaround? I have run into the same issue when live streaming to YouTube. Using a Samson go USB mic. My workaround is to place it in a bash script that pkills libcamera-vid every 20 minutes and restarts the livestream. But sometimes the pkill doesn't work. Maybe there is a more elegant solution?

#!/bin/bash

# nohup ./livestream.sh > /tmp/livestream.out 2>&1 &

card=$(arecord -l | sed -En 's/card\s([0-9]).*/\1/p') # this bizarrly keeps changing on reboot

nohup libcamera-vid -t 0 --width 1920 --height 1080 --bitrate 2000000 --framerate 30  --autofocus-mode default --codec libav --libav-format flv --libav-audio --audio-source alsa --audio-device hw:$card,0 --audio-bitrate 192000 --av-sync 200000 -n -o rtmp://a.rtmp.youtube.com/live2/xxx> /tmp/error.out 2>&1 &

for i in $(seq 1 10);
do
    sleep 1200
    pkill -f libcamera-vid
    sleep 5
    pkill -f libcamera-vid
    sleep 5
    nohup libcamera-vid -t 0 --width 1920 --height 1080 --bitrate 2000000 --framerate 30  --autofocus-mode default --codec libav --libav-format flv --libav-audio --audio-source alsa --audio-device hw:$card,0 --audio-bitrate 192000 --av-sync 200000 -n -o rtmp://a.rtmp.youtube.com/live2/xxxt > /tmp/error.out 2>&1 &
done

[iizukanao]

As for picam, please try setting the resolution to 1280x720 (using -w 1280 -h 720) instead of the default 1920x1080 and see if the situation improves.

@feacluster For libcamera-vid issues, I recommend reaching out to the libcamera-vid community for further assistance.

[iizukanao]

Also try using a lower fps like -f 20

If the recording problem persists, I think the Raspberry Pi is doing too much work.