From: Markus Armbruster <armbru@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org, "Jan Kiszka" <jan.kiszka@siemens.com>,
qemu-arm@nongnu.org, "BALATON Zoltan" <balaton@eik.bme.hu>,
qemu-ppc@nongnu.org, "Huacai Chen" <chenhuacai@kernel.org>,
"Philippe Mathieu-Daudé" <philmd@mailo.com>,
"Jiaxun Yang" <jiaxun.yang@flygoat.com>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: A few Machines crash when "no default audio driver available"
Date: Thu, 09 Jul 2026 15:22:05 +0200 [thread overview]
Message-ID: <87zf00cn7m.fsf@pond.sub.org> (raw)
In-Reply-To: <CAFEAcA9goRQuxw3VD7AqUOHHTdOXu8MSfCxdQMBviE3QgGD58w@mail.gmail.com> (Peter Maydell's message of "Thu, 9 Jul 2026 14:01:19 +0100")
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.
next prev parent reply other threads:[~2026-07-09 13:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 11:44 A few Machines crash when "no default audio driver available" Markus Armbruster
2026-07-09 13:01 ` Peter Maydell
2026-07-09 13:22 ` Markus Armbruster [this message]
2026-07-09 13:32 ` Daniel P. Berrangé
2026-07-09 13:42 ` Peter Maydell
2026-07-09 13:54 ` Marc-André Lureau
2026-07-09 14:02 ` Daniel P. Berrangé
2026-07-09 15:31 ` Marc-André Lureau
2026-07-09 15:58 ` Daniel P. Berrangé
2026-07-09 15:51 ` BALATON Zoltan
2026-07-09 13:22 ` BALATON Zoltan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zf00cn7m.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=balaton@eik.bme.hu \
--cc=chenhuacai@kernel.org \
--cc=jan.kiszka@siemens.com \
--cc=jiaxun.yang@flygoat.com \
--cc=kraxel@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@mailo.com \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.