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

[Liam Girdwood <liam.r.girdwood@linux.intel.com>]

On Tue, 2019-11-12 at 19:47 +0100, Matti Moell wrote:
> 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?

How would this work on the device driver side. Do "virtual register"
reads map to callbacks on the device driver (with assumed hypervisor
scheduling latencies?). 

Fwiw, some audio HW like the Intel audio DSP or some HDA controllers do
expose stream position HW registers and I do intend to map the DSP
stream pointers as RO "registers" to guests (as a virtual device PCI
BAR). 

> 
> 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?

My understanding from the spec is that the params from frames and
buffers are sent during PCM initialisation so these should be passed by
the device driver to the HW. I don't see any new formats being added
here either as this has been mature for a long time.

Thanks

Liam
>