washroomAccessFor.30
New member
I currently only play Street Brawl with some game sessions going hours without restarting Deadlock. I started playing the game again several weeks ago now and since I've noticed audio sync issues to the video recording. The game itself is fine while playing.
It's took me a while to decide to type up this report up as the first question is: "is it a steam issue, my system issue, or an actual Deadlock bug?" Well, I started over time testing with steam recording settings. Testing them all: every toggled on & off etc. When steam background recording released I played alot of Team Fortress 2 and at first I recorded to a HDD which caused audio sync issues due to improper speeds before I switched to a SATA SSD for storing recordings. Thus I even thought maybe the SSD is becoming faulty and for testing purposes even changed the recording folder to one on the OS NVMe.
I Type all of the previous paragraph to show that I have testing it as a steam/system issue as much as possible. So with that ticked off, what evidence is there that this is a Deadlock issue? As absence of evidence of one is not proof of the other.
Well, anytime I keep getting an issue playing Street Brawl I test out numerous bot standard matches. Just today I loaded up 5 bot standard matches in a row, leaving back into hideout after shooting near base (to avoid noise pollution) with Krill's gun & Mo's scorn (ability 1, it's instant audio with the visuals is useful here for demonstration). There was no audio issues at all in the recording.
I also confirm that loading into a party hideout does not cause this, as it was a question at a time whether it was Street Brawl and hideout loading together (both solo & party hideout tested). Booting up the game and waiting 20 minutes on the hideout did not have audio lag when I then abused the hell out of hideout Abrams (deserved btw).
Yet it only takes a 2nd round of street brawl for it to become noticeable in recordings. Hours later, the audio can be tens of seconds behind. I have attached 3 clips that demonstrate this with Mo's scorn ( is not scorn specific, just a good demonstration cue ) (headphones recommend):
There is one more thing to mention before I end by sharing the one extra test I have still to do (it's a workaround test, not a fix/information gathering test): I am on Linux Mint 22.3, 'steam -> settings -> background recordings -> record audio from... ' only allows system audio. However, by using the pipewire visual frontend UI qpwgraph (that is the name, yes) I can sever the connection between my output device & the recording, then create a direct line from Deadlock to the recording, thus making it only record game audio & nothing more.
Well, this does not make a difference to the recording. The audio async still occurs. Thought I should still share despite no difference. It was another test that I did after all.
Lastly, the next & final test I am to do is play Deadlock with background recording disabled but manually start/stop recording per match. While lag may start between Street Brawl rounds still, in theory it should reset the lag per match thus allows clips to still be 'good enough' in sync. I currently have clips from the last couple weeks that are... tens of seconds out of sync & probably will be deleted due to how annoying watching them are.
It's took me a while to decide to type up this report up as the first question is: "is it a steam issue, my system issue, or an actual Deadlock bug?" Well, I started over time testing with steam recording settings. Testing them all: every toggled on & off etc. When steam background recording released I played alot of Team Fortress 2 and at first I recorded to a HDD which caused audio sync issues due to improper speeds before I switched to a SATA SSD for storing recordings. Thus I even thought maybe the SSD is becoming faulty and for testing purposes even changed the recording folder to one on the OS NVMe.
I Type all of the previous paragraph to show that I have testing it as a steam/system issue as much as possible. So with that ticked off, what evidence is there that this is a Deadlock issue? As absence of evidence of one is not proof of the other.
Well, anytime I keep getting an issue playing Street Brawl I test out numerous bot standard matches. Just today I loaded up 5 bot standard matches in a row, leaving back into hideout after shooting near base (to avoid noise pollution) with Krill's gun & Mo's scorn (ability 1, it's instant audio with the visuals is useful here for demonstration). There was no audio issues at all in the recording.
I also confirm that loading into a party hideout does not cause this, as it was a question at a time whether it was Street Brawl and hideout loading together (both solo & party hideout tested). Booting up the game and waiting 20 minutes on the hideout did not have audio lag when I then abused the hell out of hideout Abrams (deserved btw).
Yet it only takes a 2nd round of street brawl for it to become noticeable in recordings. Hours later, the audio can be tens of seconds behind. I have attached 3 clips that demonstrate this with Mo's scorn ( is not scorn specific, just a good demonstration cue ) (headphones recommend):
- Deadlock_audio.01.mp4: Simply shows scorn as it should be (new game session straight into hideout); included for comparison so readers/devs need not look up how it should be as they read this report.
- Deadlock_audio.02.mp4: Shows that during round 1 of match 1 of street brawl in a new game session there is no noticeable audio recording delay with scorn. I believe the first round does not trigger anything, only subsequent rounds.
- Deadlock_audio.03.mp4: While subtle, round 2 of the same match already has scorn's audio cue lagging behind the visuals. Rewatch if not noticed at first view with the chaotic noise pollution, it is there.
There is one more thing to mention before I end by sharing the one extra test I have still to do (it's a workaround test, not a fix/information gathering test): I am on Linux Mint 22.3, 'steam -> settings -> background recordings -> record audio from... ' only allows system audio. However, by using the pipewire visual frontend UI qpwgraph (that is the name, yes) I can sever the connection between my output device & the recording, then create a direct line from Deadlock to the recording, thus making it only record game audio & nothing more.
Well, this does not make a difference to the recording. The audio async still occurs. Thought I should still share despite no difference. It was another test that I did after all.
Lastly, the next & final test I am to do is play Deadlock with background recording disabled but manually start/stop recording per match. While lag may start between Street Brawl rounds still, in theory it should reset the lag per match thus allows clips to still be 'good enough' in sync. I currently have clips from the last couple weeks that are... tens of seconds out of sync & probably will be deleted due to how annoying watching them are.
