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

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

[Markus Armbruster]

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

Backtrace:

    #0  0x00007ffff4a5432c in __pthread_kill_implementation () at /lib64/libc.so.6
    #1  0x00007ffff49fa15e in raise () at /lib64/libc.so.6
    #2  0x00007ffff49e16d0 in abort () at /lib64/libc.so.6
    #3  0x0000555555584ae9 in error_handle
        (err=0x55555836e8a0, errp=0x5555579c55c8 <error_abort>)
        at ../util/error.c:37
    #4  0x0000555556055670 in error_handle
        (errp=<optimized out>, err=<optimized out>) at ../util/error.c:301
    #5  error_propagate (dst_errp=<optimized out>, local_err=<optimized out>)
        at ../util/error.c:300
    #6  0x0000555555dbc754 in device_set_realized
        (obj=<optimized out>, value=<optimized out>, errp=0x5555579c55c8 <error_abort>) at ../hw/core/qdev.c:629
    #7  0x0000555555dbf9e9 in property_set_bool
        (obj=0x55555836eb50, v=<optimized out>, name=<optimized out>, opaque=0x555557b90f20, errp=0x5555579c55c8 <error_abort>) at ../qom/object.c:2484
    #8  0x0000555555dc2ec9 in object_property_set
        (obj=obj@entry=0x55555836eb50, name=name@entry=0x5555565a98c8 "realized", v=v@entry=0x555557b8faa0, errp=errp@entry=0x5555579c55c8 <error_abort>)
        at ../qom/object.c:1548
    #9  0x0000555555dc6ca1 in object_property_set_qobject
        (obj=obj@entry=0x55555836eb50, name=name@entry=0x5555565a98c8 "realized", value=value@entry=0x55555836e9a0, errp=errp@entry=0x5555579c55c8 <error_abort>)
        at ../qom/qom-qobject.c:28
    #10 0x0000555555dc3666 in object_property_set_bool
        (obj=0x55555836eb50, name=0x5555565a98c8 "realized", value=<optimized out>, errp=0x5555579c55c8 <error_abort>) at ../qom/object.c:1618
    #11 0x0000555555dbbfde in qdev_realize_and_unref
        (dev=dev@entry=0x55555836eb50, bus=bus@entry=0x55555834e0c0, errp=<optimized out>) at ../hw/core/qdev.c:284
    #12 0x00005555557988d5 in i2c_slave_realize_and_unref
        (dev=dev@entry=0x55555836eb50, bus=bus@entry=0x55555834e0c0, errp=<optimized out>) at ../hw/i2c/core.c:378
    #13 0x0000555555b6fe1d in musicpal_init (machine=0x555557f21520)
        at ../hw/arm/musicpal.c:1334
    #14 0x000055555572d1d2 in machine_run_board_init
        (machine=0x555557f21520, mem_path=<optimized out>, errp=<optimized out>)
        at ../hw/core/machine.c:1696
    #15 0x00005555559f9699 in qemu_init_board () at ../system/vl.c:2727
    #16 qmp_x_exit_preconfig (errp=errp@entry=0x5555579c55c0 <error_fatal>)
        at ../system/vl.c:2821
    #17 0x00005555559fd3fc in qmp_x_exit_preconfig (errp=<optimized out>)
        at ../system/vl.c:2816
    #18 qemu_init (argc=<optimized out>, argv=<optimized out>)
        at ../system/vl.c:3862
    #19 0x000055555558d899 in main (argc=<optimized out>, argv=<optimized out>)
        at ../system/main.c:71

Died when device_set_realized() tried to propagate a "no default audio
driver available" error to &error_abort.

The error comes from audio_init().  Backtrace:

    #0  error_setg_internal
        (errp=errp@entry=0x7fffffffd730, src=src@entry=0x5555565cfd35 "../audio/audio.c", line=line@entry=106, func=func@entry=0x55555670a468 <__func__.3> "audio_init", fmt=fmt@entry=0x55555655ef38 "no default audio driver available")
        at ../util/error.c:96
    #1  0x0000555555ec18fc in audio_init
        (dev=dev@entry=0x0, errp=errp@entry=0x7fffffffd730) at ../audio/audio.c:106
    #2  0x0000555555ec1d36 in audio_get_default_audio_be
        (errp=errp@entry=0x7fffffffd730) at ../audio/audio.c:130
    #3  0x0000555555ec21c5 in audio_be_check
        (be=be@entry=0x55555836ebf8, errp=errp@entry=0x7fffffffd730)
        at ../audio/audio-be.c:15
    #4  0x00005555556fc57a in wm8750_realize
        (dev=<optimized out>, errp=0x7fffffffd730) at ../hw/audio/wm8750.c:628
    #5  0x0000555555dbc7c7 in device_set_realized
        (obj=<optimized out>, value=<optimized out>, errp=0x5555579c55c8 <error_abort>) at ../hw/core/qdev.c:514
    #6  0x0000555555dbf9e9 in property_set_bool
        (obj=0x55555836eb50, v=<optimized out>, name=<optimized out>, opaque=0x555557b90f20, errp=0x5555579c55c8 <error_abort>) at ../qom/object.c:2484
    #7  0x0000555555dc2ec9 in object_property_set
        (obj=obj@entry=0x55555836eb50, name=name@entry=0x5555565a98c8 "realized", v=v@entry=0x555557b8faa0, errp=errp@entry=0x5555579c55c8 <error_abort>)
        at ../qom/object.c:1548
    #8  0x0000555555dc6ca1 in object_property_set_qobject
        (obj=obj@entry=0x55555836eb50, name=name@entry=0x5555565a98c8 "realized", value=value@entry=0x55555836e9a0, errp=errp@entry=0x5555579c55c8 <error_abort>)
        at ../qom/qom-qobject.c:28
    #9  0x0000555555dc3666 in object_property_set_bool
        (obj=0x55555836eb50, name=0x5555565a98c8 "realized", value=<optimized out>, errp=0x5555579c55c8 <error_abort>) at ../qom/object.c:1618
    #10 0x0000555555dbbfde in qdev_realize_and_unref
        (dev=dev@entry=0x55555836eb50, bus=bus@entry=0x55555834e0c0, errp=<optimized out>) at ../hw/core/qdev.c:284
    #11 0x00005555557988d5 in i2c_slave_realize_and_unref
        (dev=dev@entry=0x55555836eb50, bus=bus@entry=0x55555834e0c0, errp=<optimized out>) at ../hw/i2c/core.c:378
    #12 0x0000555555b6fe1d in musicpal_init (machine=0x555557f21520)
        at ../hw/arm/musicpal.c:1334
    #13 0x000055555572d1d2 in machine_run_board_init
        (machine=0x555557f21520, mem_path=<optimized out>, errp=<optimized out>)
        at ../hw/core/machine.c:1696
    #14 0x00005555559f9699 in qemu_init_board () at ../system/vl.c:2727
    #15 qmp_x_exit_preconfig (errp=errp@entry=0x5555579c55c0 <error_fatal>)
        at ../system/vl.c:2821
    #16 0x00005555559fd3fc in qmp_x_exit_preconfig (errp=<optimized out>)
        at ../system/vl.c:2816
    #17 qemu_init (argc=<optimized out>, argv=<optimized out>)
        at ../system/vl.c:3862
    #18 0x000055555558d899 in main (argc=<optimized out>, argv=<optimized out>)
        at ../system/main.c:71

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

[Peter Maydell]

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?

Otherwise every audio device needs to cope with "there is no
audio backend available" and implement "do nothing with the
audio data" itself.

thanks
-- PMM

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

[Markus Armbruster]

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.

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

[Daniel P. Berrangé]

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.

If we guarantee a /dev/null audio backend always exists, we help
the second case but degrade the first case

So we must pick the lesser evil :-(

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

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

[Peter Maydell]

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

-- PMM

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

[Marc-André Lureau]

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)

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

[Daniel P. Berrangé]

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.

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

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

[Marc-André Lureau]

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.

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.

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

[Daniel P. Berrangé]

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

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

[BALATON Zoltan]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

On Thu, 9 Jul 2026, Daniel P. Berrangé 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.

These machines have an audio device on-board (for pegasos it's part of the 
VIA south bridge) so nodefaults does not change that. I think it would be 
enough to exit with an error message instead of crashing and let the user 
correct the command.

Regards,
BALATON Zoltan

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

[BALATON Zoltan]

On Thu, 9 Jul 2026, Peter Maydell wrote:
> 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?
>
> Otherwise every audio device needs to cope with "there is no
> audio backend available" and implement "do nothing with the
> audio data" itself.

I think the "no default audio driver available" error was returned from 
the device but it was not propagated properly somewhere around 
error_handle to become an error message to abort with so it's not 
something the devices should care about but some problem in error 
handling. Without -nodefaults there is a default audio device so this does 
not happen but with -nodefaults you need to specify one explicitly. I 
think the question is why the error is not propagated and exited with on 
error_abort instead of crashing and is not something specific to these 
devices or machines which are just reproducers of the error handling 
issue.

Regards,
BALATON Zoltan