$Id: pvrusb2-faq.html,v 1.11 2005/06/06 00:15:29 isely Exp $
Mike Isely <isely at pobox dot com>
The home location for this page is here.
This page describes list of common pitfalls (in no particular order) and their corresponding solutions when using the pvrusb2 linux driver. I have gathered up this list from e-mail correspondence over time. If there are things you think should be added here, please let me know.
Feel free to e-mail me if you have any other questions.
Mike Isely <isely at pobox dot com>
That's because I screwed up when reworking the build process with the 20050527 snapshot. We're using Kbuild and the correct internal target is "modules_install" not "install". Previous snapshots should be OK because they predate the bug. Anything after 20050527 should be OK because it's been fixed. Note that in any case if you follow the procedure on the pvrusb2.html, then you're copying the modules by hand anyway, in which case this isn't an issue.
There are multiple possible causes for this problem. Check the following:
- Is msp3400.ko present and loaded? Try lsmod | grep msp3400. The pvrusb2 driver itself does not directly control the sound processor; instead that duty is offloaded to msp3400.ko which is included with video4linux (and the ivtv driver and for completeness there's a spare copy included with the driver snapshot). You need to ensure that msp3400.ko can be loaded. The driver will attempt to pull it in via modprobe when the driver itself is loaded, but any failure of that attempt will be silent (literally and figuratively). If it isn't there, then either rebuild your kernel with the module enabled within video4linux or ensure that you've installed the spare copy included with this snapshot.
- Did you just run xawtv and now you're trying to use mplayer (or probably anything else that pulls mpeg video)? In this case, xawtv mutes the audio on exit, and it will stay muted if the next application doesn't do anything to change the situation. This is in fact what will happen with mplayer if you run it in "dumb" mode. You can fix this by manually unmuting the sound using the sysfs interface. Turn off the "mute" control (and see the main pvrusb2 web page for information on how to use the sysfs interface).
- Is the driver's audio volume too low? Check that your app (e.g. xawtv) has the volume up.
- Check your mixer settings. Make sure your pcm channel is unmuted and the volume is high enough.
The problem is that the xbox has an I2C adapter controller in the xbox Linux software that is very hostile to the presence of other I2C busses showing up in the system. The pvrusb2 hardware has an internal I2C bus. The fix for this is to patch the xbox Linux software. Contact me for a patch.
Possibly your system isn't keeping up with the driver's bit rate. There are some things you can do to determine what is going on:
- Run top while running your app. How much CPU is left over? If you have less than about 20% CPU left (approx guess), then I'd suggest you need a faster system.
- Is the pvrusb2 device really connected to a USB2.0 controller and / or hub? Run usbview to inspect the device and see what rate it is going at. You may have problems if you are only running the device at USB 1.1 "hi-speed" rate.
- Try tweaking the video rendering settings of your app. For example, with mplayer, the "xv" output setting uses the XVideo extension and tries to do hardware video scaling - if your video card doesn't do hardware scaling very well, then the CPU could be getting taxed. Try the "x11" output setting and see if things improve. (In this case, top will likely reveal that you're gassing out the CPU.)
- Separate the video capture operation from the video rendering operation and see which side is taking all the CPU: Try just cat'ing /dev/video0 (or whatever the pvrusb2 device got assign) into a file. Then view that file in a separate step with mplayer. Look at the CPU utilization (e.g. use top) during both steps and see which part is taking all the CPU.
It is possible to have a very fast system but still have lousy video rendering performance. Good video rendering depends a lot on the video card you are using. For example I have found that Nvidia 5200-class video cards do hardware video scaling significantly better than ATI 9200-class video cards.
There are multiple possible causes for this problem. Check the following:
- Is tuner.ko present and loaded? Try lsmod | grep tuner. The pvrusb2 driver itself does not directly control the tuner; instead that duty is offloaded to tuner.ko which is included with video4linux (and the ivtv driver and for completeness there's a spare copy included with the driver snapshot). You need to ensure that tuner.ko can be loaded. The driver will attempt to pull it in via modprobe when the driver itself is loaded, but any failure of that attempt will be silent. If it isn't there, then either rebuild your kernel with the module enabled within video4linux or ensure that you've installed the spare copy included with this snapshot.
- You might have a Hauppauge "type 58" tuner in your pvrusb2. Some versions of tveeprom.ko floating around don't correctly map this to a type that tuner.ko can use - which then causes tuner.ko to give up trying to control your tuner. Do you see something like this in your system log?
tveeprom: tuner = Philips FM1236 MK3 (idx = 58, type = 4)If you do, then you have a type 58 tuner and it isn't being mapped properly (the mapped value "type = 4" part indicates a bad mapping. Definitely if you are using the tveeprom.ko that is part of your kernel tree then this may be a problem. Try using the tveeprom.ko module that is part of this driver snapshot. The main pvrusb2 web page has more information about this.
- You might have a tuner that is more recent than can be recognized by tveeprom.ko and / or tuner.ko. So far I know of no instances of this particular problem, but it can happen. This is a more general variant of the "type 58" problem above. Try to locate and use later versions of tuner.ko and tveeprom.ko - and please tell me if this happens.
There are multiple possible causes for this problem. Check the following:
- Any version of xawtv before 4.x has no chance - those earlier versions could not decode an mpeg2 stream. Update to something in 4.x if you are trying an older verison.
- You might not have compiled xawtv correctly. If the configuration step didn't find ffmpeg (I think) then it won't compile in any mpeg2 decoding logic and then you're no better off that a 3.x version. Similarly, it has to find and configure an mp3 decoder in order to correctly decode the audio.
- You might have a broken 4.x xawtv snapshot. Versions from early February 2005 are known to work (been using that as a test case). However there was a video streaming bug found & fixed around 20-May-2005 that would have prevented snapshots prior to that from working properly (and I guess since my Feb version worked, the bug must have been introduced into the code some time after that point).
Even though this driver is a video4linux driver, and mplayer is able to handle video4linux devices, you can't run mplayer against this driver in such a way that mplayer tries to treat it as a video4linux device. What happens when you try is that mplayer (1) can't grok v4l frames as mpeg2 data, and (2) even if it could, mplayer tries to use mmap() style I/O to fetch the video "frames" and that is not currently supported by the pvrusb2 driver.
The way to make mplayer work is just to not do anything special. Specify your video device name (e.g. /dev/video0) as the "file" to read - mplayer will then happily stream plain old mpeg2 data from the device. Yes, I know that means you can't use mplayer to adjust the device's controls, like for example changing the channel. However you can still use the driver's sysfs interface to do this while mplayer is running.
Another alternative solution you can try is the patched mplayer available with the ivtv driver. I haven't tried this, but I suspect the ivtv driver author patched mplayer to deal with exactly the problems I describe above. Thus if it works for ivtv it may very well also work for the pvrusb2 driver. (Please tell me if you try this and let me know if it worked.)
The tvdata structure is defined in tveeprom.h so the common solution is to find tveeprom.h. That header file is part of your kernel source tree. If it isn't there, then your kernel sources are too old to work with this driver. Update your kernel. Alternatively you can probably also work with a slightly older kernel that has been patched up with the latest video4linux snapshot. However I really recommend you go to a later kernel. A good choice known to work is 2.6.11.10.
Those two files are the firmware images that must be loaded into the pvrusb2 hardware before it will work properly. The firmware is not part of this snapshot, but you can extract it from your Windows drivers - which you should have gotten with the device. The extraction process is a little involved and unfortunately sensitive to the version of your Windows driver, but fortunately you only have to do this once. The best instructions for doing this can be found on Björn's web page. Note that you may need to rename the firmware file names. The two files should be:
File Size Description pvrusb2.f1 8192 bytes 8051 program image pvrusb2.f2 262144 bytes mpeg2 encoder image?
You might have compiled for the wrong kernel version. The kernel loader will usually report this in a very unsubtle way in the system log.
If the kernel is complaining that it can't find the module, you might want to try this first:
depmod -aI leave it as an exercise to the reader to look up the man page for depmod to see why this is important :-)
This is a known problem, and a likely bug in the driver.
If streaming is quickly turned off and back on again then the device can get confused. Once this happens the only recovery is to unplug the device and plug it back in. Any place where streaming can be rapidly stopped / started risks this problem. One good test case is to attempt to enable a filter in xawtv - every time it seems this kills the device. The driver and the device have nothing to do with any filter in xawtv, but xawtv tells the driver to stop streaming while it sets up the filter, and that stop / start sequence hits our problem.
This can sometimes also manifest itself as rampant ongoing audio and video corruption, though most of the time I've seen the video stream just cease to start back up.
From the driver's viewpoint, all the data requests have been queued up to the hardware but the hardware just doesn't produce any data. This is my primary problem to solve at the moment. Unfortunately this one may take a while, as I suspect the root cause may be in how the driver is programming the undocumented mpeg encoder chip in the hardware. Bear with me on this (and I'd love some help if anyone has any help to offer).