Hi, Peter Chen <hzpeterchen@xxxxxxxxx> writes: > On Mon, Jan 16, 2017 at 12:40:06PM +0200, Felipe Balbi wrote: >> >> Hi, >> >> Peter Chen <peter.chen@xxxxxxx> writes: >> > There are only two requests for uac2, it may not be enough at high >> > loading system which usb interrupt handler can't be serviced on >> > time, then the data will be lost since it is isoc transfer for audio. >> > >> > In this patch, we introduce a parameter for the number for usb request, >> > and the user can override it if current number for request is not enough >> > for his/her use case. >> > >> > Besides, update this parameter for legacy audio gadget and documentation. >> >> I would rather just drop pre-allocation of requests. Every time Audio >> wants transmit data you allocate and queue a request there and free() >> the request on completion. >> >> All of these functions already have a ton of parameters :-s >> > > At high loading system, how can we make sure the interrupt can be > serviced in one isoc time slice? We ran out this problem at one > customer project, and even at default mainline, the aplay will > meet underrun using UAC2. well, if you don't have any limits to how deep your queue can be, that should cover it, no? Another way to look at this is that 2 requests really _is_ too little, and that can be calculated. How much data do you want to send per interval and what is the interval? Currently, uac2 is using 1024-byte requests with bInterval of 4, which means an interval of 1ms (2^(4-1) * 125 us = 1000 us). I can see how we would miss an interval if our CPU is hogged by another task and our interrupt handler can't run for over 1ms. Maybe, as a fix, we should just increase USB_XFERS to a value that would work. Doubling it will make us allocate exactly one PAGE (4096) for rbuf. What are you passing as req_number on this customer project? -- balbi
Attachment:
signature.asc
Description: PGP signature
