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.
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.
-gabriel
--
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
