qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 15/24] audio: add mixing-engine option (documentation)


From: Markus Armbruster
Subject: Re: [PATCH v4 15/24] audio: add mixing-engine option (documentation)
Date: Wed, 25 Sep 2019 11:49:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux)

"Zoltán Kővágó" <address@hidden> writes:

> On 2019-09-23 15:08, Markus Armbruster wrote:
>> "Kővágó, Zoltán" <address@hidden> writes:
>>
>>> This will allow us to disable mixeng when we use a decent backend.
>>>
>>> Disabling mixeng have a few advantages:
>>> * we no longer convert the audio output from one format to another, when
>>>    the underlying audio system would just convert it to a third format.
>>>    We no longer convert, only the underlying system, when needed.
>>> * the underlying system probably has better resampling and sample format
>>>    converting methods anyway...
>>> * we may support formats that the mixeng currently does not support (S24
>>>    or float samples, more than two channels)
>>> * when using an audio server (like pulseaudio) different sound card
>>>    outputs will show up as separate streams, even if we use only one
>>>    backend
>>>
>>> Disadvantages:
>>> * audio capturing no longer works (wavcapture, and vnc audio extension)
>>> * some backends only support a single playback stream or very picky
>>>    about the audio format.  In this case we can't disable mixeng.
>>>
>>> However mixeng is not removed, only made optional, so this shouldn't be
>>> a big concern.
>>>
>>> Signed-off-by: Kővágó, Zoltán <address@hidden>
>>> ---
>>>
>>> Notes:
>>>      Changes from v1:
>>>           * renamed mixeng to mixing-engine
>>>
>>>   qapi/audio.json | 5 +++++
>>>   qemu-options.hx | 6 ++++++
>>>   2 files changed, 11 insertions(+)
>>>
>>> diff --git a/qapi/audio.json b/qapi/audio.json
>>> index 9fefdf5186..0535eff794 100644
>>> --- a/qapi/audio.json
>>> +++ b/qapi/audio.json
>>> @@ -11,6 +11,10 @@
>>>   # General audio backend options that are used for both playback and
>>>   # recording.
>>>   #
>>> +# @mixing-engine: use QEMU's mixing engine to mix all streams inside QEMU. 
>>> When
>>> +#                 set to off, fixed-settings must be also off. Not every 
>>> backend
>>> +#                 compatible with the off setting (default on, since 4.2)
>>> +#
>>
>> Last sentence no verb.
>>
>> Which backends are compatible?
>
> Actually that's a simplification, it depends on a few things.  When
> mixeng is off, qemu will try to use the same format as the emulated
> sound card, and if the backend doesn't support that format, it won't
> work (no audio).  Also attaching multiple sound cards to the same
> audiodev might not work, if the backend doesn't support multiple
> playback streams.  If you use pulseaudio, it'll work without problems,
> if you use alsa, it depends on your device.  If you use a hw: device
> directly, you'll likely only be able to use one emulated sound card
> with a few selected audio formats.  If you use dmix: (and plug), alsa
> will handle the conversion and mixing, so it will work no matter what
> format the emulated sound card uses.  With OSS the situation is
> probably similar, it depends on the kernel/hw what works and what not.
> wav and spice certainly doesn't support multiple streams.  I'm not
> completely sure about the other backends right now, but I think dsound
> and coreaudio can handle the necessary sample format conversions and
> mixing.
>
>> What happens when you try the off setting with incompatible backends?
> See above.

What happens *exactly*?

I'm asking because I'm concerned about the user experience.  When a user
asks for a combination of things QEMU can't provide, such as mixeng off
with an incompatible backend, QEMU should fail with a suitable error
message.  Does it?

Sometimes rejecting non-working configurations is impractical.  Is it
here?

If yes, we should call out the problematic configurations in
documentation.

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]