[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH] snd: Add virtio sound device specification
> > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]