On 08/27/2014 09:28 AM, Jassi Brar wrote: > On Wed, Aug 27, 2014 at 12:45 PM, Daniel Mack <dan...@zonque.org> wrote: >> On 08/27/2014 09:07 AM, Jassi Brar wrote: >>> On Wed, Aug 27, 2014 at 12:20 PM, Daniel Mack <dan...@zonque.org> wrote: >> >>>> Hmm? The first USB_XFERS packets will only contain zeros, and we're only >>>> preparing those here. For every successive packet, the length is >>>> recalculated and the audio material is copied in accordingly before the >>>> requets is requeued. What buffers should overlap here? >>>> >>> For 44100/2/S16, req_len is 176 or 44 frames. But we need to send 45 >>> frames in a packet occasionally. >>> >>> req[0]->buf = rbuf + 0 and req[1]->buf = rbuf + 176. >> >> No. req[0]->buf = rbuf + 0 and req[1]->buf = rbuf + max_psize.
Note that you are referring to the buffer pointer here. > You patch does > - req->length = prm->max_psize; > + req->length = req_len; Yes, because we tell the udc driver we want to commit req_len bytes in this request. req->buf, however, it set to a buffer that can accommodate wMaxPacketSize, so when the packet completes, we can stuff more bytes into it and modify req->length again. req->length it the request length, not the max size of the buffer we point to. > Clearly for 44.1/2/S16, req_len evaluates to 176. Yes, that's the start condition. Once both the USB and the ALSA side are running, the req->length calculation in iso_complete() kicks in and tweaks the buffer sizes. Does it make sense now? Or am I missing anything? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
