Portmaster Games sound out of sync

[genti7]

Games like GTA3 and GTA vice city run ok but sound comes with delay. This was also an issue with banana but was later fixed in pixie. If i remember back then the issue had something to do with pipewire.config

[miuirussia]

I confirm this bug, in portmaster discord reported this: Discord

[xonglebongle]

This has been addressed by removing the background service called muspeaker from the audio stack when launching titles that are sensitive to timing and frequency changes. So in this instance the “voices” in certain games now line up with the actors during cutscenes. The fix will come with the upcoming 2508.1 Canada Goose when it is ready.

This was just a small oversight on our side to reduce the amount of “squelching” you would hear switching between content and the frontend. The interaction between a long buffered background audio stream and the content audio stream was just not playing nice with each other.

Why it was happening?

• muspeaker opened a persistent playback stream at 48 kHz
• Certain content outputs at 32 kHz. Therefore PipeWire resampled 32kHz up to the sink of 48kHz… while muspeaker frequency pinned the graph at 48kHz.
• The result was that cutscene dialogue arrived late relative to video because the path contained hundreds of milliseconds of extra buffering.
• If muspeaker was killed, the “desync” disappeared, but the graph was then free to switch sample rate when content changed. That rate change produced subtle pops or clicks during transitions.

PipeWire information

The live graph via pw-top confirmed the above:

R 42 512 48000 … S32LE 2 48000 alsa_output.…card0.stereo-fallback
R 52 512 48000 … S16LE 2 48000 + alsa_playback.muspeaker
R 58 640 32000 … F32LE 2 32000 + alsa_playback.re3

And the sink exposed a large maximum latency:

node.max-latency = 4096/48000 # ≈ 85ms

That combination explains audio arriving late in some content.

Technical notes

• I tried forcing muspeaker to match the game’s frequency. That did not work.
• I tried adjusting PipeWire quantums. That did not work either.
• I tried changing the number of samples and periods that muspeaker requested. Again, that also did not work.
• Other variations were attempted with node.latency, resampler quality and all sorts of other weird and wacky changes.
  • These either had no effect or introduced other regressions. (eurgh)
• The only reliable way to remove the dialogue delay without side effects was to remove muspeaker from the playback path altogether.

Okay, cool, the fix?

The following has been changed, not without side effects though:

• Removed muspeaker entirely from the audio stack.
• Kept the default audio sink as the system output and let PipeWire handle resampling from 32 kHz content as needed.

What this means for you

If you experienced audio latency in certain content then this was surely the cause. With muspeaker removed completely PipeWire is able to automatically adjust frequencies and sample rates accordingly.

You may still hear very subtle pops when the device switches sample rate. That is the audio graph renegotiating a frequency rate and is usually brief. You can’t have your cake and eat it too… So yes, it was a background audio stream quietly holding hundreds of milliseconds of audio in a queue and content having to fight through it.