Re: [RFC 00/24] audio: add GStreamer backend

[BALATON Zoltan <balaton@eik.bme.hu>]

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

On Mon, 1 Dec 2025, Daniel P. Berrangé wrote:
> On Mon, Dec 01, 2025 at 08:30:26PM +0100, BALATON Zoltan wrote:
>> On Mon, 1 Dec 2025, Marc-André Lureau wrote:
>>> On Mon, Dec 1, 2025 at 5:03 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>>>> On Mon, 1 Dec 2025, marcandre.lureau@redhat.com wrote:
>>>>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>>>>>
>>>>> Hi,
>>>>>
>>>>> The following patch series provides a GStreamer-based audio backend,
>>>> which could
>>>>> ultimately allow QEMU to leverage the framework to support the various
>>>> audio
>>>>> subsystems and simplify the audio handling logic (timing, resampling,
>>>> mixing
>>>>> etc), as well as allow greater pipeline flexibility and customization.
>>>>
>>>> While it's good to have a GStreamer backend to integrate well into systems
>>>> already using that, this should not replace existing audio backends in
>>>> QEMU. The reason is that GStreamer has extensive dependencies that I would
>>>>
>>>
>>> GStreamer itself is not so big and doesn't have that many dependencies that
>>> qemu doesn't already have.
>>
>> Except that this proposal uses GStreamer from rust so would also pull in all
>> the rust dependencies too which is still not needed for QEMU. Saying that
>> it's optional but then you lose audio output is also not quite acceptable.
>
> In terms of replacing the existing audio backends, it would simply have to
> wait until we declare Rust to be a mandatory dependency of QEMU, before
> proposing any removal of existing backends.
>
>>>> as another audio backend but not as a replacement for QEMU's audio
>>>> handling logic and backends.
>>>
>>> It would be great if people with very specific or constrained requirements
>>> on qemu audio could check if the GStreamer backend fits their need.
>>
>> At least one of them already said it wouldn't. Also why somebody not running
>> a desktop environment that uses GStreamer would want to add that dependency
>> and use a GStreamer plugin to get the sound back to their native sound
>> service when it is probably already supported by QEMU directly? QEMU also
>> has to support Windows and macOS sound services so having a few more
>> Linux/Unix ones does not make it much more complex.
>
> GStreamer is not merely for desktop environments. It is a general purpose
> audio system, and in terms of QEMU, it is already used by the Spice server
> for video encoding purposes.  IMHO it is reasonable to consider whether
> QEMU could use GStreamer for all audio output regardless of whether it is
> running from a desktop session or not.

But it's most likely found as dependency in apps that already use other 
libraries from the same family that usually come with a certain desktop 
environment. Also spice does not want to replace all the other display 
backends or SDL does not replace other sound backends so the same way it's 
fine to add a GStreamer as another optional way to output sound but not as 
replacing the existing backends and sound infrastructure in QEMU.

> Personally my main concern with gstreamer is that when things go wrong
> it can be very difficult to understand why and thus hard to figure out
> how to fix it, unless you're pretty experienced with gstreamer.
>
> If we do consider rationalizing how many backends we have, IMHO, it
> would be desirable to retain at least one other QEMU audio backend
> that is considered simple & reliable (fool proof) to use & debug.

That probably means we should retain at least the lowest level output for 
the native sound systems of the OSes where QEMU runs but then we can also 
have other backends as the main complexity is in the audio infrastructure 
and not in the backends. What may be possible is to drop OSS and the 
mixing support that is mainly needed for OSS arguing that ALSA has 
replaced OSS on Linux and sndio replaced it on BSD and these can already 
do resampling and mixing themselves so this could simplify QEMU audio code 
to just pass data to a sound service but I'm not sure this feature isn't 
used by some people in QEMU with other backends or to record to wav for 
example. If we remove that too saying that recording can be done from the 
system native sound service then maybe no need for resampling and mixing 
in QEMU at least for output. But what about input where both the system 
and the emulated cards are limited to some specific samping rates and they 
are not set to use the same? Or do the sound services take care of that 
too and you can ask for arbitrary input rate and will it convert from 
hardware rate or you get back an error and QEMU has to handle this?

Regards,
BALATON Zoltan