No sound playback devices available after in-place upgrade to 4.2 #8560

moonlitOrca · 2023-10-02T23:08:53Z

Qubes OS release

4.2RC3

Brief summary

After update to QubesOS 4.2, I am no longer generally able to play any audio or have sound, and this appears to be because the audio device is no longer recognized as an output. This also causes any video that I attempt to play to hang forever as it seems that the player (VLC for example) attempts to play sound and gets some sort of error which causes the (visual parts as well) the video itself to hang. Very occasionally, a reboot seems to allow sound to work until I shutdown.

Steps to reproduce

Upgrade to QubesOS 4.2 from 4.1 using the script.
Boot and attempt to play any video in any VM, or attempt to change the output device and see that the internal speakers do not appear as a device.

Expected behavior

Sound worked perfectly on 4.1, and so I expected the same would be true of 4.2. Perhaps some configuration in the script is not being done correctly to link the new pipewire infrastructure for dom0?

Actual behavior

Sound output is no longer supported. Very occasionally on boot, it does seem to work. I posted on the forums here: https://forum.qubes-os.org/t/audio-no-longer-works-at-all-in-dom0-and-vms-after-upgrading-to-4-2/20839/6 and it seems that others have had the same issue, though some seem to have been able to fix it from the terminal. This did seem to work for me for one boot, but then no longer worked. I very strongly suspect that this is an issue with the update script, so I could simply clean install QubesOS 4.2, but then I would be unable to test any fix for the bug, so I am waiting on that option :-)

andrewdavidwong · 2023-10-04T01:41:53Z

Possibly related or duplicate issue: #8495

3hhh · 2023-12-28T16:31:30Z

I'm also affected by this, but my audio device is shown in pavucontrol.

verygreen · 2023-12-31T23:35:43Z

I wonder if running a qube with pulseaudio-qubes helps you the same as it does for me?

DemiMarie · 2024-01-01T02:16:42Z

@moonlitOrca @verygreen Can you provide the output of systemctl --user status pipewire.service pulseaudio.service?

verygreen · 2024-01-01T02:42:54Z

in dom0 I assume?

● pulseaudio.service - Sound Service
     Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; preset: enabled)
     Active: active (running) since Fri 2023-12-29 23:26:21 EST; 1 day 22h ago
TriggeredBy: ● pulseaudio.socket
   Main PID: 7730 (pulseaudio)
      Tasks: 7 (limit: 9436)
     Memory: 16.4M
        CPU: 10min 47.808s
     CGroup: /user.slice/user-1000.slice/[email protected]/session.slice/pulseaudio.service
             ├─7730 /usr/bin/pulseaudio --daemonize=no --log-target=journal
             └─7902 /usr/libexec/pulse/gsettings-helper

Dec 31 17:12:05 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.
Dec 31 17:12:05 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.
Dec 31 19:27:41 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.
Dec 31 19:27:41 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.
Dec 31 20:25:20 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.
Dec 31 20:25:20 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.
Dec 31 20:56:34 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.
Dec 31 20:56:34 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.
Dec 31 21:26:38 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.
Dec 31 21:26:38 dom0 pulseaudio[7730]: Disabling timer-based scheduling because running inside a VM.

● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled)
     Active: active (running) since Fri 2023-12-29 23:26:18 EST; 1 day 22h ago
TriggeredBy: ● pipewire.socket
   Main PID: 7063 (pipewire)
      Tasks: 3 (limit: 9436)
     Memory: 3.9M
        CPU: 222ms
     CGroup: /user.slice/user-1000.slice/[email protected]/session.slice/pipewire.service
             └─7063 /usr/bin/pipewire

Dec 29 23:26:18 dom0 systemd[7055]: Started pipewire.service - PipeWire Multimedia Service.

DemiMarie · 2024-01-01T02:49:19Z

Nope, in the affected VM @verygreen.

verygreen · 2024-01-01T02:50:31Z

"Affected"? as in while the sound does not work?

For me external action (starting sound in pulseaudio-enabled VMs) fixes all other VMs

DemiMarie · 2024-01-01T02:50:51Z

@verygreen does the fix persist across a dom0 reboot?

verygreen · 2024-01-01T02:57:15Z

Unit pulseaudio.service could not be found.
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/user/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sun 2023-12-31 18:36:17 EST; 3h 15min ago
TriggeredBy: ● pipewire.socket
   Main PID: 631 (pipewire)
      Tasks: 3 (limit: 4619)
     Memory: 7.0M
        CPU: 36ms
     CGroup: /user.slice/user-1000.slice/[email protected]/session.slice/pipewire.service
             └─631 /usr/bin/pipewire

Dec 31 18:36:17 untrusted pipewire[631]: mod.qubes-audio: Unknown id 15
Dec 31 18:36:17 untrusted pipewire[631]: mod.qubes-audio: Unknown id 17
Dec 31 18:36:17 untrusted pipewire[631]: mod.qubes-audio: Unknown id 15
Dec 31 18:36:17 untrusted pipewire[631]: mod.qubes-audio: Unknown id 15
Dec 31 18:36:57 untrusted pipewire[631]: mod.qubes-audio: Unknown id 17
Dec 31 18:36:57 untrusted pipewire[631]: mod.qubes-audio: Unknown id 17
Dec 31 18:37:02 untrusted pipewire[631]: mod.qubes-audio: Unknown id 17
Dec 31 21:51:39 untrusted pipewire[631]: mod.qubes-audio: Unknown id 17
Dec 31 21:51:39 untrusted pipewire[631]: mod.qubes-audio: Unknown id 17
Dec 31 21:51:42 untrusted pipewire[631]: mod.qubes-audio: Unknown id 17

this is now has the sound is working (I restarted this qube for other reasons after doing pulse-enable qube start)

now this one below had sound working for some time but I just tested and it does not have it workign anymore again, it was only started at dom0 startup time.

Unit pulseaudio.service could not be found.
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/user/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Fri 2023-12-29 23:26:21 EST; 1 day 22h ago
TriggeredBy: ● pipewire.socket
   Main PID: 589 (pipewire)
      Tasks: 3 (limit: 1083)
     Memory: 8.8M
        CPU: 4min 34.702s
     CGroup: /user.slice/user-1000.slice/[email protected]/session.slice/pipewire.service
             └─589 /usr/bin/pipewire

Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Overrun: asked to write 3764 bytes, but can only write 0
Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Underrun: asked to read 3764 bytes, but only 0 available
Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Overrun: asked to write 3764 bytes, but can only write 0
Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Underrun: asked to read 3764 bytes, but only 0 available
Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Overrun: asked to write 3764 bytes, but can only write 0
Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Underrun: asked to read 3764 bytes, but only 0 available
Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Overrun: asked to write 3764 bytes, but can only write 0
Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Underrun: asked to read 3760 bytes, but only 0 available
Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Overrun: asked to write 3760 bytes, but can only write 0
Dec 31 21:55:06 work pipewire[589]: mod.qubes-audio: Underrun: asked to read 3764 bytes, but only 0 available

Let me try on other machine if the "fix" is persistent across restarts (it probably does not), I'll report in a bit

verygreen · 2024-01-01T04:46:50Z

Well, the other machine does not work.

In a qube where I switch to pulseaudio-qube instead of pipewire, audio applications that start hang on attempt to audio output.
the systemctl output is:

○ pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; disabled; preset: disabled)
     Active: inactive (dead)
TriggeredBy: ○ pipewire.socket

● pulseaudio.service - Sound Service
     Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; preset: disabled)
    Drop-In: /usr/lib/systemd/user/pulseaudio.service.d
             └─30_qubes.conf
     Active: active (running) since Sun 2023-12-31 23:40:28 EST; 52s ago
TriggeredBy: ● pulseaudio.socket
    Process: 1414 ExecStartPre=/usr/bin/qubesdb-read -w /qubes-audio-domain-xid (code=exited, status=0/SUCCESS)
   Main PID: 1415 (pulseaudio)
      Tasks: 2 (limit: 374)
     Memory: 7.7M
        CPU: 75ms
     CGroup: /user.slice/user-1000.slice/[email protected]/session.slice/pulseaudio.service
             └─1415 /usr/bin/pulseaudio --start -n --file=/etc/pulse/qubes-default.pa --exit-idle-time=-1 --daemonize=no --log-target=journal

Dec 31 23:40:28 untrusted-pulseaudio pulseaudio[1415]: source cork req state =1, now state=-2
Dec 31 23:40:28 untrusted-pulseaudio pulseaudio[1415]: module-rescue-stream is obsolete and should no longer be loaded. Please remove it from your configuration.
Dec 31 23:40:28 untrusted-pulseaudio systemd[536]: Started pulseaudio.service - Sound Service.
Dec 31 23:40:28 untrusted-pulseaudio pulseaudio[1415]: GetManagedObjects() failed: org.freedesktop.DBus.Error.NameHasNoOwner: Could not activate remote peer: unit failed.
Dec 31 23:40:28 untrusted-pulseaudio pulseaudio[1415]: source cork req state =0, now state=1
Dec 31 23:40:41 untrusted-pulseaudio pulseaudio[1415]: sink cork req state =0, now state=1
Dec 31 23:40:57 untrusted-pulseaudio pulseaudio[1415]: source cork req state =1, now state=0
Dec 31 23:41:02 untrusted-pulseaudio pulseaudio[1415]: source cork req state =2, now state=1
Dec 31 23:41:02 untrusted-pulseaudio pulseaudio[1415]: sink cork req state =1, now state=0
Dec 31 23:41:03 untrusted-pulseaudio pulseaudio[1415]: sink cork req state =0, now state=1

the difference between the first system where the audio works and with the second where it does not is the first is a desktop with hdmi used for audio. The second system is a thhinkpad T480 with internal audio.

What's interesting is that I have another same spec T480 that was installed as Qubes 4.2 for a tst (rc2 back then, but now rc4) and sound works there just fine.

I am not yet sure what to make out of this. I can't easily reboot my desktop where sound now works but I suspect it'll need a similar "start qube with old pulseaudio" first given that one of the qubes that was started on system startup lost it's sound now that I killed the pulseaudio-enabled qube.

DemiMarie · 2024-01-01T04:49:48Z

This indicates that:

PipeWire is running.
The Qubes OS module is loaded.
pacat-simple-vchan has connected.
pacat-simple-vchan is not sending and receiving data on the vchan.

verygreen · 2024-01-01T05:13:27Z

On the thinkpad that does not work status of pulseaudio looks like this which is probably bad:

● pulseaudio.service - Sound Service
     Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; preset: enabled)
     Active: active (running) since Mon 2024-01-01 00:09:08 EST; 2min 29s ago
TriggeredBy: ● pulseaudio.socket
   Main PID: 5317 (pulseaudio)
      Tasks: 7 (limit: 4612)
     Memory: 10.1M
        CPU: 338ms
     CGroup: /user.slice/user-1000.slice/[email protected]/session.slice/pulseaudio.service
             ├─5317 /usr/bin/pulseaudio --daemonize=no --log-target=journal
             └─5419 /usr/libexec/pulse/gsettings-helper

Jan 01 00:09:08 dom0 systemd[5118]: Starting pulseaudio.service - Sound Service...
Jan 01 00:09:08 dom0 pulseaudio[5317]: Disabling timer-based scheduling because running inside a VM.
Jan 01 00:09:08 dom0 pulseaudio[5317]: Disabling timer-based scheduling because running inside a VM.
Jan 01 00:09:08 dom0 pulseaudio[5317]: stat('/etc/pulse/default.pa.d'): No such file or directory
Jan 01 00:09:08 dom0 systemd[5118]: Started pulseaudio.service - Sound Service.
Jan 01 00:09:11 dom0 pulseaudio[5317]: ALSA woke us up to write new data to the device, but there was actually nothing to write.
Jan 01 00:09:11 dom0 pulseaudio[5317]: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
Jan 01 00:09:11 dom0 pulseaudio[5317]: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.

3hhh · 2024-01-01T11:34:34Z

Possibly related: #8816

marmarek · 2024-01-01T14:00:35Z

Which kernel version in dom0? Does opening pavucontrol in dom0 help?

verygreen · 2024-01-01T17:01:30Z

opening pavucontrol in dom0 does not help. dom0 kernel on the non-working Thinkpad is 6.1.62-1.qubes.fc37 (on working in 6.1.57 or some such, but I doubt it's related)

ben-grande · 2024-01-19T08:45:41Z

Qubes: R4.2 (clean install, not in-place)
Kernel: 6.1.62-1.qubes.fc37
AudioVM: yes
AudioVM Template: debian-12-minimal
Output built-in: working
Input built-in: failing
Output USB headphone: working
Input USB headphone: working

I have a debian-12-minimal based audiovm. Output audio works correctly via built-in stereo, JACK or USB headphones.

Input audio only works if headphones have microphones. Input does not work if I attach the built-in microphone from dom0 to the audio client and try to record:

pipewire[569]: mod.qubes-audio: Underrun: asked to read 940 bytes but only 0 available

Pavucontrol in sys-audio shows when I have the headphones with microphone connected in the the Input Devices tab, but does not show anything for the built-in microphone when attached. It already shows Built-in Audio Analog Stereo in the Input Devices tab before attaching the microphone.

When attaching the USB headphone to the client, arecord -l shows the card, but when attaching the built-in microphone, nothing is shown.

In the client:

The microphone worked before having an audiovm, but it can possibly be related to pipewire not detecting the built-in microphone while pulseaudio in Dom0 did in R4.1.

Can I provide more information to help debug this?

DemiMarie · 2024-01-20T00:31:41Z

Qubes: R4.2 (clean install, not in-place)
Kernel: 6.1.62-1.qubes.fc37
AudioVM: yes
AudioVM Template: debian-12-minimal
Output built-in: working
Input built-in: failing
Output USB headphone: working
Input USB headphone: working

I have a debian-12-minimal based audiovm. Output audio works correctly via built-in stereo, JACK or USB headphones.

Input audio only works if headphones have microphones. Input does not work if I attach the built-in microphone from dom0 to the audio client and try to record:
pipewire[569]: mod.qubes-audio: Underrun: asked to read 940 bytes but only 0 available

This message comes from the Qubes OS PipeWire module and indicates that dom0 (or the AudioVM) did not provide audio samples quickly enough. This situation will cause a glitch, but the code is designed to recover from this error once audio samples are available again.

Does this message appear a few times after audio recording is requested, or do you get an endless stream of such messages? The former is expected due to a known limitation in how audio recording works in Qubes OS. The latter indicates one of two things:

pacat-simple-vchan in the AudioVM was never told that it should allow audio recording.
There is something else wrong preventing pacat-simple-vchan from providing audio samples.

A third possibility is that pacat-simple-vchan never started at all, but you being able to play audio rules this out.

Pavucontrol in sys-audio shows when I have the headphones with microphone connected in the the Input Devices tab, but does not show anything for the built-in microphone when attached. It already shows Built-in Audio Analog Stereo in the Input Devices tab before attaching the microphone.

Does the built-in microphone work when attached to dom0? I’m wondering if the built-in microphone is powered down by default and must be powered up via ACPI and/or I²C. Neither of these are exposed to VMs, so this would prevent the AudioVM from being able to use the device.

When attaching the USB headphone to the client, arecord -l shows the card, but when attaching the built-in microphone, nothing is shown.

In the client:

The microphone worked before having an audiovm, but it can possibly be related to pipewire not detecting the built-in microphone while pulseaudio in Dom0 did in R4.1.

I don’t think this is a problem with PipeWire, but rather a problem with your microphone not being assignable to a VM.

Can I provide more information to help debug this?

If the microphone works in dom0, then I suspect that this is not a Qubes OS bug, but rather a limitation of your hardware.

ben-grande · 2024-01-20T18:02:40Z

pipewire[569]: mod.qubes-audio: Underrun: asked to read 940 bytes but only 0 available
This message comes from the Qubes OS PipeWire module and indicates that dom0 (or the AudioVM) did not provide audio samples quickly enough. This situation will cause a glitch, but the code is designed to recover from this error once audio samples are available again.

Does this message appear a few times after audio recording is requested, or do you get an endless stream of such messages? The former is expected due to a known limitation in how audio recording works in Qubes OS. The latter indicates one of two things:

pacat-simple-vchan in the AudioVM was never told that it should allow audio recording.

There is something else wrong preventing pacat-simple-vchan from providing audio samples.

A third possibility is that pacat-simple-vchan never started at all, but you being able to play audio rules this out.

Endless stream of these messages after trying to record audio.

Pavucontrol in sys-audio shows when I have the headphones with microphone connected in the the Input Devices tab, but does not show anything for the built-in microphone when attached. It already shows Built-in Audio Analog Stereo in the Input Devices tab before attaching the microphone.

Does the built-in microphone work when attached to dom0? I’m wondering if the built-in microphone is powered down by default and must be powered up via ACPI and/or I²C. Neither of these are exposed to VMs, so this would prevent the AudioVM from being able to use the device.

When attaching the USB headphone to the client, arecord -l shows the card, but when attaching the built-in microphone, nothing is shown.
In the client:
The microphone worked before having an audiovm, but it can possibly be related to pipewire not detecting the built-in microphone while pulseaudio in Dom0 did in R4.1.

I don’t think this is a problem with PipeWire, but rather a problem with your microphone not being assignable to a VM.

I did not write that phrase well. When I said it worked in R4.1 with pulseaudio and Dom0, I meant Dom0 as the audiovm. The microphone worked in R4.1 when assining to DomUs.

Can I provide more information to help debug this?

If the microphone works in dom0, then I suspect that this is not a Qubes OS bug, but rather a limitation of your hardware.

Also, the microphone dom0:mic can't be attached to dom0 as the audiovm property is not set. But this was a writing mistake, answered in my comment above.

I will however, try to record without an audiovm (dom0 as the audiovm) and see what happens in R4.2.

Maybe related: #4054 (comment)

DemiMarie · 2024-01-21T19:10:38Z

pipewire[569]: mod.qubes-audio: Underrun: asked to read 940 bytes but only 0 available
This message comes from the Qubes OS PipeWire module and indicates that dom0 (or the AudioVM) did not provide audio samples quickly enough. This situation will cause a glitch, but the code is designed to recover from this error once audio samples are available again.
Does this message appear a few times after audio recording is requested, or do you get an endless stream of such messages? The former is expected due to a known limitation in how audio recording works in Qubes OS. The latter indicates one of two things:

pacat-simple-vchan in the AudioVM was never told that it should allow audio recording.

There is something else wrong preventing pacat-simple-vchan from providing audio samples.

A third possibility is that pacat-simple-vchan never started at all, but you being able to play audio rules this out.
Endless stream of these messages after trying to record audio.

Does PulseAudio work? Install pulseaudio and remove pipewire.

Pavucontrol in sys-audio shows when I have the headphones with microphone connected in the the Input Devices tab, but does not show anything for the built-in microphone when attached. It already shows Built-in Audio Analog Stereo in the Input Devices tab before attaching the microphone.

Does the built-in microphone work when attached to dom0? I’m wondering if the built-in microphone is powered down by default and must be powered up via ACPI and/or I²C. Neither of these are exposed to VMs, so this would prevent the AudioVM from being able to use the device.

When attaching the USB headphone to the client, arecord -l shows the card, but when attaching the built-in microphone, nothing is shown.
In the client:
The microphone worked before having an audiovm, but it can possibly be related to pipewire not detecting the built-in microphone while pulseaudio in Dom0 did in R4.1.

I don’t think this is a problem with PipeWire, but rather a problem with your microphone not being assignable to a VM.

I did not write that phrase well. When I said it worked in R4.1 with pulseaudio and Dom0, I meant Dom0 as the audiovm. The microphone worked in R4.1 when assining to DomUs.

Do you mean that PCI passthrough of the sound card works, or that assigning the dom0:mic device with the Qubes GUI or CLI tools works?

ben-grande · 2024-01-21T20:59:59Z

Endless stream of these messages after trying to record audio.

Does PulseAudio work? Install pulseaudio and remove pipewire.

Will try soonish.

I did not write that phrase well. When I said it worked in R4.1 with pulseaudio and Dom0, I meant Dom0 as the audiovm. The microphone worked in R4.1 when assining to DomUs.

Do you mean that PCI passthrough of the sound card works, or that assigning the dom0:mic device with the Qubes GUI or CLI tools works?

I mean that assining dom0:mic to with the Qubes GUI or CLI worked in R4.1. But there could be other reasons, will try Pulseaudio and see.

DemiMarie · 2024-01-21T23:25:29Z

Endless stream of these messages after trying to record audio.

Does PulseAudio work? Install pulseaudio and remove pipewire.

Will try soonish.

Thanks! If the problem is what I think it is, this won’t help, unfortunately.

I did not write that phrase well. When I said it worked in R4.1 with pulseaudio and Dom0, I meant Dom0 as the audiovm. The microphone worked in R4.1 when assining to DomUs.

Do you mean that PCI passthrough of the sound card works, or that assigning the dom0:mic device with the Qubes GUI or CLI tools works?

I mean that assining dom0:mic to with the Qubes GUI or CLI worked in R4.1. But there could be other reasons, will try Pulseaudio and see.

Was the actual PCI device with the microphone attached to dom0 or to an AudioVM? Can you try detaching the PCI device from the AudioVM, rebooting, attaching it to dom0, and setting the AudioVM’s AudioVM to dom0? You can then persistently assign dom0:mic to the AudioVM and continue to assign it to other VMs. Unfortunately, this will not work in the GUI due to GUI limitations, but it should work if you use the command line. There will also be a latency penalty due to nesting AudioVMs.

marmarek · 2024-01-21T23:29:41Z

Despite the device always named dom0:mic, attaching it to a qube should talk to that qube's audiovm to enable recording there. It uses qubes.AudioInputEnable qrexec service for that.

DemiMarie · 2024-01-22T00:34:03Z

Also, an AudioVM can have its own AudioVM and this can be chained an arbitrary number of times, though there is a latency hit each time.

ben-grande · 2024-01-22T09:32:21Z

Endless stream of these messages after trying to record audio.

Does PulseAudio work? Install pulseaudio and remove pipewire.

Will try soonish.

Thanks! If the problem is what I think it is, this won’t help, unfortunately.

Well, with pulseaudio works....

I removed the Audio PCI from the sys-audio AudioVM, rebooted the system.
I first tried to attach the mic to the browser AppVM, it failed with Failed to attach audio input from dom0 to test: pulseaudio agent not running. The first time after reboot it actually shows no messages, but also doesn't work, just a second try that shows this error message. So the problem is not Dom0 or my custom template for AudioVM.
I did clone my browser template, uninstalled pipewire and pipewire-qubes, cleaned remaining pipewirelibraries and installed pulseaudio and pulseaudio-qubes.
Created an AppVM based on it and attached the microphone to the AppVM. Tested mic recording on Firefox and Chromium and both worked.

I did not write that phrase well. When I said it worked in R4.1 with pulseaudio and Dom0, I meant Dom0 as the audiovm. The microphone worked in R4.1 when assining to DomUs.

Do you mean that PCI passthrough of the sound card works, or that assigning the dom0:mic device with the Qubes GUI or CLI tools works?

I mean that assining dom0:mic to with the Qubes GUI or CLI worked in R4.1. But there could be other reasons, will try Pulseaudio and see.

Was the actual PCI device with the microphone attached to dom0 or to an AudioVM? Can you try detaching the PCI device from the AudioVM, rebooting, attaching it to dom0, and setting the AudioVM’s AudioVM to dom0?

With the soundcard held by Dom0 and uninstalling pipewire and installing pulseaudio in the client, microphone is working, as show in the previous

The soundcard was being held by the AudioVM, while the microphone, unnatached, remained in dom0 until I assign it to a qube.

You can then persistently assign dom0:mic to the AudioVM and continue to assign it to other VMs. Unfortunately, this will not work in the GUI due to GUI limitations, but it should work if you use the command line. There will also be a latency penalty due to nesting AudioVMs.

Sorry, I didn't get this part, isn't the dom0:mic supposed to be attached to the AudioVM client instead of the AudioVM itself?

Or you really mean this:

qvm-device mic attach disp-sys-audio dom:mic

My audio template only has pipewire.

Attaching microphone to custom AudioVM (only has pipewire):

Failed to attach audio input from dom0 to disp-sys-audio: pulseaudio agent not running

Setting disp-sys-audio preference audiovm to dom0 results in the same message.

The journal from disp-sys-audio:

disp-sys-audio qubes.AudioInputEnable+disp-sys-audio-dom0[834]: socat[836] E connect(, AF=1 "/var/run/qubes/audio-control.disp-sys-audio", 45): Connection refused

While if I attach the microphone to the pulseaudio browser app qube that has audiovm set to dom0:

qvm-device mic attach browser-pulseaudio dom:mic

No error messages in Dom0, no journal messages in the qube, built-in microphone works.

Qrexec policy error is also ruled out as I can't find a denied rule from the Dom0 journal.

ben-grande · 2024-01-22T10:20:08Z

Cloned the audio template and did the same as above, uninstalled pipewire and installed pulseaudio packages:

user@sys-audio-pulse:~$ apt list --installed pulse*
Listing... Done
pulseaudio-qubes/unknown,now 4.2.11-1+deb12u1 amd64 [installed]
pulseaudio-utils/stable,now 16.1+dfsg1-2+b1 amd64 [installed,automatic]
pulseaudio/stable,now 16.1+dfsg1-2+b1 amd64 [installed]
user@sys-audio-pulse:~$ apt list --installed pipe*
Listing... Done
user@sys-audio-pulse:~$

And create an hvm named sys-audio-pulse based on it with meminfo-writer service set to off and the service audiovm set to on. I did not start the qvm-start-daemon automatically so I can read the log messages. The audiovm of sys-audio-pulse is set to dom0 and to itself, sys-audio-pulse. Both configurations worked.

Set the client app qube browser-pulseaudio audiovm to sys-audio-pulse (based on tpl-sys-audio-pulse with the packages above).

Started manually on the server (AudioVM):

qvm-start-daemon --all --watch

Restarted the client browser-pulseaudio, attached the microphone to the client, audio input through the built-in microphone worked.

qvm-start-daemon logs:

Setting audio-input to enabled
Recording start
Stream device alsa_input.pci-0000_00_0X.0.analog-stereo resumed.
Stream uncork
Stream device alsa_output.pci-0000_00_0X.0.analog-stereo resumed.
Stream started.

Summary: custom AudioVM or dom0 as the AudioVM with pulseaudio and client with pulseaudio allows the microphone to work.

I will try to not autostart the qvm-start-daemon on the pipewire audiovm and see what happens by starting it manually....

ben-grande · 2024-01-22T11:03:21Z

I will try to not autostart the qvm-start-daemon on the pipewire audiovm and see what happens by starting it manually....

Actually, I can't do this because the client needs to have pulseaudio for the microphone to be attached else it says that pulseaudio is not running.

So I tested:

client with pipewire and server with pipewire
- mic can't be attached
- speaker works
client with pipewire and server with pulseaudio
- mic can't be attached,
- didn't test speakers
client with pulseaudio and server with pulseadio
- mic attached, mic works
- speaker works

client with pulseaudio and server with pipewire

mic attached, mic does not work
speaker works
client logs:

browser-pulseaudio pulseaudio[561]: source cork req state =1, now state=2
browser-pulseaudio pulseaudio[561]: source cork req state =0, now state=1
browser-pulseaudio pulseaudio[561]: source cork req state =1, now state=0
browser-pulseaudio pulseaudio[561]: source cork req state =2, now state=1

server logs:

Setting audio-input to enabled
Recording start
Recording stop

marmarek · 2024-01-22T11:29:17Z

On Mon, Jan 22, 2024 at 03:03:32AM -0800, ben-grande wrote: > I will try to not autostart the qvm-start-daemon on the pipewire audiovm and see what happens by starting it manually.... Actually, I can't do this because the client needs to have pulseaudio for the microphone to be attached else it says that pulseaudio is not running.

You don't need pulseaudio daemon for that, just pulseaudio libs. pipewire-pulse should + pulseaudio-libs should be enough.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab

ben-grande · 2024-01-22T13:48:28Z

You don't need pulseaudio daemon for that, just pulseaudio libs.
pipewire-pulse should + pulseaudio-libs should be enough.

pulseaudio-libs is for Fedora and for Debian I already had libpuse*.

So, I tried with sys-audio based on debian-12-xfce and also fedora-38-xfce and also the browser qube being based on debian-12-xfce.... no success. Mic can be attached but does not work:

Client (debian-12-xfce):

disp6587 pipewire[1269]: mod.qubes-audio: Underrun: asked to read 1884 bytes, but only 0 available

AudioVM (fedora-38-xfce with qubes-core-admin-client and qubes-audio-daemon) (sound output works, input doesn't):

Recording start
Overrun: discarding 32768 bytes
Overrun: discarding 32768 bytes
Overrun: discarding 32768 bytes

moonlitOrca added P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: bug Type: bug report. A problem or defect resulting in unintended behavior in something that exists. labels Oct 2, 2023

moonlitOrca changed the title ~~No sound devices available after update to 4.2~~ No sound playback devices available after update to 4.2 Oct 2, 2023

andrewdavidwong changed the title ~~No sound playback devices available after update to 4.2~~ No sound playback devices available after in-place upgrade to 4.2 Oct 4, 2023

3hhh mentioned this issue Dec 29, 2023

Both pulseaudio and pipewire installed #8805

Open

verygreen mentioned this issue Dec 31, 2023

In-place upgrade to 4.2 from 4.1 ruins sound on supported templates by spurios switch to pipewire #8814

Open

ben-grande mentioned this issue Jul 18, 2024

video-companion formula and persistent attachment of mics/webcams ben-grande/qusal#92

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

No sound playback devices available after in-place upgrade to 4.2 #8560

No sound playback devices available after in-place upgrade to 4.2 #8560

moonlitOrca commented Oct 2, 2023 •

edited

Loading

andrewdavidwong commented Oct 4, 2023

3hhh commented Dec 28, 2023

verygreen commented Dec 31, 2023

DemiMarie commented Jan 1, 2024

verygreen commented Jan 1, 2024 •

edited

Loading

DemiMarie commented Jan 1, 2024

verygreen commented Jan 1, 2024

DemiMarie commented Jan 1, 2024

verygreen commented Jan 1, 2024

verygreen commented Jan 1, 2024

DemiMarie commented Jan 1, 2024

verygreen commented Jan 1, 2024

3hhh commented Jan 1, 2024

marmarek commented Jan 1, 2024

verygreen commented Jan 1, 2024

ben-grande commented Jan 19, 2024 •

edited

Loading

DemiMarie commented Jan 20, 2024

ben-grande commented Jan 20, 2024

DemiMarie commented Jan 21, 2024

ben-grande commented Jan 21, 2024

DemiMarie commented Jan 21, 2024

marmarek commented Jan 21, 2024

DemiMarie commented Jan 22, 2024

ben-grande commented Jan 22, 2024

ben-grande commented Jan 22, 2024 •

edited

Loading

ben-grande commented Jan 22, 2024

marmarek commented Jan 22, 2024 via email

ben-grande commented Jan 22, 2024

No sound playback devices available after in-place upgrade to 4.2 #8560

No sound playback devices available after in-place upgrade to 4.2 #8560

Comments

moonlitOrca commented Oct 2, 2023 • edited Loading

Qubes OS release

Brief summary

Steps to reproduce

Expected behavior

Actual behavior

andrewdavidwong commented Oct 4, 2023

3hhh commented Dec 28, 2023

verygreen commented Dec 31, 2023

DemiMarie commented Jan 1, 2024

verygreen commented Jan 1, 2024 • edited Loading

DemiMarie commented Jan 1, 2024

verygreen commented Jan 1, 2024

DemiMarie commented Jan 1, 2024

verygreen commented Jan 1, 2024

verygreen commented Jan 1, 2024

DemiMarie commented Jan 1, 2024

verygreen commented Jan 1, 2024

3hhh commented Jan 1, 2024

marmarek commented Jan 1, 2024

verygreen commented Jan 1, 2024

ben-grande commented Jan 19, 2024 • edited Loading

DemiMarie commented Jan 20, 2024

ben-grande commented Jan 20, 2024

DemiMarie commented Jan 21, 2024

ben-grande commented Jan 21, 2024

DemiMarie commented Jan 21, 2024

marmarek commented Jan 21, 2024

DemiMarie commented Jan 22, 2024

ben-grande commented Jan 22, 2024

ben-grande commented Jan 22, 2024 • edited Loading

ben-grande commented Jan 22, 2024

marmarek commented Jan 22, 2024 via email

ben-grande commented Jan 22, 2024

moonlitOrca commented Oct 2, 2023 •

edited

Loading

verygreen commented Jan 1, 2024 •

edited

Loading

ben-grande commented Jan 19, 2024 •

edited

Loading

ben-grande commented Jan 22, 2024 •

edited

Loading