Surround Sound Support

joe.blough · October 17, 2025, 6:03pm

I could be wrong but I could have sworn I saw qubes supporting surround sound when the computer is connected to an AVR on my old setups. Is this right, because on 4.2 and 4.3rc2 with a couple newer Z890 boards I only see HDA Intel PCH Digital Stereo (HDMI)?

alimirjamali · October 17, 2025, 6:18pm

Unfortunately the answer is no. Not only Qubes OS never supported over 2 channels, but also the sample rate of those two channels is limited to 44.1KHz (not even 48KHz). And 16 bit bit-rate. If you need/want better quality audio in specific qube, your best bet would be hardware pass-through (e.g. a dedicated external USB sound card or DAC) to the target qube and attaching speakers to it.

Some more info:

github.com/QubesOS/qubes-issues

Add support for 24-bit (S16LE) 48k audio (perhaps as separate installable package) (humble feature request)

opened 05:30PM - 21 May 22 UTC

tonsimple

P: default C: audio

### The problem you're addressing (if any) Availability of "modern" 48k, 24 b…it audio will improve compatibility with various audio equipment, quality of life features such as Pulse Equalizer (which really doesn't work very well with current Qubes 41k 16 bit setup) This can be particularly useful for users who work in headphones using external DAC which is "picky" about format modes and generally ability to at least choose among two most popular formats (48k 24 bit and 41100 in 16 bit) would resolve a lot of subtle but annoying woes for people who (like me) use Qubes as general purpose workstation and thus for music listening too. ### The solution you'd like Keep current "no negotiation, just raw PCMs being thrown" architecture. Separate pacat-simple-vchan-48k and separate module-vchan-sink-48k are made available as optional installs original pacat-simple-vchan slightly modified to check upon startup if the pacat-simple-vchan-48k was installed and if it in fact was, launches the 48k version instead of the regular one. User has to manually edit their pulseaudio configs in relevant template VMs to load module-vchan-sink-48k instead of regular one (people who care about "44.1k is causing me minor issues" are usually aware of how to do that) User is also responsible for configuring resampling properly across the path from VM to Dom0/audio-VM and to their playback tract ### The value to a user, and who that user might be While it is true that under normal conditions the difference between 44.1k is not reliably distinguishable from 48k 24-bit of same content (except perhaps under very particular conditions), when having to deal with idiosyncrasies of particular playback tracts it may become source of problems (admittedly minor ones). My current setup results in some content being resampled from 48 (or more)k down to 44.1k and then (because of my external headphone equalizer which doesn't approve of 44.1k on principle, but hey, it was affordable) gets resampled back to 48k which does result in a handful of unpleasant minor artifacts even if "best" resampling methods are used. Generally one is better off resampling 41.1k to 48k and then running the 48k content down to playback than the other way around, in my humble experience. Also pulseaudio's equalizer tends to work better with 48k 24-bit which currently makes it rather "un-Qubesly" alas (I experimented with that extensively since 3-ish version of Qubes and ended up buying a hardware equalizer) The suggested implementation does not add much complexity to the audio virtualization protocol itself: still no negotiation, no "million switches", does not burden the developers with decisions about when to go 48k or reconfiguring the template VMs It does however give users who are "Qubes all the way" a little bit more flexibility for slightly better quality of life I realize it is probably a low-priority consideration but hope one day to see it implemented

balko · December 18, 2025, 8:18am

How does it work when qube (Linux-based or Windows) sends 48kHz audio? Who does it resample it to 44.1kHz?

I think the sound issue (crackling) in R4.2 that I have with Windows 10 is due to 48<->44.1 conversion, but I do not know how to fix it.

alimirjamali · December 18, 2025, 10:37am

Honestly talking, full understanding and deep study of the workflow has been on my personal todo list. Code is available in qubes-gui-daemon, qubes-gui-agent-linux and qubes-gui-agent-windows repositories. I believe it is done at Pipewire level at this moment. But I am not certain.

balko · December 18, 2025, 3:22pm

I see, thanks for response.
Somewhere there we had a regression (in R4.2) that added crackling noises to all Windows 10 qubes for me. The output physical device does not matter in my case: analog, S/PDF, external card - all have the same sound issue.

If I install virtual sound card in Windows 10 qube, connect it to fedora qube via networking, and stream all sound from Windows 10 qube to fedora and play there on fly - it works without crackling. But I failed to make such setup without lags and huge delays to make a work-around for the issue.

arkenoi · December 19, 2025, 8:11am

I always have crackling noises in all my Qubes audio, regardless of guest OS type. Got used to it.

balko · December 20, 2025, 6:01am

Can you make an example recording somehow?

alimirjamali · December 20, 2025, 2:54pm

I have been looking at some Qubes audio code recently. And while I am at it, maybe we could look at this together. It might be fun.

Here is how the sample rate is decided in daemon side (dom0 or sys-audio):

github.com/QubesOS/qubes-gui-daemon

pulse/pacat-simple-vchan.c

main


      
          /* The Sample format to use */
          static pa_sample_spec sample_spec = {
              .format = PA_SAMPLE_S16LE,
              .rate = 44100,
              .channels = 2
          };

Here is how the equivalent sample rate is set in Linux based qubes (with current Pipewire workflow):

github.com/QubesOS/qubes-gui-agent-linux

pipewire/qubes-pw-module.c

main


      
          /* SPDX-FileCopyrightText: Copyright © 2019,2021-2023 Wim Taymans */
          /* SPDX-License-Identifier: MIT */
          
          #define QUBES_PA_SINK_VCHAN_PORT 4713
          #define QUBES_PA_SOURCE_VCHAN_PORT 4714
          
          #define QUBES_PA_SOURCE_START_CMD 0x00010001
          #define QUBES_PA_SOURCE_STOP_CMD 0x00010000
          #define QUBES_PA_SINK_CORK_CMD 0x00020000
          #define QUBES_PA_SINK_UNCORK_CMD 0x00020001
          #define QUBES_STREAM_RATE 44100
          
          #define QUBES_AUDIOVM_QUBESDB_ENTRY "/qubes-audio-domain-xid"
          #define QUBES_AUDIOVM_PW_KEY "org.qubes-os.audio-domain-xid"
          #define QUBES_PW_KEY_BUFFER_SPACE   "org.qubes-os.vchan-buffer-size"
          #define QUBES_PW_KEY_RECORD_BUFFER_SPACE   "org.qubes-os.record.buffer-size"
          #define QUBES_PW_KEY_PLAYBACK_BUFFER_SPACE   "org.qubes-os.playback.buffer-size"
          #define QUBES_PW_KEY_PLAYBACK_TARGET_BUFFER_FILL   "org.qubes-os.playback.target-buffer-fill"
          #define QUBES_PW_KEY_CAPTURE_TARGET_BUFFER_FILL   "org.qubes-os.record.target-buffer-fill"
          #define QUBES_PW_KEY_ASSUME_MIC_ATTACHED   "org.qubes-os.assume-mic-attached"

There is also a legacy Pulse module in the same repo. But I guess it would be better ignored.

And for Windows, I believe there is none. For Windows I believe an intermediate stubdomain is used to emulate Intel ich6 interface which Windows does not require a driver for.

Some code might be here:

balko · December 20, 2025, 5:47pm

Thank you for looking into it.

Yes, we should expect frequency to be hardcoded as 44.1kHz (as mentioned on github by @DemiMarie).

In Windows the user can select the “output” frequency in a wide range of values. But in case of Qubes OS they are working all the same, as it seems. I have the same windows qube restored from backup, so no drivers running inside this qube were changed.

So, the question that I think can be helpful: what exactly had changed in R4.2 compared to R4.1 with frequencies of audio-stack in dom0. I know that it was migrated from pulseaudio to pipewire, but what can be the source of this regression.