Re: A few Machines crash when "no default audio driver available"

["Daniel P. Berrangé" <berrange@redhat.com>]

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é <berrange@redhat.com> 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 <peter.maydell@linaro.org> wrote:
> > > >
> > > > On Thu, 9 Jul 2026 at 14:32, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > > >
> > > > > On Thu, Jul 09, 2026 at 03:22:05PM +0200, Markus Armbruster wrote:
> > > > > > Cc: mainainters for "Overall Audio backends"
> > > > > > Peter Maydell <peter.maydell@linaro.org> writes:
> > > > > >
> > > > > > > On Thu, 9 Jul 2026 at 12:44, Markus Armbruster <armbru@redhat.com> 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.

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 :-(

> 
> 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.
> 

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|