Re: [virtio-dev] Re: [PATCH] virtio-gpu: add shared resource feature
Hi,
> If the following scenario happens:
>
> 1) Driver sends RESOURCE_CREATE_2D shared request
> 2) Driver sends ATTACH_BACKING request
> 3) Device creates a shared resource
> 4) Driver sends SET_SCANOUT request
> 5) Device sends shared resource to display
> 6) Driver sends DETACH_BACKING request
Hmm, I think you can crash the current qemu code that way (didn't test
though). I think the proper solution would be to return -EBUSY on the
DETACH_BACKING request. Guess I'll add a new error code for that.
> > +Otherwise the shared resources are used like normal resources.
> > +Especially the driver must send explicit VIRTIO_GPU_CMD_TRANSFER_*
> > +commands to the device for both normal and shared resources. Reason:
> > +The device might have to flush caches.
>
> Can we make this spec stronger to avoid to avoid transfers all the
> time (i.e, in virtio_gpu_update_dumb_bo)?
>
> drm_gem_shmem_* helpers seem to use WC buffers, and dumb buffers are
> traditionally WC as well. If we mandate the host ("device?" here)
> must properly clean caches at creation time, it may be possible to
> avoid hypercalls for 2D_SHARED resources.
I think we can do 90% of that optimization without changing the
protocol. Display updates typically involve multiple commands. A
transfer, possibly a set-scanout (when page-flipping), finally flush.
The driver can first queue all commands, then notify the host, so we
will have only one vmexit per display update instead of one vmexit per
command.
> > The device MAY also choose to
> > +not create mapping for the shared resource. Especially for small
> > +resources it might be more efficient to just copy the data instead of
> > +establishing a shared mapping.
>
> Should the device send a response code (OK_SHARED} to inform the
> driver that the resource is shared?
Is there a good reason why the driver should be aware of that?
I'd prefer to make that an internal implementation detail of
the device and not inform the guest.
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
[virtio-dev] Re: [PATCH] virtio-gpu: add shared resource feature
On Thu, Nov 28, 2019 at 5:20 AM Gerd Hoffmann wrote:
>
> This patch adds a new virtio feature for shared resources.
>
> Shared resources are allocated by the guest from normal ram, like
> traditional resources. They can be used by the guest almost like
> traditional resources, the only exception is that shared resources can
> only be used with backing storage attached (the linux driver does that
> anyway so the workflow doesn't change). The host can map these
> resources and use them directly (using udmabuf), so any guest changes to
> these resources can be visible on the host without explicit transfer
> request. Transfer requests are still needed though as the host might
> still have syncronize the resource, for example in case importing the
> udmabuf failed for some reason.
>
> guest/host interface: Two new commands are added to create 2D and 3D
> shared resources. They work exactly like the non-shared counterparts.
>
> qemu patches:
> https://git.kraxel.org/cgit/qemu/log/?h=sirius/virtio-gpu-feature-shared
>
> linux patches:
> https://git.kraxel.org/cgit/linux/log/?h=drm-virtio-feature-shared
>
> Signed-off-by: Gerd Hoffmann
> ---
> virtio-gpu.tex | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/virtio-gpu.tex b/virtio-gpu.tex
> index 15dbf9f2ec82..ca27b3d5fa45 100644
> --- a/virtio-gpu.tex
> +++ b/virtio-gpu.tex
> @@ -35,6 +35,7 @@ \subsection{Feature bits}\label{sec:Device Types / GPU
> Device / Feature bits}
> \begin{description}
> \item[VIRTIO_GPU_F_VIRGL (0)] virgl 3D mode is supported.
> \item[VIRTIO_GPU_F_EDID (1)] EDID is supported.
> +\item[VIRTIO_GPU_F_RESOURCE_SHARED 2)] shared resources are supported.
> \end{description}
>
> \subsection{Device configuration layout}\label{sec:Device Types / GPU Device
> / Device configuration layout}
> @@ -103,6 +104,8 @@ \subsubsection{Device Operation: Create a framebuffer and
> configure scanout}
>
> \begin{itemize*}
> \item Create a host resource using VIRTIO_GPU_CMD_RESOURCE_CREATE_2D.
> + In case VIRTIO_GPU_F_RESOURCE_SHARED is negotiated the driver can
> + also use VIRTIO_GPU_CMD_RESOURCE_CREATE_2D_SHARED.
> \item Allocate a framebuffer from guest ram, and attach it as backing
>storage to the resource just created, using
>VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING. Scatter lists are
> @@ -166,6 +169,28 @@ \subsubsection{Device Operation: Configure mouse cursor}
> the pointer shape and position. To move the pointer without updating
> the shape use VIRTIO_GPU_CMD_MOVE_CURSOR instead.
>
> +\subsubsection{Device Operation: Shared resources}
> +
> +In case VIRTIO_GPU_F_RESOURCE_SHARED is negotiated the driver can use
> +the VIRTIO_GPU_CMD_RESOURCE_CREATE_2D_SHARED command to create shared
> +resources. Normal resources have both a guest buffer and host buffer
> +buffer for the resource and the VIRTIO_GPU_CMD_TRANSFER_* commands are
> +used to transfer data between host and guest. Shared (guest
> +allocated) buffers CAN be used directly by the host, to remove or
> +reduce the data copies needed.
> +
> +The driver MUST attach backing storage to a shared resource before
> +using it. Any changes on the shared resource MAY be instantly visible
> +on the host.
If the following scenario happens:
1) Driver sends RESOURCE_CREATE_2D shared request
2) Driver sends ATTACH_BACKING request
3) Device creates a shared resource
4) Driver sends SET_SCANOUT request
5) Device sends shared resource to display
6) Driver sends DETACH_BACKING request
How do we synchronize between (5) and (6)? Is there a guarantee the
shared pages won't go back to guest RAM, and will be owned by the
display (like traditional dma-bufs)?
> +
> +Otherwise the shared resources are used like normal resources.
> +Especially the driver must send explicit VIRTIO_GPU_CMD_TRANSFER_*
> +commands to the device for both normal and shared resources. Reason:
> +The device might have to flush caches.
Can we make this spec stronger to avoid to avoid transfers all the
time (i.e, in virtio_gpu_update_dumb_bo)?
drm_gem_shmem_* helpers seem to use WC buffers, and dumb buffers are
traditionally WC as well. If we mandate the host ("device?" here)
must properly clean caches at creation time, it may be possible to
avoid hypercalls for 2D_SHARED resources.
> The device MAY also choose to
> +not create mapping for the shared resource. Especially for small
> +resources it might be more efficient to just copy the data instead of
> +establishing a shared mapping.
Should the device send a response code (OK_SHARED} to inform the
driver that the resource is shared? If the device can choose not to
create shared mappings, would the response code +
VIRTIO_GPU_CMD_RESOURCE_CREATE_2D + the feature flag suffice (i.e, no
VIRTIO_GPU_CMD_RESOURCE_CREATE_2D_SHARED)?
> +
> \subsubsection{Device Operation: Request header}\label{sec:Device Types /
> GPU Device / Device Operation / Device Operation: Request header}
>
> All requests and responses on the v
Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification
On Wed, Dec 4, 2019 at 1:16 AM Gerd Hoffmann wrote:
>
> Hi,
>
> > 1. Focus on only decoder/encoder functionalities first.
> >
> > As Tomasz said earlier in this thread, it'd be too complicated to support
> > camera
> > usage at the same time. So, I'd suggest to make it just a generic mem-to-mem
> > video processing device protocol for now.
> > If we finally decide to support camera in this protocol, we can add it
> > later.
>
> Agree.
>
> > 2. Only one feature bit can be specified for one device.
> >
> > I'd like to have a decoder device and encoder device separately.
> > It'd be natural to assume it because a decoder and an encoder are provided
> > as
> > different hardware.
>
> Hmm, modern GPUs support both encoding and decoding ...
>
> I don't think we should bake that restriction into the specification.
> It probably makes sense to use one virtqueue per function though, that
> will simplify dispatching in both host and guest.
>
> > 3. Separate buffer allocation functionalities from virtio-video protocol.
> >
> > To support various ways of guest/host buffer sharing, we might want to have
> > a
> > dedicated buffer sharing device as we're discussing in another thread.
> > Until we
> > reach consensus there, it'd be good not to have buffer allocation
> > functionalities in virtio-video.
>
> I think virtio-video should be able to work as stand-alone device,
> so we need some way to allocate buffers ...
>
> Buffer sharing with other devices can be added later.
>
> > > +The virtio video device is a virtual video streaming device that
> > > supports the
> > > +following functions: encoder, decoder, capture, output.
> > > +
> > > +\subsection{Device ID}\label{sec:Device Types / Video Device / Device ID}
> > > +
> > > +TBD.
> >
> > I'm wondering how and when we can determine and reserve this ID?
>
> Grab the next free, update the spec accordingly, submit the one-line
> patch.
>
> > > +\begin{lstlisting}
> > > +enum virtio_video_pixel_format {
> > > + VIRTIO_VIDEO_PIX_FMT_UNDEFINED = 0,
> > > +
> > > + VIRTIO_VIDEO_PIX_FMT_H264 = 0x0100,
> > > + VIRTIO_VIDEO_PIX_FMT_NV12,
> > > + VIRTIO_VIDEO_PIX_FMT_NV21,
> > > + VIRTIO_VIDEO_PIX_FMT_I420,
> > > + VIRTIO_VIDEO_PIX_FMT_I422,
> > > + VIRTIO_VIDEO_PIX_FMT_XBGR,
> > > +};
> >
> > I'm wondering if we can use FOURCC instead. So, we can avoid reinventing a
> > mapping from formats to integers.
> > Also, I suppose the word "pixel formats" means only raw (decoded) formats.
> > But, it can be encoded format like H.264. So, I guess "image format" or
> > "fourcc" is a better word choice.
>
> Use separate pixel_format (fourcc) and stream_format (H.264 etc.) enums?
>
> > > +\begin{lstlisting}
> > > +struct virtio_video_function {
> > > + struct virtio_video_desc desc;
> > > + __le32 function_type; /* One of VIRTIO_VIDEO_FUNC_* types */
> > > + __le32 function_id;
> > > + struct virtio_video_params in_params;
> > > + struct virtio_video_params out_params;
> > > + __le32 num_caps;
> > > + __u8 padding[4];
> > > + /* Followed by struct virtio_video_capability video_caps[]; */
> > > +};
> > > +\end{lstlisting}
> >
> > If one device only has one functionality, virtio_video_function's fields
> > will be
> > no longer needed except in_params and out_params. So, we'd be able to remove
> > virtio_video_function and have in_params and out_params in
> > virtio_video_capability instead.
>
> Same goes for per-function virtqueues (used virtqueue implies function).
>
> > > +\begin{lstlisting}
> > > +struct virtio_video_resource_detach_backing {
> > > + struct virtio_video_ctrl_hdr hdr;
> > > + __le32 resource_id;
> > > + __u8 padding[4];
> > > +};
> > > +\end{lstlisting}
> > > +
> > > +\begin{description}
> > > +\item[\field{resource_id}] internal id of the resource.
> > > +\end{description}
> >
> > I suppose that it'd be better not to have the above series of T_RESOURCE
> > controls at least until we reach a conclusion in the thread of
> > buffer-sharing
> > device. If we end up concluding this type of controls is the best way,
> > we'll be
> > able to revisit here.
>
As an interim solution, this form of "manual resource backing-store
management" could be specified as a feature flag.
Once there is an established solution for buffer sharing, we would
then go ahead and introduce a new feature flag for "works with the
buffer sharing mechanism", as an alternative to this manual mechanism.
wdyt?
> Well. For buffer management there are a bunch of options.
>
> (1) Simply stick the buffers (well, pointers to the buffer pages) into
> the virtqueue. This is the standard virtio way.
>
> (2) Create resources, then put the resource ids into the virtqueue.
> virtio-gpu uses that model. First, because virtio-gpu needs an id
> to reference resources in the rendering command stream
> (virtio-video doesn't need this). Also because (some kinds of)
> resour
Re: [virtio-dev] [PATCH] snd: Add virtio sound device specification
Hi, > > > For example, in case > > > of GUEST_MEM the request could be followed by a buffer sg-list. > > > > I'm not convinced guest_mem is that useful. host_mem allows to give the > > guest access to the buffers used by the hosts sound hardware, which is > > probably what you need if the MSG transport can't handle the latency > > requirements you have. > > Actually, it might be pretty useful. > > If a device is not capable of sharing host memory with a guest but still > capable of using guest shared memory, then there's a good use case for that: Note that "hostmem" only means that the buffer is allocated by the host (i.e. the device). Whenever the allocation is backed by actual host sound buffers or just normal ram depends on the device implementation and maybe the host sound hardware capabilities. Qemu would probably use normal ram due to the extra indirection caused by the sound backend interface. I don't think there is a use case which guestmem can handle but hostmem can not. > when a buffer is mapped into a user space application. It assumes, that the > driver is not involved in frame transfer at all (thus, it can not queue > buffers into a virtqueue and send notifications to the device). The sound data can actually be in userspace mapped buffers even for the message transport. Adding a buffer to the virtqueue (which actually stores pointer(s) to the buffer pages) effectively moves the application position then. But, yes, userspace must do a syscall for that which is not needed when updating the position in a shared page. > But if that > memory is shared with the device (as long as some piece of memory containing > an application position as well), then it's possible to implement quite > simple poller in the device. And it would be pretty aligned with common > software mixer workflow (like in PA or QEmu), where a mixer invokes client's > callbacks for reading/writing next piece of data. The device will need only > to check an application position and directly read from/write to a shared > buffer. Note that it is possible to store things in the virtqueue without notifying the device and expect the device poll the virtqueue instead. Likewise for the other direction. That allows operating the queue without vmexits and might work more efficient with lots of small buffers. Of course device and driver must negotiate whenever they want use polling or notifications. > > > If we gonna introduce any buffer constrains, it must be set by the > > > device in a stream configuration. > > > > If we want allow the device specify min/max period_bytes which it can > > handle, then yes, that should go into the stream configuration. > > > > Or we use negotiation: driver asks for period_bytes in set-params, the > > driver picks the closest period_bytes value it can handle and returns > > that. > > As I said before, periods are not used everywhere. Also, even in ALSA such > kind of negotiations may be non trivial. I would propose to leave choosing the > period_bytes value up to the driver. We could add yet one mandatory field to > the set_params request - driver's buffer size. (If the driver wants to use > period notification feature, then buffer_bytes % period_bytes must be 0). Sounds good to me. > > > But you described exactly "blockable" case: an I/O request is completed > > > not > > > immediately but upon some condition (the buffer is full). In case of > > > message- > > > based transport, both the device and the driver will have its own buffers. > > > > Well, no. The device doesn't need any buffers, it can use the buffers > > submitted by the driver. Typical workflow: > > > >(1) The driver puts a bunch of empty buffers into the rx (record/read) > >virtqueue (each being period_bytes in size). > >(2) The driver starts recording. > >(3) The device fills the first buffer with recorded sound data. > >(4) When the buffer is full the device returns it to the driver, > >takes the next from the virtqueue to continue recording. > >(5) The driver takes the filled buffer and does whatever it wants do > >with the data (typically pass on to the userspace app). > >(6) The driver submits a new empty buffer to the virtqueue to make > >sure the device doesn't run out of buffers. > > > > So, it's not a "here is a buffer, fill it please", "here is the next, > > ..." ping pong game between driver and device. There is a queue with > > multiple buffers instead, and the device fills them one by one. > > Then, should we make this pattern to be mandatory? It's pretty standard for virtio. The network receive queue works fundamentally the same way for example, except that network buffers actually might be half-filled only because you get network packets where you don't know the size beforehand instead of a constant stream of sound samples which you can easily pack into buffers as you like. But, yes, it probably makes sense to explicitly say so in the spe
Re: [virtio-dev] [PATCH] snd: Add virtio sound device specification
On 03.12.2019 10:00, Gerd Hoffmann wrote: ...snip... PCM_MSG -- I would drop the feature bit and make that mandatory, so we have a common baseline on which all drivers and devices can agree on. Then we need to inform device what "transport" will be in use (I assumed it would be feature negotiation). Whenever other transports (i.e. via shared memory) are supported: yes, that should be a feature bit. Not sure about choosing the transport. If both msg (i.e. via virtqueue) and shared memory are available, does it make sense to allow the driver choose the transport each time it starts a stream? Shared memory based transport in any case will require some additional actions. For HOST_MEM case the driver will need to get an access to host buffer somehow. In GUEST_MEM case the driver will need to provide a buffer for the host. At first sight, we could extend the set_params request with the transport_type field and some additional information. Or have a per-transport set_params request command. Or, since now we decided to make a message-based transport as a default one, at the moment we can go without explicit transport selection. Some additional extensions could be done at the future, when buffer sharing mechanism will be stabilized. For example, in case of GUEST_MEM the request could be followed by a buffer sg-list. I'm not convinced guest_mem is that useful. host_mem allows to give the guest access to the buffers used by the hosts sound hardware, which is probably what you need if the MSG transport can't handle the latency requirements you have. Actually, it might be pretty useful. If a device is not capable of sharing host memory with a guest but still capable of using guest shared memory, then there's a good use case for that: when a buffer is mapped into a user space application. It assumes, that the driver is not involved in frame transfer at all (thus, it can not queue buffers into a virtqueue and send notifications to the device). But if that memory is shared with the device (as long as some piece of memory containing an application position as well), then it's possible to implement quite simple poller in the device. And it would be pretty aligned with common software mixer workflow (like in PA or QEmu), where a mixer invokes client's callbacks for reading/writing next piece of data. The device will need only to check an application position and directly read from/write to a shared buffer. ...snip... If we gonna introduce any buffer constrains, it must be set by the device in a stream configuration. If we want allow the device specify min/max period_bytes which it can handle, then yes, that should go into the stream configuration. Or we use negotiation: driver asks for period_bytes in set-params, the driver picks the closest period_bytes value it can handle and returns that. As I said before, periods are not used everywhere. Also, even in ALSA such kind of negotiations may be non trivial. I would propose to leave choosing the period_bytes value up to the driver. We could add yet one mandatory field to the set_params request - driver's buffer size. (If the driver wants to use period notification feature, then buffer_bytes % period_bytes must be 0). If the device has its own intermediate buffer of any kind, it's possible to adjust this according to the buffer_bytes value (like making it's being no smaller than the specified size and so on). This way we could resolve original concerns regarding possible different buffer sizes. Also, the capture stream is a special case. Now we don't state explicitly whether read request is blockable or not. The concept of "blockable" doesn't exist at that level. The driver submits buffers to the device, the device fills them and notifies the driver when the buffer is full. It simply doesn't work like a read(2) syscall. But you described exactly "blockable" case: an I/O request is completed not immediately but upon some condition (the buffer is full). In case of message- based transport, both the device and the driver will have its own buffers. Well, no. The device doesn't need any buffers, it can use the buffers submitted by the driver. Typical workflow: (1) The driver puts a bunch of empty buffers into the rx (record/read) virtqueue (each being period_bytes in size). (2) The driver starts recording. (3) The device fills the first buffer with recorded sound data. (4) When the buffer is full the device returns it to the driver, takes the next from the virtqueue to continue recording. (5) The driver takes the filled buffer and does whatever it wants do with the data (typically pass on to the userspace app). (6) The driver submits a new empty buffer to the virtqueue to make sure the device doesn't run out of buffers. So, it's not a "here is a buffer, fill it please", "here is the next, ..." ping pong game between driver and device. There is a queue with multiple buffers instead, and
Re: [virtio-dev] [RFC RESEND] virtio-video: Add virtio video device specification
Hi,
> 1. Focus on only decoder/encoder functionalities first.
>
> As Tomasz said earlier in this thread, it'd be too complicated to support
> camera
> usage at the same time. So, I'd suggest to make it just a generic mem-to-mem
> video processing device protocol for now.
> If we finally decide to support camera in this protocol, we can add it later.
Agree.
> 2. Only one feature bit can be specified for one device.
>
> I'd like to have a decoder device and encoder device separately.
> It'd be natural to assume it because a decoder and an encoder are provided as
> different hardware.
Hmm, modern GPUs support both encoding and decoding ...
I don't think we should bake that restriction into the specification.
It probably makes sense to use one virtqueue per function though, that
will simplify dispatching in both host and guest.
> 3. Separate buffer allocation functionalities from virtio-video protocol.
>
> To support various ways of guest/host buffer sharing, we might want to have a
> dedicated buffer sharing device as we're discussing in another thread. Until
> we
> reach consensus there, it'd be good not to have buffer allocation
> functionalities in virtio-video.
I think virtio-video should be able to work as stand-alone device,
so we need some way to allocate buffers ...
Buffer sharing with other devices can be added later.
> > +The virtio video device is a virtual video streaming device that supports
> > the
> > +following functions: encoder, decoder, capture, output.
> > +
> > +\subsection{Device ID}\label{sec:Device Types / Video Device / Device ID}
> > +
> > +TBD.
>
> I'm wondering how and when we can determine and reserve this ID?
Grab the next free, update the spec accordingly, submit the one-line
patch.
> > +\begin{lstlisting}
> > +enum virtio_video_pixel_format {
> > + VIRTIO_VIDEO_PIX_FMT_UNDEFINED = 0,
> > +
> > + VIRTIO_VIDEO_PIX_FMT_H264 = 0x0100,
> > + VIRTIO_VIDEO_PIX_FMT_NV12,
> > + VIRTIO_VIDEO_PIX_FMT_NV21,
> > + VIRTIO_VIDEO_PIX_FMT_I420,
> > + VIRTIO_VIDEO_PIX_FMT_I422,
> > + VIRTIO_VIDEO_PIX_FMT_XBGR,
> > +};
>
> I'm wondering if we can use FOURCC instead. So, we can avoid reinventing a
> mapping from formats to integers.
> Also, I suppose the word "pixel formats" means only raw (decoded) formats.
> But, it can be encoded format like H.264. So, I guess "image format" or
> "fourcc" is a better word choice.
Use separate pixel_format (fourcc) and stream_format (H.264 etc.) enums?
> > +\begin{lstlisting}
> > +struct virtio_video_function {
> > + struct virtio_video_desc desc;
> > + __le32 function_type; /* One of VIRTIO_VIDEO_FUNC_* types */
> > + __le32 function_id;
> > + struct virtio_video_params in_params;
> > + struct virtio_video_params out_params;
> > + __le32 num_caps;
> > + __u8 padding[4];
> > + /* Followed by struct virtio_video_capability video_caps[]; */
> > +};
> > +\end{lstlisting}
>
> If one device only has one functionality, virtio_video_function's fields will
> be
> no longer needed except in_params and out_params. So, we'd be able to remove
> virtio_video_function and have in_params and out_params in
> virtio_video_capability instead.
Same goes for per-function virtqueues (used virtqueue implies function).
> > +\begin{lstlisting}
> > +struct virtio_video_resource_detach_backing {
> > + struct virtio_video_ctrl_hdr hdr;
> > + __le32 resource_id;
> > + __u8 padding[4];
> > +};
> > +\end{lstlisting}
> > +
> > +\begin{description}
> > +\item[\field{resource_id}] internal id of the resource.
> > +\end{description}
>
> I suppose that it'd be better not to have the above series of T_RESOURCE
> controls at least until we reach a conclusion in the thread of buffer-sharing
> device. If we end up concluding this type of controls is the best way, we'll
> be
> able to revisit here.
Well. For buffer management there are a bunch of options.
(1) Simply stick the buffers (well, pointers to the buffer pages) into
the virtqueue. This is the standard virtio way.
(2) Create resources, then put the resource ids into the virtqueue.
virtio-gpu uses that model. First, because virtio-gpu needs an id
to reference resources in the rendering command stream
(virtio-video doesn't need this). Also because (some kinds of)
resources are around for a long time and the guest-physical ->
host-virtual mapping needs to be done only once that way (which
I think would be the case for virtio-video too because v4l2
re-uses buffers in robin-round fashion). Drawback is this
assumes shared memory between host and guest (which is the case
in typical use cases but it is not mandated by the virtio spec).
(3) Import external resources (from virtio-gpu for example).
Out of scope for now, will probably added as optional feature
later.
I guess long-term we want support either (1)+(3) or (2)+(3).
cheers,
Gerd
Re: [virtio-dev] [PATCH] snd: Add virtio sound device specification
On 02.12.2019 14:55, Mark Brown wrote: On Mon, Dec 02, 2019 at 02:30:44PM +0100, Anton Yakovlev wrote: On 28.11.2019 13:19, Mark Brown wrote: If you're talking about compressed as opposed to PCM audio here (you say decompression) I think you probably want a different spec there, the flow control stuff is quite different and you often need a lot more configuration for compressed formats. Usually all such kind of things are tight together in one audio subsystem and in one audio driver. I don't think it has a sense to separate all kind of streams into different specs. All the Linux based systems split the data paths, and at the hardware level unless you're using a message based system (which is basically just software anyway) you need a different interface as you can't push data through the system at a constant rate which is a central assumption for PCM audio. Are we going to design separated specs for different audio features? It seems a little bit of overkill. -- Anton Yakovlev Senior Software Engineer OpenSynergy GmbH Rotherstr. 20, 10245 Berlin Phone: +49 30 60 98 54 0 E-Mail: anton.yakov...@opensynergy.com - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
