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

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

On Wed, 2019-11-13 at 10:05 +0100, Anton Yakovlev wrote:
> > > > > 
> > > > > Since xrun conditions are higher level conceptions, we
> > > > > decided to
> > > > > delegate
> > > > > such issues to guest application itself. It helps to make
> > > > > overall
> > > > > design
> > > > > simpler. And it seems there's not so much we can do if xrun
> > > > > condition
> > > > > is
> > > > > happened on the device side.
> > > > 
> > > > We can inform the guest. The guest userspace can then take any
> > > > remedial
> > > > action if needed.
> > > 
> > > Then, we need the third queue for notifications.
> > 
> > Why, this should go in the queue that's used for stream position ?
> 
> Then, the I/O queue will multiplex already three things: read
> requests, write 
> requests and notifications. The question is how rational is it.

If there is no multiplexing, then we probably need 4 queues per virtual
PCM:

1) Playback data
2) Playback notifications
3) Capture data
4) Capture notifications

additionally, if we include a controls (like volume, mixer etc) we can
also include:

5) control W data
6) control R data

Latency is important for 1 - 4 (where multiplexing may not be
desirable), but 5 & 6 can be easily multiplexed for multiple controls.

> 
> 
> > > 
> > > 
> > > > > 
> > > > > 
> > > > > > 2) Zero copy of audio data and stream positions. Essential
> > > > > > for
> > > > > > any
> > > > > > low
> > > > > > latency audio use cases (if supported by HW, hypervisor, VM
> > > > > > framework).
> > > > > 
> > > > > What do you mean by zero-copy? Shared memory between device
> > > > > and
> > > > > driver sides?
> > > > 
> > > > Yes, but I see this is now a separate thread as it used by
> > > > others
> > > > too.
> > > 
> > > Shared memory based approach was proposed in the very first
> > > version
> > > of the
> > > spec (and we are rooting for this). Then there was discussion and
> > > it
> > > was
> > > postponed for some future virtio device. One of the reason - it's
> > > not
> > > suitable
> > > for arch with non-coherent memory between host and guest.
> > 
> > I'm rooting for this too. I do think we need to be a bit more
> > flexible
> > so we can deal with non coherent architectures via a SW virtio copy
> > and
> > support coherent architectures via zero copy.
> > 
> > We should be good as long as we can leave some configuration
> > space/types in the stream config to allow mapping of operating
> > modes
> > (zero copy, periodic, mmap etc). The device driver should also send
> > it's capabilities during init so that guests will know what use
> > cases
> > and modes are supported.
> 
> Yes, we can use device feature bits for this.

Can we also include some reserved words to ease spec updates ? e.g.
guest is using older version of spec than device driver but we still
want working audio.

Thanks

Liam