[pvrusb2] driver status / update

[Mike Isely]

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


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8