On Wed, Dec 14, 2011 at 01:44:38PM -0600, Gabriel M. Beddingfield wrote: > On 12/14/2011 12:26 PM, Greg KH wrote: > >On Wed, Dec 14, 2011 at 08:04:11AM -0600, Gabriel M. Beddingfield wrote: > >> > >>On OMAP4, sending USB audio over the High Speed port typically > >>results in data loss (audio noise). If I modify sound/usb/urb.c to > >>tweak things like the "total_packs" calculation, I can sometimes get > >>it to work well for a specific case. How do I "right-size" the > >>packets? Or should I be doing something else? > > > >iso packets are supposed to be able to be "lost", that's the whole way > >the protocol transfer works. It is never a "this must get through" type > >of thing here, so this is normal. > > Except that the data usually *does* get through... and the Audio USB > code doesn't take any special action in the event that there are > drops... and userspace gets no indication that there was an > under-run. How would it know there was an underrun, how are you supposed to notify userspace of this? > >>In this case, sound/usb/urb.c typically calculates that it wants to > >>send 24 URB's in each transer. If I manually alter it to use 12 > >>instead, then the audio plays as expected.[2] However, the same > >>tweak does not work for 48000 Hz. > > > >That's probably because you are trying to send more data than can be > >scheduled here, right? And again, that's to be expected and should be > >just fine, you might want to look at why things are "popping" and fix > >that in the audio player, as it should be able to handle this smoother I > >would think. > > The audio player on the host? The kernel makes no effort to notify it. > The audio player on the device? It's given audio gaps. It can > either concatenate or write zeros. Either way, that's a pop. > > My theory is that I'm running in to throughput issues on my local > bus. (The OMAP4 L3 interconnect.) I'm guessing that I *do* have > enough bandwidth if my overall bundle of URB's is the right size. > > I don't know enough about the USB/URB protocol to fiddle with this > code reliably... and since it's common code, I'm double-wary. I would be too, I'd look at your local bus issues, I'd blame that for now :) 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
