[pvrusb2] driver status / update

[Xavier Gnata]

Hi  Mike,

Well I have had my WinTV-PVR-USB2 since the very first versions of your
driver and it  just works well.
Thanks a lot. Nothing to add :)

The only small problem is that I'm still missing a good *small* tv app
like xawtv4 (but xawtv4 is alomost dead).
However, I have a small python/qt script to write in /sys and mplayer to
play the mpeg flux. It does the job :)

An old happy user,
Xavier

> Well I've spent a chunk of time on the driver today, and I'm not nearly 
> as far along as I'd wanted.  But I'd thought I'd offer a summary here 
> since I know several people are waiting around to hear about it.
>
> It's been quite a while since I had released a snapshot, and as such, 
> there's been some divergence between the standalone driver and the 
> v4l-dvb (and kernel) versions.  I had to pull that back together, and I 
> hit a few issues along the way.  Nothing really earth-shattering, but it 
> took time to sort out.  Note: the current latest standalone snapshot 
> probably won't compile in 2.6.28 - until this afternoon I hadn't even 
> tried 2.6.28 yet.  I already have fixes for this, but read on...
>
> I looked at the bus_info question, and I've been convinced.  I've made a 
> change now that puts the driver serial number into the bus_info V4L 
> capability field.  Actually, what I did was to push the logic that 
> generated the sysfs-interface string for this into the driver core, then 
> exported that back out to the interfaces.  So now the sysfs interface 
> (as the "abcdef" in "/sys/class/pvrusb2/abcdef") and the V4L interface 
> (via the bus_info capability field) exactly match each other.
>
> I haven't dug out the cx25840 problem yet.  I think this is a line of 
> investigation that once chased, is going to reveal other issues.  I am 
> working on this however.
>
> The raw video support looks very interesting.  To do this right, I have 
> to advertise a different "format" in V4L.  Not a surprise; I knew this 
> all along and I've had hooks in the driver since the beginning to make 
> this feasible.  I should also now do the work to support the other I/O 
> methods in V4L (mmap and async).  Those methods weren't really useful 
> for mpeg, but for raw uncompressed output they make more sense.  Again, 
> the foundation is already there to support the other methods; I just 
> need to finish it.  Also, I *might* have to support isochronous USB 
> transfers for this.  Well I'm not sure, but for data like this 
> uncompressed video where the timing is not actually in the stream itself 
> (I assume) you need a transfer method that is less sensitive to jitter / 
> latency.  USB bulk transfers don't really satify either constraint.  
> Also, I have reason to suspect that the video format being sent by the 
> device probably does not match what V4L expects.  So the driver is going 
> to have to swizzle the pixel data.  No more direct pass-through to the 
> app...
>
> Another even more interesting issue is the audio side of this.  In raw 
> mode, there's no means to encapsulate the audio inside the same stream 
> as the video - after all V4L was originally a video spec not an audio 
> one.  We've been able to ignore this with mpeg since the mpeg format 
> allows for embedded audio and the hardware encoder does all the heavy 
> lifting here.  But not with raw mode.  In this case another means must 
> be found, and I am thinking that what needs to happen is that the 
> pvrusb2 driver will have to export an ALSA interface now.  So now the 
> driver will actually have to parse the stream and send the video to the 
> video app, and (hopefully) PCM audio to the ALSA interface.  This change 
> will in fact make the device walk and talk pretty much exactly like an 
> old-school V4L device with "external" audio - tvtime should then work.  
> Let's hope.  (Might have an issue here maintaining audio/video sync, due 
> to split buffers in the two paths, but I'm not going to sweat that yet.)
>
> One other interesting thing about raw support: radio mode.  Right now 
> when in radio mode, you get the audio stream as MP3 data inside a normal 
> mpeg container, complete with its own useless blank video channel as 
> well.  And by "blank" I mean blank as in wasting-bandwidth-blank.  If 
> the pvrusb2 driver can act like an ALSA device and if we can get the 
> audio in raw mode as PCM data, then, well now we can run the radio such 
> that it looks like a normal V4L radio device...
>
> Now, with all that said, it should be obvious that full raw mode support 
> isn't going to happen immediately.  This is still going to take a little 
> while.  But I'm not stuck on this, and I'll let you all know how it's 
> going.  I do plan an incremental approach, i.e. the audio fun will 
> probably show up after the video is working.
>
> For the immediate future however I need to figure out what is going on 
> with the cx25840 module.  Only after dealing with that will I seriously 
> look at raw mode.
>
> I can release another snapshot now with the bus_info change.  But it's 
> not that big of a change, and with the cx25840 breakage, the value of 
> that snapshot will be somewhat less than it should be.  (Running such a 
> standalone driver against any kernel at least up to 2.6.27 should still 
> be OK, but after that the cx25840 issue is probably going to nail 
> everyone except those whose [older] devices use the saa7115 instead - 
> then again maybe it's broken too - I need to test further.)
>
>   -Mike
>
>
>