Re: [PATCH 2/2] usb: gadget: uac2: add req_number as parameter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

-- 

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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux