From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre-Louis Bossart Subject: Re: Master Plan on rewinding Date: Mon, 15 Sep 2014 12:01:26 -0500 Message-ID: <54171B66.3010705@linux.intel.com> References: <540C76E0.9050808@gmail.com> <54148E72.2050903@gmail.com> <541584FB.2030208@gmail.com> <5416B852.6080406@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by alsa0.perex.cz (Postfix) with ESMTP id 76928265576 for ; Mon, 15 Sep 2014 19:02:05 +0200 (CEST) In-Reply-To: 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: Takashi Iwai , "Alexander E. Patrakov" Cc: Raymond Yau , ALSA Development Mailing List , Clemens Ladisch , David Henningsson , Takashi Sakamoto List-Id: alsa-devel@alsa-project.org >> What remains not fully understood for me is the claim that the >> information already exposed by every driver (in the form of the minimal >> period size) is not useful. I understand that two people are against >> this idea, so it must be bad. But I must understand why. Is it because >> the minimum period size reported by some drivers (which ones are >> suspected, if any?) may be a lie? > > A kind of yes. Many drivers, especially the old ones, set the minimal > period size without actually knowing the real limit. It tends to be > smaller than the hardware really supports. This is, in most cases, > just because no hardware spec defines that. So, it can't be blindly > taken as the bottom line, unfortunately. That's why I suggested the > new field would be optional; we simply don't know the value. Agree with Takashi, even recent audio IP tend to be reused in various ways (buses, system agents, arbiters, DMA controllers, DDR controllers) and no one really knows what the rewind granularity is, it's not a metric that's tracked. I actually liked the heuristic that's present in PulseAudio: constrain the safeguard to 256 bytes or 1ms (the last part would actually be fixed, it's currently not dependent on the sink actual rate and number of channels). we could introduce an optional query drivers for this but I wonder if it's worth the effort. -Pierre