Bug 505653 - Mono audio is only played to left side of stereo outputs
Summary: Mono audio is only played to left side of stereo outputs
Status: REPORTED
Alias: None
Product: kasts
Classification: Applications
Component: general (other bugs)
Version First Reported In: 25.04.1
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: bart
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-16 06:37 UTC by Be
Modified: 2025-08-02 23:01 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Be 2025-06-16 06:37:11 UTC
SUMMARY
Podcast episodes formatted as mono audio do not get played as dual mono on stereo outputs; output is only sent to the left side of the audio output.

STEPS TO REPRODUCE
1. Download a podcast episode with mono audio, for example https://feeds.soundcloud.com/users/soundcloud:users:545327328/sounds.rss (all recent episodes I tested 16-06-2025 reproduced this) 
2. Play podcast episode

OBSERVED RESULT
Audio only plays on left side of stereo outputs

EXPECTED RESULT
Audio plays on both sides of stereo outputs

SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 42
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0
Kernel Version: 6.14.9-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 4 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Intel® UHD Graphics 620

ADDITIONAL INFORMATION
Using Pipewire-Pulseaudio 1.4.4

I have reproduced this with both the onboard audio interface on my motherboard and the USB audio interface of a Traktor Kontrol S4 Mk3. For the latter, I have used pavucontrol to configure the profile to both "Analog Stereo 4.0 Output" and "Pro Audio" and could reproduce the bug with both configurations.

Workaround is to manually make the connection from Kasts to the right side of the stereo output with qpwgraph
Comment 1 bart 2025-06-16 07:56:01 UTC
Which audio backend is in use? You can check that in general settings
Comment 2 Be 2025-06-16 21:40:22 UTC
Ah, I didn't know there were multiple backends. I had been using the VLC backend. I switched to Qt Multimedia and cannot reproduce this bug.
Comment 3 bart 2025-06-18 16:54:20 UTC
I think I've seen an almost identical ticket in the past for another distro for one of the backends.
It's very likely related to the compiler flags and plugins that were enabled for the respective audio backends/libs.  So, apparently something changed in fedora.
Comment 4 Claire 2025-07-11 01:33:22 UTC
(In reply to Be from comment #2)
> Ah, I didn't know there were multiple backends. I had been using the VLC
> backend. I switched to Qt Multimedia and cannot reproduce this bug.

Want to confirm that QT Multimedia works but VLC does not. VLC pipes it only to one ear, while qt multimedia functions appropriately. Still, Kasts recommends using VLC as the backend. Is there anything that can be done about this?
Comment 5 bart 2025-07-11 07:11:19 UTC
(In reply to Claire from comment #4)
> Is there anything that can be done about this?

Since this is not a problem on other distros, this is very likely a fedora-specific issue with the out-of-the-box configuration of either vlc, pipewire, or some other package in the audio stack.  The only thing you can do is open a bug report to fedora to fix the default behaviour for mono sources.
Comment 6 Be 2025-07-11 17:00:49 UTC
Are you sure this is not a problem on other distros? Have you failed to reproduce the bug with the VLC backend on other distros?
Comment 7 bart 2025-07-11 17:11:15 UTC
Yes, I'm using kasts native on arch and through flatpak, and both are ok with mono sources and the vlc backend.
Comment 8 Be 2025-07-11 17:25:43 UTC
Claire, what distro are you using?
Comment 9 Lukas 2025-08-02 23:01:06 UTC
I'm seeing the same issue (also on Fedora 42).
In qpwgraph the output appears as "playback_AUX0" instead of "playback_FL" and "playback_FR".

It does not seem to be unique to kasts. While playing a mono mp3 file works fine in VLC directly, playing it in Kaffeine (also using libVLC) shows the same issue.

Kaffeine allows setting options for libVLC and there the problem goes away if I add "--stereo-mode=1" to the options. So apparently the default value of that setting seems to be incorrect.