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
likely
improve user experience, however the buffer ptr still suffers
latency
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
the
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
notifications.
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.
Cheers,
Matti
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
