From mboxrd@z Thu Jan 1 00:00:00 1970 From: Clemens Ladisch Subject: Re: USB Audio questions Date: Tue, 16 Aug 2011 17:46:23 +0200 Message-ID: <4E4A90CF.9040004@ladisch.de> References: <1313432124-22591-1-git-send-email-lars@metafoo.de> <1313432124-22591-2-git-send-email-lars@metafoo.de> <4E4A100D.9020302@ladisch.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by alsa0.perex.cz (Postfix) with ESMTP id 2ECF6244A8 for ; Tue, 16 Aug 2011 17:46:28 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Daniel Mack Cc: Sarah Sharp , ALSA Development Mailing List , Pierre-Louis Bossart List-Id: alsa-devel@alsa-project.org Daniel Mack wrote: > On Tue, Aug 16, 2011 at 8:37 AM, Clemens Ladisch wrote: >> Pierre-Louis Bossart wrote: >>> - Is there any good reason why the max number of packets per urb defaults to >>> 8? >> >> Not really. It is an attempt to compromise between interrupt frequency >> and the latency resulting from packet queueing. > > Ah, I thought there is a limit of frames per urb that is the same than > subframes per packet on USB. That's not the case then? URBs are a Linux-defined data structure; they can be arbitrarily long (as long as you don't reach the undocumented limit of how far in the future the HCD can schedule packets). > Wouldn't it be possible to not count what we submitted but look at the > playback packets that return from the HCD and move the hwptr there? > That information is presumably closer to the actual hardware position > than the time when we queue. In this case, the "hardware position" is the read pointer in ALSA's ring buffer, which must be incremented whenever data is moved from there into the URBs' buffers. Regards, Clemens