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. > > > > > > > > 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. > > > > > > Ah, so this is because of -nodefaults, not because QEMU was > > > somehow built with no audio backends in it. > > > > > > > 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. > > > > > > 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"). > > > > > > > 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. 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.
