On Thu, 21 May 2009, Mike Isely wrote: > > Martin: > > This coming weekend I will try to reproduce the problem here in a 2.6.29 > kernel. I'll let you know. > > -Mike >
I have some results. I am able to reproduce the problem. Just to recap, the symptom at issue here is that the audio fails after switching from radio to tv while streaming. I tested with kernel 2.6.29.3. With the stock pvrusb2 driver included with that kernel, the problem does not occur. With the current standalone driver compiled for that kernel, the problem DOES occur. Then I played a hunch. The standalone driver is effectively a "superset" driver. It includes lots and lots of goodies that can be selectively compiled - the idea is that various things are expected to be enabled / disabled depending on the surrounding kernel environment. This is all controlled by the file pvrusb2-options.h included with the standalone driver. Well, one of the more recent and pervasive things done with the driver was a complete reworking of how it communicates with the various chip-level drivers. The v4l-dvb repository has a new unified mechanism for performing this communication. It's a lot cleaner than was there before and in fact taking advantage of it allows the pvrusb2 driver to obsolete a whole bunch of code within the driver that was there basically to do for the driver what the v4l-dvb core now does. This new ability becomes possible with the v4l-dvb version included in the stock 2.6.29 kernel so the pvrusb2-options.h file compiles in the new mechanism while disabling the old one. The two switches within the standalone driver source are PVR2_ENABLE_V4L2SUBDEV and PVR2_ENABLE_OLD_I2COPS. For kernels older than 2.6.29 the following is in effect: #define PVR2_ENABLE_OLD_I2COPS #undef PVR2_ENABLE_V4L2SUBDEV But for 2.6.29 or greater instead the standalone driver does this: #undef PVR2_ENABLE_OLD_I2COPS #define PVR2_ENABLE_V4L2SUBDEV Now, with 2.6.30 (or maybe 2.6.31) the old mechanism will no longer work, but for 2.6.29 the old mechanism is still usable. So as an experiment, I modified pvrusb2-options.h so it treated the 2.6.29 kernel using the old communications mechanism and re-tested. And... now the audio problem does not happen! The pvrusb2 driver in the v4l-dvb repository has none of these nice switches. Rather the source code is transformed into a smaller version by filtering it with all the switches set a specific way (normally what is appropriate for whatever is current in v4l-dvb). This means that the pvrusb2 driver source in v4l-dvb no longer even has the old mechanism present. This fits with the symptoms you are describing - with the older v4l-dvb snapshot you tried the pvrusb2 driver still talked to the chip-level drivers the "old way" which we know still works. But with the current v4l-dvb repository the pvrusb2 driver only includes the code for the new sub-device mechanism. Thus the breakage. I was also able to get the audio to fail even if I closed /dev/video0 after switching back to tv mode. Most (but not all of the time) it failed this way. So what now? Well I could have introduced a bug in the pvrusb2 driver in how it talks to the sub-device drivers. Another possibility is that the v4l-dvb core has a bug in the new mechanism. I'm not sure which yet. I need to dig further. I never saw the tda9887 errors you are seeing. However (1) I never tested directly against a current v4l-dvb snapshot since I'm able to get it to fail just with the standalone driver and a stock 2.6.29 kernel. And (2) since I am seeing the audio issue anyway, it's a good guess that the tda9887 thing is unrelated. -Mike -- 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
