From mboxrd@z Thu Jan 1 00:00:00 1970 From: Liam Girdwood Subject: Re: [PATCH] ALSA: core: Allow drivers to set R/W wait time. Date: Thu, 15 Mar 2018 16:07:39 +0000 Message-ID: <1521130059.7762.298.camel@linux.intel.com> References: <20180314204440.14027-1-liam.r.girdwood@linux.intel.com> <1521120937.7762.258.camel@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by alsa0.perex.cz (Postfix) with ESMTP id D03B2267252 for ; Thu, 15 Mar 2018 17:07:44 +0100 (CET) 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 Cc: alsa-devel@alsa-project.org, Mark Brown List-Id: alsa-devel@alsa-project.org On Thu, 2018-03-15 at 15:30 +0100, Takashi Iwai wrote: > > It's not atm, as it was being set by the driver. Would probably mean an ABI > > change to PCM ops or a new ioctl ? The latter wont break the ABI and the > > default > > value would remain if the ioctl was not called. > > Basically this timeout is merely for a safety, wasn't considered as a > part of the real functionality. > > So, with your plan, this is exposed as a real PCM feature, as a part > of API? For what kind of scenario / purpose? Use case is XRUN handling, DMA failure or FW crash detection. The shortened timeout means we can recover far faster leaving a smaller gap in any audio. Liam