Roger: If it's working fine when you send the driver output to a file, then there's really nothing wrong with the driver.
Odds are instead you might be instead dealing with a station that's weak enough that the pvrusb2 device might not be able to maintain a lock on the signal, resulting in real time breaks in the bit stream output, which might be upsetting the playback app due to the (probably tiny) pauses. There's NOTHING WRONG with the driver or the hardware in this case. You need to be having this conversation with the application developer, not here. I've seen a similar thing happen in mplayer with video/audio sync. See this link and read the last paragraph in the "mplayer" section: http://www.isely.net/pvrusb2/usage.html#mplayer The acid test is that if recording the data to a file "clears" the problem, then the driver is fine. -Mike On Thu, 2 Feb 2012, Roger wrote: > > I hooked-up my old pvrusb2 device today, a WinTV PVR USB2 Model 29xxx since > the > HVR-1950 cx25842 chip doesn't currently work, to be able to use the FM > /dev/radio0 device and am noticing pops/breaks during audio playback. > > > # mpeg2desc -a0 < /dev/radio0 | mpg123 -T - > > Or > > # mpeg2desc -a0 < /dev/radio0 | mpg321 --aggressive - > > Or > > $ mpeg2desc -a0 < /dev/radio0 | madplay - > > And, using mplayer /dev/radio0 seems even more problematic. Increasing the > cache does seem to resolve, but requires an excessive value for the -cache > option (1-2 minutes). > > > Recording to file for playing-back separately does resolve the pop/break > problem, but isn't a convienient method of playing back a live stream. > > $ mpeg2desc -a0 < /dev/radio0 > /tmp/file.mp2 > > > Seems to be a caching problem. I don't recall noticing this "audio break" > problem within the past year or so. > > > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
