On Mon, Dec 12, 2011 at 7:46 AM, Yan Seiner <yan@xxxxxxxxxx> wrote: > Andy Walls wrote: >> >> 800 MB for 320x420 frames? It sounds like your app has gooned its >> requested buffer size. >> > > > That's an understatement. :-) > > >> <wild speculation> >> This might be due to endianess differences between MIPS abd x86 and your >> app only being written and tested on x86. >> </wild speculation> >> > > > My speculation too. I don't know where that number comes from; the same app > works fine with the saa7115 driver if I switch frame grabbers. I'll have to > do some fiddling with the code to figure out where the problem lies. It's > some interaction between the app and the cx231xx driver. > > > > >> You still appear to USB stack problems, but not as severe (can't change >> device config to some bogus config). >> > > > The requested buffer size is the result of multiplying max_pkt_size * > max_packets and the rejected config shows a max_packet_size of 0, maybe > ithere;'s a problem with either endianness or int size... ??? Something to > follow up on. For what it's worth, I did do quite a bit of work on cx231xx, including work for mips and arm platforms. That said, all the work done was on the control interfaces rather than the buffer management (my particular use case didn't have the video coming back over the USB bus). How does your app setup the buffers? Is it doing MMAP? Userptr? It's possible userptr support is broken, as that's something that is much less common. And as Andy suggested, if you can test your app under x86, knowing whether the app works with cx231xx under x86 is useful in knowing if you have a mips issue or something that your app in particular is doing. Also, just to be clear, the USB Live 2 doesn't have any onboard hardware compression. It has comparable requirements related to USB bus utilization as any other USB framegrabber. The only possible advantage you might get is that it does have an onboard scaler, so if you're willing to compromise on quality you can change the capture resolution to a lower value such as 320x240. Also, bear in mind that the cx231xx driver may not be properly tuned to reduce the alternate it uses dependent on resolution. To my knowledge that functionality has not been thoroughly tested (as it's an unpopular use case). And finally, there were fixes for the USB Live 2 specifically which you may not have in 3.0.3. You should check the changelogs. It's possible that the failure to set the USB alternate is leaving the driver is an unknown state, which causes it to crash once actually trying to allocate the buffers. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
