-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic audiovm switching #8975
Dynamic audiovm switching #8975
Comments
Besides new tests, rename "prepare_audio_vm" to "prepare_audio_test" to avoid confusion with "audiovm". QubesOS/qubes-issues#8975
Besides new tests, rename "prepare_audio_vm" to "prepare_audio_test" to avoid confusion with "audiovm". QubesOS/qubes-issues#8975
Besides new tests, rename "prepare_audio_vm" to "prepare_audio_test" to avoid confusion with "audiovm". QubesOS/qubes-issues#8975
Besides new tests, rename "prepare_audio_vm" to "prepare_audio_test" to avoid confusion with "audiovm". QubesOS/qubes-issues#8975
Besides new tests, rename "prepare_audio_vm" to "prepare_audio_test" to avoid confusion with "audiovm". QubesOS/qubes-issues#8975
Besides new tests, rename "prepare_audio_vm" to "prepare_audio_test" to avoid confusion with "audiovm". Since starting/stopping pacat is asynchronous, retry up to 10s. QubesOS/qubes-issues#8975
Changing audiovm when recording is enabled is confusing. It's because the recording state is in fact hold by the pacat process in a specific audiovm - after switching, the new audiovm doesn't know if it was enabled. The result is recording gets disabled after switching (until you switch back, where the old pacat still knows it), but the devices widget thinks it's still enabled (and fails to detach microphone). Steps to reproduce:
I see two options:
|
- Fix missing dependency for ArchLinux See QubesOS/qubes-issues#8975
- Fix missing dependency for ArchLinux Related to QubesOS/qubes-issues#8975
@marmarek only remains this recording issue right? I think I've experimented it but I would need to retry. |
On Mon, May 13, 2024 at 02:18:51AM -0700, Frédéric Pierret wrote:
@marmarek only remains this recording issue right? I think I've experimented it but I would need to retry.
Yes, only this one. I talked with Marta about it, and she says it's
better to keep recording status (option 1 above), but it may be not easy
to implement...
…--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
|
Use pulseaudio inside VM as that's more compatible. This also tests starting HVM with a non-dom0 audiovm. QubesOS/qubes-issues#8975
Automated announcement from builder-github The component
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The component
|
Automated announcement from builder-github The component
|
Automated announcement from builder-github The component
|
Automated announcement from builder-github The component
|
How to file a helpful issue
The problem you're addressing (if any)
Currently, changing audiovm requires target qube restart in practice. Technically, it is possible to change it without qube restart, if you know which services to restart in what order etc, but that's very much not obvious. This also includes the case of restarting said audiovm.
The solution you'd like
Changing audiovm at runtime should be seamless, as is changing netvm.
The value to a user, and who that user might be
Easier to use non-dom0 audiovm, mostly relevant for USB audio devices. Related to #7750, #8093.
Details
Implementation-wise, this requires:
The text was updated successfully, but these errors were encountered: