All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: "Zoltán Kővágó" <dirty.ice.hu@gmail.com>
Cc: qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [PATCH v4 15/24] audio: add mixing-engine option (documentation)
Date: Wed, 25 Sep 2019 11:49:50 +0200	[thread overview]
Message-ID: <87wodwyabl.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <4d24c95c-0e98-2646-0b1a-6c7b3afe0e90@gmail.com> ("Zoltán	Kővágó"'s message of "Tue, 24 Sep 2019 02:21:32 +0200")

"Zoltán Kővágó" <dirty.ice.hu@gmail.com> writes:

> On 2019-09-23 15:08, Markus Armbruster wrote:
>> "Kővágó, Zoltán" <dirty.ice.hu@gmail.com> 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 <DirtY.iCE.hu@gmail.com>
>>> ---
>>>
>>> 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	other threads:[~2019-09-25  9:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-19 21:24 [PATCH v4 00/24] Audio: Mixeng-free 5.1/7.1 audio support Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 01/24] audio: api for mixeng code free backends Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 02/24] alsaaudio: port to the new audio backend api Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 03/24] coreaudio: " Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 04/24] dsoundaudio: " Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 05/24] noaudio: " Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 06/24] ossaudio: " Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 07/24] paaudio: " Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 08/24] sdlaudio: " Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 10/24] wavaudio: " Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 11/24] audio: remove remains of the old " Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 12/24] audio: unify input and output mixeng buffer management Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 13/24] audio: common rate control code for timer based outputs Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 14/24] audio: split ctl_* functions into enable_* and volume_* Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 15/24] audio: add mixing-engine option (documentation) Kővágó, Zoltán
2019-09-23 13:08   ` Markus Armbruster
2019-09-24  0:21     ` Zoltán Kővágó
2019-09-25  9:49       ` Markus Armbruster [this message]
2019-09-29 19:07         ` Zoltán Kővágó
2019-10-01  6:23           ` Markus Armbruster
2019-10-03 23:27             ` Zoltán Kővágó
2019-10-07  8:21               ` Markus Armbruster
2019-09-19 21:24 ` [PATCH v4 16/24] audio: make mixeng optional Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 18/24] audio: support more than two channels in volume setting Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 19/24] audio: replace shift in audio_pcm_info with bytes_per_frame Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 20/24] audio: basic support for multichannel audio Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 21/24] paaudio: channel-map option Kővágó, Zoltán
2019-09-23 13:12   ` Markus Armbruster
2019-09-24  0:43     ` Zoltán Kővágó
2019-09-25 12:17       ` Markus Armbruster
2019-09-25 14:13         ` Gerd Hoffmann
2019-09-29 18:13           ` Zoltán Kővágó
2019-09-30  6:36             ` Gerd Hoffmann
2019-09-19 21:24 ` [PATCH v4 22/24] usb-audio: do not count on avail bytes actually available Kővágó, Zoltán
2019-09-19 21:24 ` [PATCH v4 24/24] usbaudio: change playback counters to 64 bit Kővágó, Zoltán

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=87wodwyabl.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=dirty.ice.hu@gmail.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@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.