On 20.12.2019 13:41, Gerd Hoffmann wrote:
Hi,
Period notification would be implicit (playback buffer completion) or
explicit event queue message?
Good question. I think, for message-base transport they would be implicit,
since we will require to enqueue period_size length buffers. The only
Hi,
> > Period notification would be implicit (playback buffer completion) or
> > explicit event queue message?
>
> Good question. I think, for message-base transport they would be implicit,
> since we will require to enqueue period_size length buffers. The only
> exception here will be the end
Hi,
On 20.12.2019 08:53, Gerd Hoffmann wrote:
Hi,
qemu has rather small buffers backend buffers, to keep latencies low.
So, yes it would copy data to backend buffers. No, it would most likely
not copy over everything immediately. It will most likely leave buffers
in the virtqueue, reading
Hi,
> > qemu has rather small buffers backend buffers, to keep latencies low.
> > So, yes it would copy data to backend buffers. No, it would most likely
> > not copy over everything immediately. It will most likely leave buffers
> > in the virtqueue, reading the data piecewise in the audio ba
On 19.12.2019 08:17, Gerd Hoffmann wrote:
Hi,
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
On 18.12.2019 17:54, Mark Brown wrote:
On Wed, Dec 18, 2019 at 04:34:12PM +0100, Anton Yakovlev wrote:
On 18.12.2019 12:52, Gerd Hoffmann wrote:
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 i
Hi,
> > 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 dev
On 18.12.2019 12:52, Gerd Hoffmann wrote:
+/* 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 c
> > > +/* 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 capabil
Hi,
On 17.12.2019 15:45, Gerd Hoffmann wrote:
Hi,
+\subsection{Feature bits}\label{sec:Device Types / Sound Device / Feature bits}
+
+None currently defined.
Flags for hostmem & guestmem here?
This could be an information the driver might want to know before
initializing the virtqueues.
Hi,
> +\subsection{Feature bits}\label{sec:Device Types / Sound Device / Feature
> bits}
> +
> +None currently defined.
Flags for hostmem & guestmem here?
This could be an information the driver might want to know before
initializing the virtqueues.
> +\item START
> +\item PAUSE
> +\item UNP
11 matches
Mail list logo
