From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Master Plan on rewinding Date: Tue, 09 Sep 2014 18:09:32 +0200 Message-ID: References: <540C76E0.9050808@gmail.com> <540CC53B.7080204@ladisch.de> <540D5B46.3020904@gmail.com> <540EBD9A.9000009@ladisch.de> <540EC08E.4000906@gmail.com> <540F047F.7090607@ladisch.de> <540F22D9.8010203@gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 8EE0B2651FE for ; Tue, 9 Sep 2014 18:09:36 +0200 (CEST) In-Reply-To: <540F22D9.8010203@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: "Alexander E. Patrakov" Cc: ALSA Development Mailing List , Clemens Ladisch , David Henningsson , Takashi Sakamoto List-Id: alsa-devel@alsa-project.org At Tue, 09 Sep 2014 21:55:05 +0600, Alexander E. Patrakov wrote: > > 09.09.2014 19:45, Clemens Ladisch wrote: > > Alexander E. Patrakov wrote: > >> can the proposed heuristic (minimum period size for a given sample > >> rate, number of channels and sample format) be useful as an upper- > >> bound approximation of the pointer update granularity for cards that > >> are "rewindable even further than the nearest period"? > > > > No; USB precsion depends on the URB size, which is roughly proportional > > to (but smaller than) the period size. > > Thanks for the explanation. It was very useful. > > At this point, I am tempted to not express this "less than the period > size but depends on it" rule, and classify USB audio devices as > "Rewindable down to the period size", even though it is a pessimization. > > Also (sorry for the off-topic) this explanation completely crystallizes > my opinion about possible misuse of the SNDRV_PCM_INFO_BATCH flag in the > snd-usb-audio driver or PulseAudio. My opinion now is: there is no > misuse on either side. Well, it's not entirely a "misuse" in either side. The flag is merely a hint, and the current attitude of PA is in a safer side of the behavior this flag may indicate. Whether it's the best choice is another question, of course. After all, we certainly need some API to expose the granularity. This has been asked since long time ago, but it wasn't done simply because the demands (and specifications) haven't been clarified. Also, for rewinding, we may need to consider about the FIFO or other things on top of signal processing path. If the granularity defines the granularity of the hwptr *update*, it wouldn't be enough for defining a safe guard range. Currently, most of hardware have a small amount of FIFO that can be mostly ignored, fortunately, though. Takashi