Also, on mplayer check priority of the mplayer playback process. I was using a netbook with a USB distro of Knoppix linux this weekend and had to renice gnome-mplayer which forks mplayer to raise the playback task's priority. When using media from a wireless server, had to use a larger cache to get the dropouts/pops to stop. YMMV.
On Thu, Feb 2, 2012 at 10:32 PM, Mike Isely <[email protected]> wrote: > > 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 > _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
