On 08/27/2014 09:15 AM, Daniel Mack wrote: > On 08/27/2014 09:07 AM, Jassi Brar wrote: >> On Wed, Aug 27, 2014 at 12:20 PM, Daniel Mack <daniel@xxxxxxxxxx> 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. > > prm->max_psize is still set to wMaxPacketSize of the endpoint. We just > decide how much of it to really use dynamically, each time before a > packet with real payload is commited. As I said earlier, I decided to do it like this so that we can eventually implement sample rate and format switches during runtime. We wouldn't want to touch the size of allocated buffers when this happens, so let's keep them at the largest packet size that might ever occur on the endpoint. The *actual* size of the each request's buffer is a different thing. Thanks, Daniel -- 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
