[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
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:
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-copyapproach. 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: email@example.com