> > > +/* supported PCM stream features */ > > > +enum { > > > + VIRTIO_SND_PCM_F_HOST_MEM = 0, > > > + VIRTIO_SND_PCM_F_GUEST_MEM, > > > > Is this useful as stream property? I would expect when supported by a > > device it would work for all streams. > > Since we allowed different capabilities for different streams, now it's > possible to have different backends for them. I’m not sure how much this can > be a real scenario, but it is theoretically possible to have one backend that > is able to work with shared memory, and the other is not. The same can be said > for other stream feature bits.
Hmm, ok. Point. Independant from that they should either be a note that these two are nor (yet) specified and are just placeholders. Or simply be deleted and re-added with the actual specification for guestmem + hostmem. > > > + VIRTIO_SND_PCM_F_EVT_PERIOD, > > > > I think this is only useful for hostmem/guestmem. > > Using message-based transport, an application can send the entire playback > buffer at the beginning, and then send period-sized parts on each period > notification. The driver can still split the data from the application into a set of smaller virtio buffers. And this is how I would write a driver. Create a bunch of buffers, period_bytes each, enough to cover buffer_bytes. Then go submit them, re-use them robin-round (each time the device completes a buffer re-fill and re-submit it), without a special case with one big buffer for the (playback) stream start. I still think this is not needed for message-based transport. Maybe this is not needed for hostmem/guestmem either. The point of using shared memory is to avoid system calls and vmexits for buffer management, so VIRTIO_SND_PCM_F_EVT_PERIOD doesn't look that useful here too. But maybe it is nice to have that as option. > > > +\subsubsection{PCM I/O Messages}\label{sec:Device Types / Sound Device / > > > Device Operation / PCM IO Messages} > > > + > > > +An I/O message consists of the header part, followed by the buffer, and > > > then > > > +the status part. > > > > Each buffer MUST (or SHOULD?) be period_bytes in size. > > > > The driver SHOULD queue (buffer_bytes / period_bytes) virtio buffers, so > > the device has buffer_bytes total buffer space available. > > I think, it's better not to set queued buffer size restrictions. Lets make it SHOULD then. > Periods are an optional feature. If the driver is not interested in > period notifications, it's unclear what period_bytes means here. Well, the driver has to manage buffers, so I can't see how a driver is not interested in completion notifications. If the driver isn't interested in keeping the latency low by using lots of small buffers it still needs to queue at least two (larger) buffers, so the device still has data to continue playback when it completed a buffer. And the driver needs to know when the device is done with a buffer so it can either recycle the buffer or free the pages. > Although, for the input stream we could say, that the total size of > buffers in the rx queue should be buffer_bytes. Yes. cheers, Gerd --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org