Daniel P. Berrangé <[email protected]> writes: > On Thu, Jul 09, 2026 at 07:31:31PM +0400, Marc-André Lureau wrote: >> Hi >> >> On Thu, Jul 9, 2026 at 6:02 PM Daniel P. Berrangé <[email protected]> >> wrote: >> > >> > On Thu, Jul 09, 2026 at 05:54:30PM +0400, Marc-André Lureau wrote: >> > > Hi >> > > >> > > On Thu, Jul 9, 2026 at 5:44 PM Peter Maydell <[email protected]> >> > > wrote: >> > > > >> > > > On Thu, 9 Jul 2026 at 14:32, Daniel P. Berrangé <[email protected]> >> > > > wrote: >> > > > > >> > > > > On Thu, Jul 09, 2026 at 03:22:05PM +0200, Markus Armbruster wrote: >> > > > > > Cc: mainainters for "Overall Audio backends" >> > > > > > Peter Maydell <[email protected]> writes: >> > > > > > >> > > > > > > On Thu, 9 Jul 2026 at 12:44, Markus Armbruster >> > > > > > > <[email protected]> wrote: >> > > > > > >> >> > > > > > >> I stumbled over ARM machine musicpal, PPC machines pegasos1, >> > > > > > >> pegasos2, >> > > > > > >> and MIPS machine fuloong2e crashes. >> > > > > > >> >> > > > > > >> I run them like this: >> > > > > > >> >> > > > > > >> $ qemu-system-aarch64 -M musicpal -nodefaults -S -display none >> > > > > > >> -monitor stdio >> > > > > > > >> > > > > > >> Died when device_set_realized() tried to propagate a "no >> > > > > > >> default audio >> > > > > > >> driver available" error to &error_abort. >> > > > > > > >> > > > > > > Is this something we want to have be a possibility the devices >> > > > > > > have to cope with? Can we have the "ignores all audio data" >> > > > > > > backend be always available instead? >> > > > > > >> > > > > > There's plenty of precedence for /dev/null-like backends. >> > > > > > >> > > > > > > Otherwise every audio device needs to cope with "there is no >> > > > > > > audio backend available" and implement "do nothing with the >> > > > > > > audio data" itself. >> > > > > > >> > > > > > Yes. >> > > > > >> > > > > We've got a bit of tension between "no defaults" and "builtin audio >> > > > > devices" here. >> > > > > >> > > > > Cnosider if I had instead done >> > > > > >> > > > > qemu-system-x86_64 -M pc -device ac97 -nodefaults >> > > > > >> > > > > It is not unreasonable to expect to see an error because you asked >> > > > > explicitly for 'ac97' and forgot to wire up the required audio >> > > > > backend, and asked to NOT have any defaults.
Even then, a crash is unequivocally wrong. Fatal error would be defensible. >> > > > > But with your 'musicpal' machine example, you never asked for the >> > > > > frontend device, so you should be forgiven for also not asking >> > > > > for a audio backend. Indeed. >> > > > Ah, so this is because of -nodefaults, not because QEMU was >> > > > somehow built with no audio backends in it. Yes. There are more ways to end up with no audio backend. >> > > > > If we guarantee a /dev/null audio backend always exists, we help >> > > > > the second case but degrade the first case >> > > > >> > > > As a possible analogy, for network devices we just warn in >> > > > the analogous "device created but no backend wired up": >> > > > >> > > > ./build/x86/qemu-system-x86_64 -nodefaults -device e1000 -display none >> > > > qemu-system-x86_64: warning: nic e1000.0 has no peer >> > > > >> > > > and the effective behaviour is that output packets are dropped. When a network device lacks a backend, we make it behave as if it's not connected to anything, and also tell the user that this is the case. Makes sense, especially for onboard devices: the user may not care for such an onboard device, and can't remove it. When an audio device lacks a backend, could we make it behave as if it's not connected to anything? Longwinded way to say ... >> > > > We could make audio devices do that (which would be basically >> > > > equivalent to "if we need an audio backend and we don't have >> > > > one, warn and create the null backend"). ... yes, please. >> > > Note that we don't have a real "null" backend. The "none" backend does >> > > mixing/resampling/volume before dropping the audio (its parent is >> > > MIXENG_BACKEND). I think it would be worth to add (so one day we can >> > > compile qemu without the whole audio/ engine) >> > >> > Rather than adding "null" backend, IMHO, we should make "none" do >> > what its name suggests, by removing the MIGENG_BACKEND from it. >> > >> >> It's a bit more complicated, the "none" backend can be used by vnc >> (not spice or dbus), and we have the now-deprecated HMP wavcapture >> command. > > Oh right because VNC used the capture APIs to receive the audio. > It should probably have had an explicit "vnc" audio backend like > spice did :-( Is this fixable? "Certain audio commands only work when you actually have an audio backend" would be perfectly reasonable, wouldn'it ? >> Note, the new "qemu-vnc" server does not mix/resample audio at this >> point, it takes the first audio stream instead. > >> >> Fwiw, a "null" audio backend would still need to process audio data at >> a correct pace. I'm dense today: why?
