On 19.11.2019 17:09, Liam Girdwood wrote:
On Wed, 2019-11-13 at 10:44 +0100, Anton Yakovlev wrote:
On 12.11.2019 19:02, Liam Girdwood wrote:
On Tue, 2019-11-12 at 17:05 +0100, Jean-Philippe Brucker wrote:
snip
And here I want to talk about real issue. I already mentioned it a
few times:
operating system schedulers. You describe low latency solution, but
you didn't
explain how are you gonna support realtime properties. The closer to
hw
position we read/write - the easier to miss a deadline.
This is hypervisor/HW/guest specific and unrelated to this proposal.
In general if I have guest core affinity then hypervisor context
switching for that guest is in low 10s of uS (depends on hypervisor of
course and HW). This is good enough for low latency audio.
Honestly, I'm not sure whether this relates to the proposed spec or not.
I want to describe an experiment we conducted regarding possible zero-copy
approach. We had simple audio device in QEmu and simple ALSA driver in virtual
guest.
The driver basically allocated a buffer, allowed to mmap it into user-space
application and shared this memory with the device (i.e. device could access
the whole buffer at any moment of time). Then we shared yet one memory page
where we placed current application pointer value. We did it in order to avoid
possible issues with sharing actual ALSA control page. Also, we used
the SNDRV_PCM_INFO_SYNC_APPLPTR feature to enforce the application to notify
kernel on every position update. Thus, we could update our shared application
pointer value immediately. As a hardware position we returned estimated one
(frame rate * elapsed time).
On playback stream start, QEmu device activated a dedicated thread (SCHED_FIFO
/ high priority) that waked up every 10ms, shifted its own position value to
10ms and compared it with current application pointer value.
In short, we tried to simulate the closest possible HW behavior for zero-copy
low latency case. It might be not so perfect, but at least it gave us more or
less accurate estimation.
A host had 4 physical cores (2 cores with enabled HT), a guest had 4 vcpus
and we used as a test PA and some low latency applications (like voice call
and so on). And we observed empty buffer ~1-2 times per second. It
would most probably mean underrun conditions if it were a real zero-copy
implementation. Also we found out that different Linux distros as a guest give
different results (but always not so good for audio). :)
From other side, we also had a host with 8 physical cores (4 cores with
enabled HT) and a guest had the same 4 vcpus. And there the same setup worked
perfectly.
That's why we are really curious how other people target such issues with
audio virtualization. And that's why I'm not sure about the spec in this
regard. We could say something like "you can activate zero-copy mode, but it's
up to your HW, OS and luck", but it does not sound very nicely.
--
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
