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

[Gerd Hoffmann <kraxel@redhat.com>]

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

You need:

  (1) control queue (guest -> host commands)
  (2) events queue (host -> guest notifications, but see below)
  (3) tx queue (playback)
  (4) rx queue (recording)

You can allow multiple rx/tx pairs, not sure multiqueue support buys us
much for audio though.

The tx/rx queue requests should have three elements: a small request
header (out), a small request status (in), and one (or more) data
buffers (out for tx, in for rx) for the actual sample data (see also
the more verbose comment elsewhere in this thread).

The request status can probably be used to notify the guest about
overruns and underruns, so maybe the event queue is not needed.

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

feature bits handle this.  The device knows which features are supported
by the driver and can act accordingly.  Reserved fields in structs might
make sense to simplify that (avoid struct layout change depending on
feature bits).

cheers,
  Gerd