OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[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

Hi Liam,

On 12.11.19 19:02, Liam Girdwood wrote:
On Tue, 2019-11-12 at 17:05 +0100, Jean-Philippe Brucker wrote:
This would be a good improvement, it's less copying and would
improve user experience, however the buffer ptr still suffers
as it's queued (same for stream positions going the other way).

Right if the queuing overhead is still too large, then I don't think
current virtqueues can be used.

They can be used for non low latency audio, I don't see any issues if
latency is not important. e.g. media playback, some gaming, most system

You are absolutely right that the virtques come with some overhead that is probably acceptable in many use cases.

The trick for even lower latency will be to use the fancy new virtio shared-mem feature, this will allow making a piece of shared memory between the audio DSP/sound device and the guest available that contains the current sample buffer and the HW position register. Thus, once this is set-up, the DSP and the guest can directly communicate without the VMM or the virtual device being involved at all.

Maybe it's even enough to just have a single register containing the hardware buffer position in shared mem?

Of course this has to be guarded by a feature flag but it would allow true zero copy audio where instead of using the queues you would just have the producer and consumer free-running without interruptions (as long es everything is fine).

The buffer layout is probably the trickiest thing here, how can we know what the hardware expects? If we add all known buffer formats now, how can we know if they are sufficient for future hardware? Does it make sense to wait and add additional buffer formats as they become necessary and known?

For the "simple" things like desktop virtualization and all the other boring audio use cases using the queues and playing with the driver/device kick and interrupt suppression seems to be sufficient to reach the respective latency requirements.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]