All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: Hao Chen <chenhaosjtuacm@google.com>, virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] Fwd: [PATCH v1] Add virtio audio policy device specification
Date: Tue, 15 Jun 2021 14:04:21 +0200	[thread overview]
Message-ID: <28d71143-5dc2-f730-5590-399d377bde8f@metux.net> (raw)
In-Reply-To: <CABATKF8CSfNs3VJViX44Ui=ugJriWX680Grm3w6VxtQkE5+LSw@mail.gmail.com>

On 15.06.21 01:28, Hao Chen wrote:

Hi,

> ---------- Forwarded message ---------
> From: Hao Chen <chenhaosjtuacm@google.com>
> Date: Mon, Jun 14, 2021 at 4:26 PM
> Subject: [PATCH v1] Add virtio audio policy device specification
> To: <chenhaosjtuacm@google.com>
> 
> 
> This patch includes a new device for coordinating audio among mutliple
> VMs.

Wouldn't this be better a case for audio servers (e.g. PA) ?
Once we already have several VMs (or just multiple programs) playing to
the same output channel we're IMHO directly within the use case of audio
servers.

Audio in general is a complex matter as soon as RT requirements,
multiple producers, various codecs, filters, harware mixing and routing,
etc, come in.

It seems we currently only have a pretty trivial virtio audio device
that even only supports raw PCM.

<snip>

> +When there are multiple guest VMs playing sounds, they may want to cooperate
> +with each other. For example, a VM is playing something very critical and want
> +to mute everyone else; or it is OK for other to lower the volume ("duck") but
> +keep playing; or it is OK to playing concurrently with other sounds. They can
> +cooperate via audio policy device. The driver notifies the device when the
> +guest VM is playing, and the device will notify other VMs. The driver can also
> +suggest the device to mute or duck some audio devices based on the information
> +it received from the device.

It seems that this is just an simple arbiter that doesn't do much more
than managing flags in a central place. Doesn't seem to related to any
actual (virtio) devices at all. And purely volountarily (not enforcing
anything, just notifying)

Why not just using some remote file system like 9P for that ?

Really seems to be a very special case thing to me, and I'm really
unsure whether there's much gain in having an own virtio device for that
at all.

What is this really meant for ? Are there any actual implementations for
that approach ?


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2021-06-15 12:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210614232650.265428-1-chenhaosjtuacm@google.com>
2021-06-14 23:28 ` [virtio-dev] Fwd: [PATCH v1] Add virtio audio policy device specification Hao Chen
2021-06-15 12:04   ` Enrico Weigelt, metux IT consult [this message]
2021-06-15 21:26     ` Hao Chen

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=28d71143-5dc2-f730-5590-399d377bde8f@metux.net \
    --to=lkml@metux.net \
    --cc=chenhaosjtuacm@google.com \
    --cc=virtio-dev@lists.oasis-open.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.