On Fri, May 21, 2010 at 08:33:50PM +0000, Mike Thomas wrote: > I am the unfortunate author/maintainer of the easycapdc60 driver, which targets > a single USB device: the EasyCAP DC60 dongle/stick having USB ID 05e1:0408. > This is widely marketed as an inexpensive ($10) means of digitizing videotapes > and similar sources. The front-end video chip is a SA7113H, the audio chip is > (normally - see below) a VT1612A (or equivalent) and the bridge is a STK1160. > The easycapdc60 driver is an integrated audio/video driver entirely independent > of the V4L2 videodev module, although it does use the V4L2 protocol for IOCTL. > The driver was made publically available in January 2010 as a GPL Sourceforge > project. > > The issue raised in the present thread arises from the fact that a given EasyCAP > responds consistently in one of two different ways when probed. One kind of > EasyCAP always gives the output already posted above: > > http://pastebin.com/WPGLZtDA > > I call these "slow" EasyCAPs. I do not own any of these, but have been obliged > to recognize their existence following numerous complaints by users on the > Sourceforge project's Open Discussion forum. The second kind of EasyCAP, of > which I possess three, gives different output: > > http://pastebin.com/k7MFfkA3 > > I call these "normal EasyCAPs". The difference between the slow and normal > EasyCAPs is in the isochronous audio interface. The slow EasyCAPs have audio > format PCM8, tSamFreq 8000 and wMaxPacketSize 9. The normal EasyCAPs have audio > format PCM, tSamFreq 48000 and wMaxPacketSize 256. > > When originally developing the driver over Christmas 2009/2010 I was unaware of > the slow EasyCAPs, and I hard-coded the URB parameters to give trouble-free > audio streaming on the normal EasyCAP which I was using for testing. The audio > part of the driver in its present form does not expect a wMaxPacketSize of > anything other than 256, and just concedes defeat gracefully when encountering a > different value. > > I should like to enhance the driver to cope with the slow EasyCAPs, and I > suppose it will be straightforward in principle to modify the URB parameters to > accommodate slower audio streaming. But the way in which the driver sets the > registers of the VT1612A will not be right if the slow EasyCAPs contain a > different audio chip, in which case the amount of work required will increase > very substantially and my resolve may falter. Thanks for the very detailed descriptions. How about just removing the device ids of these devices that don't work well? Also, if you want, you should get the driver into the main kernel tree. I'd be glad to add it to the drivers/staging/ portion of the kernel if you don't think it is ready to merge to the "real" part of the kernel for this type of driver. Just let me know. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
