On 25.11.2012 23:23, Daniel Griscom wrote:
At 1:43 PM +0100 11/25/12, Daniel Mack wrote:
Please do another test and change prepare_outbound_urb() so that instead of calling ep->prepare_data_urb() to fill the URB, fill it directly with some sort of easily recognizable test pattern (you can take the code from "silence" case to access the buffers). Some kind of 16-bit counter should do. And then check the payload with the Beagle and see whether the pattern has gaps.
This test will tell us whether data is in fact lost before it hits the usb audio driver, or if it's dropped by the USB HCD.
I did the test, and expected to either a) see the incrementing data be contiguous even though the USB packet transmission was stuttering, or b) see the incrementing data have gaps where the "missing" packets were. However, what I saw was c): the USB packets never misbehaved.
Here's the code I used in /usb/endpoint.c, prepare_outbound_urb():
static short left = 0; static short right = 0x0404; short *sp;
...
if (ep->prepare_data_urb) {#if 1 ep->prepare_data_urb(ep->data_subs, urb); #else /* Fake constantly increasing samples */ unsigned int offs = 0; for (i = 0; i < ctx->packets; ++i) { int counts;
if (ctx->packet_size[i]) counts = ctx->packet_size[i]; else counts = snd_usb_endpoint_next_packet_size(ep); urb->iso_frame_desc[i].offset = offs * ep->stride; urb->iso_frame_desc[i].length = counts * ep->stride; offs += counts; } urb->number_of_packets = ctx->packets;
Note that this is a potential difference between your two cases.
prepare_playback_urb() from pcm.c will not always set urb->number_of_packets to the maximum value but cut packets short at PCM period boundaries.
Could you move your pattern generating code down to that function? Just look for the memcpy() calls there.
Daniel