On Thu, May 09, 2019 at 02:27:10PM +0200, Gerd Hoffmann wrote:
> > For the sake of the specification I think we need to focus on is how to
> > transport these streams and how to share a configuration for each one.
> 
> I think we need at least three virt queues.  One control queue for
> commands (query capabilities, set configuration, start/stop streams,
> volume control, ...).  One queue for input streams.  One queue for
> output streams.
> 
> If we want allow for multiple inputs/outputs we have basically two
> options: (a) one queue per stream, or (b) use a small header for each
> data packet, telling what stream it belongs to.
> 
> Maybe a small header is a good idea anyway, for timestamps.

I agree with the 3 virtqueue layout.

Multiplexing streams over a single input/output virtqueue pair has pros
and cons.  Overall I think it's a good fit though:
+ Number of streams can change at runtime (virtqueues are static!)
+ Easy to handle multiple inputs/outputs
+ Ability to synchronize streams, including transferring buffers for
  multiple streams in a single message with a single timestamp
- Virtqueue must be sized to handle maximum simultaneous streams without
  running out of descriptors
- Extra latency (jitter) and locking requirements due to sharing
  virtqueues between streams even if they are processed on different
  vCPUs

Stefan