Hi, Peter Chen <hzpeterchen@xxxxxxxxx> writes: > 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. I've applied with the extra parameters. You're right, if we just change USB_XFERS to 4 we're probably gonna have that parameter being changed every few months or so. -- balbi
Attachment:
signature.asc
Description: PGP signature
