[pvrusb2] Pops/Breaks on radio0 device

[Mike Isely]

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