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 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
