audio sync is completely off

[escalade]

Recording video works great, but audio is ahead of it's time. Any way to fix this? I'm using Pulseaudio 13.0.

[ammen99]

How much ahead is the audio? Something on the order of seconds or just slightly?

I am not doing too much to sync audio and video, but it has been working fine so far. Also, have you ever tried to use other tools (maybe under X or OBS)? Did it work fine here, or it needed adjustments?

[benciks]

When recording desktop audio, it's completely off, not in sync, almost feels like it gets somehow distorted. That is on swaywm running in arch linux.

[charlieegan3]

I've been playing with wf-recorder this evening, really neat project but I'm also experiencing this too.

I experience the audio being faster (as in sped up) than the video by about 1-2 seconds. It's clearly this is more noticeable in shorter videos.

What's strange is that when I went to record an example video to upload to this issue I switched and opened a youtube tab in Firefox, rather than using spotify. This was not out of sync, and, it made the spotify sound in sync even if the youtube video was paused in firefox. I have no idea what to make of that!

I am using pulseaudio 13.99.1-rebootstrapped

[escalade]

@charlieegan3

I noticed that as well, if I start off the video by playing something on Youtube then the audio is fine. Perhaps a 48000/44100 sampling rate issue?

[ghost]

I was experiencing the same extreme delay others have reported with pulseaudio, however with pipewire and pipewire-pulse the issue seems to have disappeared for me.

[pkillnine]

I also had the same issue recording hedgewars

[robstumborg]

I'm experiencing this issue out of nowhere now. I've changed nothing and now the audio is out of sync (sped up) when using monitor. When recording with a microphone, it's fine. Also, when recording without audio playing initially, and then beginning the playback when wf-recorder is already recording, this issue does not occur. Very strange.

On Arch Linux using swaywm, latest pipewire & pipewire-pulse.

[paul-ri]

Had the same issue. I solved it by setting the pipewire default sampling rate down to 44100Hz. The above sampling rate suggestion was a good hint.

Pipewire default sampling rate is 48000Hz and wf-recorder doesn't yet allow changing the audio codec parameters and is currently set at 44100Hz

Doc: https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Config-PipeWire#setting-sample-rates

# ~/.config/pipewire/pipewire.conf.d/pipewire.conf
context.properties = {
    default.clock.rate = 44100
}

Note: I had first created a ~/.config/pipewire/pipewire.conf but pipewire would timeout and fail to load. Sounds like a bug despite their doc suggesting it's a valid config file

Edit: On Arch Linux, swaywm, latest pipewire & pipewire-pulse too

[robstumborg]

@paul-ri

Thanks! This is super helpful. It looks like the pipewire configuration is working as intended. Apparently one must copy the entire config template into pipewire/pipewire.conf or otherwise use .d/* for partials.

Your solution worked for me, but only when I set the following:

default.clock.rate          = 44100
default.clock.allowed-rates = [ 44100 ]

[ammen99]

Does anyone still have this problem with latest master of wf-recorder? Default sample rate has been changed to 48000 and can be manually set to 44100 if necessary.

[Parollel]

@ammen99

Does anyone still have this problem with latest master of wf-recorder? Default sample rate has been changed to 48000 and can be manually set to 44100 if necessary.

I tested both 44100Hz and 48000Hz with wf-recorder 0.3.0-460d454 (Jan 21 2023, branch 'master'),using pipewire-pulse.In output files,audio is always 250ms faster than video. Edit: I recorded a longer video(10 minutes),and it seemed that the video and audio are in sync.

[traeanto]

hello, any solution for this? i use pipewire-pulse for the audio server. I tried recording a video but there is no sound, just video without audio.

>>> wf-recorder --audio alsa_output.pci-0000_00_1b.0.analog-stereo.monitor -f record.mp3 selected region 0,0 0x0 Setting codec option: crf=20 Setting codec option: preset=ultrafast Setting codec option: tune=zerolatency Using video filter: null [libx264 @ 0x7fd0f8002d00] using SAR=1/1 [libx264 @ 0x7fd0f8002d00] MB rate (4128000000) > level limit (16711680) [libx264 @ 0x7fd0f8002d00] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX [libx264 @ 0x7fd0f8002d00] profile High 4:4:4 Predictive, level 6.2, 4:4:4, 8-bit Output #0, mp3, to 'record.mp3': Stream #0:0: Video: h264, yuv444p(pc), 1366x768 [SAR 1:1 DAR 683:384], q=2-31 Stream #0:1: Audio: aac (LC), 44100 Hz, stereo, fltp, 128 kb/s [mp3 @ 0x7fd0f8000d40] Invalid audio stream. Exactly one MP3 audio stream is required. Failed to write file header Invalid argument

[Yutsuten]

Invalid argument

I think your issue is different. See this:

• https://github.com/ammen99/wf-recorder/issues/165

[ghost]

I am having this issue when using h264_nvenc. Some 0.5s off. With libx264 it's almost right. Somehow changing to h264_nvenc offsets it enough to be noticeable.

[camj2]

I'm experiencing the same issue. I tried both libx264rgb and libx265. Also tried libopus. The audio is always ahead of the video. I'm using pipewire-pulse. Is there a way to fix this?

[ammen99]

I know many people have encountered this issue so I decided to try and take a look at what could be going wrong. I made a small patch which seems to make the audio and video closer together at least on my desktop, can someone else with this issue try it and see whether it makes things any better? https://0x0.st/Xba8.diff

[0xVasconcelos]

@ammen99 just tried your patch and it works perfectly for me as well!

[ammen99]

Great @0xVasconcelos ! I'll merge it together with the Pipewire PR and then do the next release ;)

[0xVasconcelos]

@ammen99 but I noticed something very odd, it works, but only when I instantiate the wf-recorder for the second time. Context: I have a docker container running wayland with swaywm + pulse audio, capturing the screen headless and sending via SRT.

If I just start the container with the wf-record command it gets the same delay, but if I run a second one in parallel this one get sync!

With that hacky strategy works!

wf-recorder -d /dev/dri/renderD128 --codec hevc_vaapi --muxer mpegts   --framerate 30 --no-damage --audio -R 44100  -p b=3M -p tune=zerolatency -p low_power=1  -f /dev/null &
PID=$!
sleep 5
wf-recorder -d /dev/dri/renderD128 --codec hevc_vaapi --muxer mpegts   --framerate 30 --no-damage --audio -R 44100  -p b=3M -p tune=zerolatency -p low_power=1  -f "srt://..." &
sleep 5
kill -9 $PID

[ammen99]

Quite weird. Without the patch, does it work correctly with the same workaround?

[0xVasconcelos]

@ammen99 nope! Does not work, the patch made it possible

[ammen99]

Alright, that's interesting, I'll think a bit whether I am not missing something :) Maybe we can make it work the first time.

[0xVasconcelos]

I'm not very familiar with the codebase yet, but I will take some look later today. I would think in having frames buffered and the first instance process all of them, but just guessing

[0xVasconcelos]

@ammen99 btw, the patch breaks when using pipewire+pipewire-pulse

Assertion 'p' failed at ../src/pulse/simple.c:456, function pa_simple_get_latency(). Aborting.

[ammen99]

@ammen99 btw, the patch breaks when using pipewire+pipewire-pulse

Assertion 'p' failed at ../src/pulse/simple.c:456, function pa_simple_get_latency(). Aborting.

Try the full PR here, it adds direct pipewire support: #247

[ammen99]

@0xVasconcelos I fail to see what might be going wrong so that it works only the second time you try it. Maybe we don't need to check the stream latency at all? It might help if you could add a debug output (cout/cerr/whatever) in pulse.cpp, where we get the latency, to see what kind of values you are getting the first time when stuff doesn't work.

[0xVasconcelos]

@ammen99 now using pipewire+pipewire-pulse as backend I cant reproduce the problem anymore, it works instantly and in first try :)