On Tue, Jan 17, 2017 at 05:57:50PM +0800, Peter Chen wrote: > On Tue, Jan 17, 2017 at 11:23:55AM +0200, Felipe Balbi wrote: > > > > 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 > > Set req_number as 4 can let aplay work well using mainline kernel. > For the customer project, the number is 20 since they don't care > the memory. The system latency and memory requirement are different > per projects, why not let user choose it? > Any more comments, Felipe? If you don't like extra parameter, I can have a patch to change USB_XFERS as 4. -- Best Regards, Peter Chen -- 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
