Hi On Mon, Jul 20, 2026 at 3:21 PM Markus Armbruster <[email protected]> wrote: > > 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? >
Yes, that's not so trivial though.. (mostly because compatibility with existing behaviour/cli etc) > "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? -audio is emulating a real DAC/ADC that consumes bytes in real-time. If you just do >/dev/null, the audio clock will be too fast, and most apps playing video will likely just play as quickly as they can... This is just the small part we need to keep emulating right depending on the audio stream format
