Re: [virtio-dev] Fwd: [PATCH v1] Add virtio audio policy device specification

[Hao Chen <chenhaosjtuacm@google.com>]

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

I agree, but this is not the problem we want to solve here. Like you
said, this is purely voluntary.
The device will basically notify the VMs when others are playing. The
mixer on the host may or
may not do something to the VM's audio output (e.g., mute), but the VM
does not need to know.

Speaking of being voluntary, you can say it is "voluntary" because we
never enforce the action
of the process of the VM when receiving a notice, but there are
(hardware and/or software) mixers below, so if
this process choose to ignore the notice, it may lose the content when
the underlying mixer decides to mute it.

> 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. Why not just using some remote file system like 9P for that ?

Like I said in another patch, we can do whatever we want. We can use
any protocol we like and interpret
the meaning of the moving bytes as we like, but it doesn't mean
anything. The good thing about putting
them into a spec is when everybody agrees on it, we can build based on
the spec without needing to
persuade others "hey, let's use 9P. BTW, 0001 means I am about to mute you".

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

We use it for controlling audio streams on cars. For example, the
music and navigation audio streams from your
IVI and safety chimes from the car. They are on different OSes.
Currently we have an implementation but not based
on virtio.

Thanks,
Hao

On Tue, Jun 15, 2021 at 5:04 AM Enrico Weigelt, metux IT consult
<lkml@metux.net> wrote:
>
> 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