My question for QEMU is if this is going to be disabled as well, then how can we figure out whether this is supported or not as we do not capture a spice audio capability and starting to do that would break older QEMUs.  Can we depend on spice graphics being enabled when we are trying to figure out whether the QEMU supports the audio device?  Will that not break some use case?

So then the questions are really two I think:

 * how to detect / negotiate audio dev support between libvirt and qemu, so that we don't advertise support for something not there
 * in case qemu is called with an unsupported audio backend, should qemu explicitly fail?

I honestly think those are questions are not specific for audio/spice, so cc'in Paolo for his thoughts, and Gerd FYI only.

(In reply to Klaus Heinrich Kiwi from comment #2)
We have a way to detect most audio devices, but spice was always regarded as graphics, not audio, so we did not probe spice audio.  And when called with unsupported audio backend I think qemu fails, it's just spice that's acting out.  Anyway, any update helps, thanks.

kraxel@sirius ~/projects/qemu (queue/kraxel)# qemu-default -audiodev spice,id=a1
audio: Could not init `spice' audio driver
audio: warning: Using timer based audio emulation

So, yes, qemu silently picks something else instead of throwing an error
(which indeed looks like it is not specific to spice).

Detection: 
There is qemu-default -audio-help, not sure whenever we have a qmp version of that.

In general both spice audio and spice grapics depend on the same compile time option, so typically you should have either none or both, also spice audio wouldn't actually work with spice disabled.

The modules are packaged in different sub-rpms though (qemu-ui-spice-core, qemu-audio-spice) so it is in theory possible that you have the one and not the other.

OK, sorry for the presumption in my case, I really thought spice was special with the audio.  So it seems like the change for QEMU should be changing the behaviour so that it errors out instead of falling back to something else and for libvirt we can assume that qemu has spice audio support if and only if it has spice graphics support as well.  Or should we go a step further and only allow using spice audio if at least one of the graphics is spice?

I can try and do this in both qemu and libvirt.

Oh, I missed the part about sub-rpms.  Shouldn't one depend on the other in this case?

(In reply to Martin Kletzander from comment #5)
> OK, sorry for the presumption in my case, I really thought spice was special
> with the audio.  So it seems like the change for QEMU should be changing the
> behaviour so that it errors out instead of falling back to something else

Yes.

> and for libvirt we can assume that qemu has spice audio support if and only
> if it has spice graphics support as well.  Or should we go a step further
> and only allow using spice audio if at least one of the graphics is spice?

The latter given that spice audio will fail anyway in case spice is not
enabled (the audio stream is sent to the spice client for playback ...).

(In reply to Martin Kletzander from comment #6)
> Oh, I missed the part about sub-rpms.  Shouldn't one depend on the other in
> this case?

Yes, spice audio should depend on spice core.
Maybe that is actually the case, didn't check.

Alternatively merge them all into a single spice sub-rpm.

(In reply to Gerd Hoffmann from comment #7)
> (In reply to Martin Kletzander from comment #5)
> > OK, sorry for the presumption in my case, I really thought spice was special
> > with the audio.  So it seems like the change for QEMU should be changing the
> > behaviour so that it errors out instead of falling back to something else
> 
> Yes.
> 
> > and for libvirt we can assume that qemu has spice audio support if and only
> > if it has spice graphics support as well.  Or should we go a step further
> > and only allow using spice audio if at least one of the graphics is spice?
> 
> The latter given that spice audio will fail anyway in case spice is not
> enabled (the audio stream is sent to the spice client for playback ...).

As far as I can tell, libvirt does not prevent me from configuring a domain with other audio backends even when they are not available in the qemu that libvirt is using. At least, when I try configuring a domain with the 'coreaudio' macOS audio backend on my linux host, the domain starts without problem. (When running qemu directly on this host with '-audiodev coreaudio,...' it gives the same "Using timer based audio emulation" fallback warning that Gerd mentions above.)

I suppose the spice scenario is more important because there are so many existing domains that are configured to use the spice audio backend, but this seems like a more general issue, doesn't it?

(In reply to Jonathon Jongsma from comment #8)
Your question is similar to why I actually cloned this to QEMU initially.  Even though it is customary to error out for unavailable devices, maybe audio is using fallback for some particular reason. Maybe it is so that applications using audio do not get stuck if playing even a system sound?  Maybe that's a stretch, but it seems audio does fallback for some reason, not just out of spite.  We'll see how the conversation plays out if I ever get to post the patches upstream, it might end up being something completely unexpected.

Marc-Andre - in my review of older, open bugs destined to be closed in the next 6 months I came across this - since you've recently added yourself to the audio subsystem in qemu can you provide some thoughts / context?  Is this fixable or worth fixing for RHEL?  Thanks...

-soundhw is now gone from upstream QEMU. (we have -audio instead)

Regarding the original issue, we simply exit(1) if -audiodev is invalid, since 7.2:

commit 0f957c53c84d655f2e99677d407cf2bbe1832de4
Author: Marc-André Lureau <marcandre.lureau>
Date:   Mon Aug 22 17:10:21 2022 +0400

    audio: exit(1) if audio backend failed to be found or initialized
    
    If you specify a known backend but it isn't compiled in, or failed to
    initialize, you get a simple warning and the "none" backend as a
    fallback, and QEMU runs happily:
    
    $ qemu-system-x86_64 -audiodev id=audio,driver=dsound
    audio: Unknown audio driver `dsound'
    audio: warning: Using timer based audio emulation
    ...
    
    Instead, QEMU should fail to start:
    $ qemu-system-x86_64 -audiodev id=audio,driver=dsound
    audio: Unknown audio driver `dsound'
    $
    
    Resolves:
    https://bugzilla.redhat.com/show_bug.cgi?id=1983493


I think we can consider this bug closed upstream.

Martin, your cleanup series "[PATCH 00/18] RFC: Remove deprecated audio features" (https://patchew.org/QEMU/cover.1650874791.git.mkletzan@redhat.com/) has not been applied. Do you plan to refresh it?

thanks

(In reply to Marc-Andre Lureau from comment #11)
> -soundhw is now gone from upstream QEMU. (we have -audio instead)
> 
> Regarding the original issue, we simply exit(1) if -audiodev is invalid,
> since 7.2:
> 
> commit 0f957c53c84d655f2e99677d407cf2bbe1832de4
> Author: Marc-André Lureau <marcandre.lureau>
> Date:   Mon Aug 22 17:10:21 2022 +0400
> 
>     audio: exit(1) if audio backend failed to be found or initialized
>     
>     If you specify a known backend but it isn't compiled in, or failed to
>     initialize, you get a simple warning and the "none" backend as a
>     fallback, and QEMU runs happily:
>     
>     $ qemu-system-x86_64 -audiodev id=audio,driver=dsound
>     audio: Unknown audio driver `dsound'
>     audio: warning: Using timer based audio emulation
>     ...
>     
>     Instead, QEMU should fail to start:
>     $ qemu-system-x86_64 -audiodev id=audio,driver=dsound
>     audio: Unknown audio driver `dsound'
>     $
>     
>     Resolves:
>     https://bugzilla.redhat.com/show_bug.cgi?id=1983493
> 
> 
> I think we can consider this bug closed upstream.
> 

I agree, this is handled in libvirt and does not need any explicit work in RHEL since then.

> Martin, your cleanup series "[PATCH 00/18] RFC: Remove deprecated audio
> features"
> (https://patchew.org/QEMU/cover.1650874791.git.mkletzan@redhat.com/) has not
> been applied. Do you plan to refresh it?
> 

I did, but there were some conflicts with other patches and more important things always came first.  Since I planned to do it to mostly get more familiar with qemu's codebase it was not that important anyway.

Is there anything left to do after the mentioned commit (and any previous relevant ones)?  I'm guessing it's already been done, no?

(In reply to Martin Kletzander from comment #12)
> I did, but there were some conflicts with other patches and more important
> things always came first.  Since I planned to do it to mostly get more
> familiar with qemu's codebase it was not that important anyway.

It would still be welcome.

> Is there anything left to do after the mentioned commit (and any previous
> relevant ones)?  I'm guessing it's already been done, no?

not that I know, closing