I would point out that there is a infrastructure in the latest qemu repository to allow a shared memory region between the host and the guest: <a href="http://www.linux-kvm.org/wiki/images/e/e8/0.11.Nahanni-CamMacdonell.pdf">http://www.linux-kvm.org/wiki/images/e/e8/0.11.Nahanni-CamMacdonell.pdf</a> <a href="http://lwn.net/Articles/380869/">http://lwn.net/Articles/380869/</a><br> <br><div class="gmail_quote">On Fri, Sep 24, 2010 at 13:58, Jeremy Nickurak <span dir="ltr"><<a href="mailto:jeremy@nickurak.ca">jeremy@nickurak.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="gmail_quote"><div class="im">On Fri, Sep 24, 2010 at 10:19, Tomasz Torcz <span dir="ltr"><<a href="mailto:tomek@pipebreaker.pl" target="_blank">tomek@pipebreaker.pl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div> Has qemu informed PA about required latency? There's an API for that.</div></blockquote><div><br></div></div><div>That's a really hard piece of information to provide, in general at the VM-level, because various applications inside the VM may require different latency guarantees.</div> <div><br></div><div>That said, this makes me wonder if the idea of virtualizing a sound card isn't the right approach here, and instead, the pulse clients (be they native or via the alsa pulse plugin) should be contacting a pulseaudio server on the host? Would it be more feasible to manage latency this way? </div> </div><br><font color="#888888">-- <br><div style="text-align: right;">Jeremy Nickurak -= Email/XMPP: -= <a href="mailto:jeremy@nickurak.ca" target="_blank">jeremy@nickurak.ca</a> =- </div><br> </font></blockquote></div><br><br clear="all"><br>-- <br><div style="text-align: right;">Jeremy Nickurak -= Email/XMPP: -= <a href="mailto:jeremy@nickurak.ca" target="_blank">jeremy@nickurak.ca</a> =- </div><br>