Re: [virtio-dev] [PATCH] snd: Add virtio sound device specification

[Matti Moell <Matti.Moell@opensynergy.com>]

Hi Liam,

On 12.11.19 19:02, Liam Girdwood wrote:
> On Tue, 2019-11-12 at 17:05 +0100, Jean-Philippe Brucker wrote:
> > > This would be a good improvement, it's less copying and would
> > > likely
> > > improve user experience, however the buffer ptr still suffers
> > > latency
> > > as it's queued (same for stream positions going the other way).
> >
> > Right if the queuing overhead is still too large, then I don't think
> > the
> > current virtqueues can be used.
>
> They can be used for non low latency audio, I don't see any issues if
> latency is not important. e.g. media playback, some gaming, most system
> notifications.

You are absolutely right that the virtques come with some overhead that 
is probably acceptable in many use cases.

The trick for even lower latency will be to use the fancy new virtio 
shared-mem feature, this will allow making a piece of shared memory 
between the audio DSP/sound device and the guest available that contains 
the current sample buffer and the HW position register. Thus, once this 
is set-up, the DSP and the guest can directly communicate without the 
VMM or the virtual device being involved at all.

Maybe it's even enough to just have a single register containing the 
hardware buffer position in shared mem?

Of course this has to be guarded by a feature flag but it would allow 
true zero copy audio where instead of using the queues you would just 
have the producer and consumer free-running without interruptions (as 
long es everything is fine).

The buffer layout is probably the trickiest thing here, how can we know 
what the hardware expects? If we add all known buffer formats now, how 
can we know if they are sufficient for future hardware? Does it make 
sense to wait and add additional buffer formats as they become necessary 
and known?

For the "simple" things like desktop virtualization and all the other 
boring audio use cases using the queues and playing with the 
driver/device kick and interrupt suppression seems to be sufficient to 
reach the respective latency requirements.


Cheers,

		Matti