qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/7] usb: remove old usb-host code


From: Hans de Goede
Subject: Re: [Qemu-devel] [PATCH 1/7] usb: remove old usb-host code
Date: Mon, 11 Nov 2013 20:28:36 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

Hi,

On 11/11/2013 09:47 AM, Gerd Hoffmann wrote:
On Fr, 2013-11-08 at 17:51 +0100, Jan Kiszka wrote:
On 2013-11-08 16:39, Gerd Hoffmann wrote:
   Hi,

OK, then here is the first issue I ran into while trying libusbx (git
head, i.e. 1.0.17+: The new stack causes significant latency issues that
makes it almost unusable for pass-through of USB audio devices (some
headset in my case). Reverting usb-linux and disabling libusb over QEMU
git head makes things work again. I'll have to stick with this for now
as it is affecting my work environment.

Any spontaneous ideas how to analyse or even resolve this?

Try setting isobsize property to something smaller than 32 (which is the
default).

OK, isobsize=2 and isobufs=32 helped, possibly other combinations as
well - but not just reducing isobsize or increasing isobufs. Any theory
about this? How can we find better defaults?

isobsize is the size of a single buffer (in MaxPacketSize units).
isobufs is the number of buffers in the ring.

So the total ring buffer size is MaxPacketSize * isobsize * isobufs.

isobsize basically trades overhead for latency.  Larger numbers reduce
the overhead, smaller numbers reduce latency.

isobufs should be as small as possible.  Start with 4 (default).  If you
get overruns/underruns increase.

We should probably look at the endpoint interval, then calculate how
many packets we should expect within a certain time range and use that
as additional factor for the buffer size.  That should get the defaults
closer to the actual needs of the device.

hw/usb/redirect.c actually has some code for that, you could use that as
a start for the host redirection code...

Regards,

Hans



reply via email to

[Prev in Thread] Current Thread [Next in Thread]