Re: [Qemu-devel] USB streaming [Re: [PATCH 18/18] usb: add ehci adapter]

[David Ahern]

On 05/17/11 12:44, Hans de Goede wrote:
> Hi,
> 
> On 05/17/2011 07:43 PM, David Ahern wrote:
>> On 05/17/11 11:36, Hans de Goede wrote:
>>> Very likely it won't be needed both the guest OS, as well as any
>>> emulated hardware (or redirection code) will be doing some amount of
>>> buffering. Normal bufferering for usb video devices is 32 iso packets
>>> per urb and then 2-4 queued urbs, so that means that the OS does not
>>> even ask to be bothered with iso transfers till 32 of them have
>>> completed,
>>> or in other words 4 ms have passed in the usb 2 case with an endpoint
>>> with the lowest possible interval.
>>
>> I got audio streaming working nicely through UHCI in early 2010. The
>> qemu patch is:
>> http://www.mail-archive.com/address@hidden/msg28185.html
>>
>> I noticed a lot of timing issues related to when the UHCI frame timer
>> ran and saw the pending requests from the guest.
> 
> Given the nature of isoc data streams, tricks like you did can only
> go so far. If you look at the patches which I did for isochroneous
> data buffering, which are in kraxel's latest usb pull request
> (tested with usb 1 webcams and audio devices), you see that they add a
> small fifo between the real device and the emulated uhci controller,
> this allows to handle iso request synchronously by simply
> taking the next packet from the buffer for input streams, or storing it
> into the buffer for output streams.

interesting.

> 
> With these patches in place I can significantly lower the wakeup rate
> of the UHCI emulation (and handle multiple frames at once on wakeup
> without any ill effects and a nice drop in CPU load.

that's good.

> 
> Note that once every while a packet will get lost since normally a usb
> device is synced to the usb frame timer, but the real and emulated frame
> timer
> are not synced, so eventually a packet will get lost.

I noticed that as well. The guest uhci driver (linux at least) guesses
where to put the initial request (10 frames out as I recall). From there
the requests need to flow - responses come into the guest, requests are
appended to the stream.

One missed packet in the guest causes the driver to "start over" -- ie,
it's no longer a stream, but an initial request placed 10 frames out.
That causes an ugly jitter, and if the qemu controller happens to be
past the '10 frames out' guess by the OS you get a 1+ sec gap of silence.

David

> 
> Regards,
> 
> Hans