[pvrusb2] Qemu and usb

[Mike Isely]

On Sun, 19 Oct 2008, Xavier Gnata wrote:

> Bjorn Danielsson wrote:
> > Mike Isely <isely at isely.net> wrote:
> >   
> >> On Sat, 18 Oct 2008, Bjorn Danielsson wrote:
> >> [...]
> >>     
> >>> I started playing with qemu recently, mainly for work-related things
> >>> that involve freebsd. I haven't tried it on my pvrusb2 box yet
> >>> but I am tempted.
> >>>       
> >> I'd be curious to know how well that works.  The key factor will 
> >> of course be how well qemu handles USB support.
> >>     
> >
> > I tried qemu on my tv box today. Making it work was unfortunately
> > not as straight-forward as I would have liked. The first problem
> > was that I had to compile qemu from source on that box, and the
> > qemu release won't compile with gcc-4. So I used the svn version
> > instead, and there the second problem showed up: usb support is
> > broken in the current svn. But I was able to fix that (and a patch
> > is in the pipeline) and after some fumbling with the qemu control
> > monitor I managed to redirect my 2040:2400 device to the guest OS.
> > At that point the drivers were loaded, the firmware was installed,
> > and the v4l devices were created. Then I tried capturing with
> > "cat /dev/video0" and it sort of worked. The sound was ok but
> > about half of the video frames were missing so the picture was
> > jerky in mplayer (when played later on another machine).
> >
> >   
> 
> Well I have learned that qemu (or kvm) has no usb2 support. Only usb1 
> (no way plug my ipod under kvm).
> 
> One great chanlenge to get usb2 support in qemu is to find a way to 
> implement EHCI without having to rely on very accurate timers.
> IMHO, it is why you can see missing frames.

The PVR-USB2 hardware can work at USB1.1 rates, so long as the 
configured bit rate is slow enough, which is the case for the pvrusb2 
device driver's default configuration and IIRC should be true for the 
Windows driver.

Also since we're dealing with mpeg data and not uncompressed video, then 
the stream is effectively self-timed and not itself sensitive to jitter 
/ lag in the delivery, so long as there is enough buffering in the 
playback.  As long as the byte stream itself is intact then it should be 
usable.  If however qemu is corrupting the byte stream then of course 
there will be problems.

One test you can try is to capture to a file rather than directly using, 
say, mplayer to display the video.  I learned a while back that mplayer 
is actually quite sensitive to stream jerkiness / realtime delays / 
gaps.  This is why mplayer can sometime show stuttering / blockiness on 
a channel change - because the hardware has to stop the stream for a few 
moments during the channel change.  But if you capture to a file and 
play that back instead, then mplayer "sees" a continuously available 
stream and will actually behave better.  If this trick helps under qemu 
then the problem is not that stream data is being corrupted but rather 
that the stream is too jittery.

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8