From mboxrd@z Thu Jan 1 00:00:00 1970 From: Clemens Ladisch Subject: Re: snd_pcm_delay, hw buffers and driver api (v2) Date: Fri, 14 Aug 2009 14:13:00 +0200 Message-ID: <4A8554CC.2060009@ladisch.de> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by alsa0.perex.cz (Postfix) with ESMTP id 28A7E24721 for ; Fri, 14 Aug 2009 14:13:08 +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: Kai Vehmanen Cc: alsa-devel@alsa-project.org, Ujfalusi Peter , ext-eero.nurkkala@nokia.com List-Id: alsa-devel@alsa-project.org Kai Vehmanen wrote: > ... > In both cases, this value (hw_ptr) shows the status of sending data to an > separate entity, and one that has its own buffer (multiple ms) before the > actual DAC/ADC. > > So when application developer uses snd_pcm_delay(), the result is not > quite what the ALSA API says: ... snd_pcm_avail() returns the free part of the buffer. snd_pcm_delay() returns the filled part of the buffer plus the additional delay imposed by the device. The additional delay can be set by the driver in pcm_substream->runtime->delay. (Currently, only the USB audio driver bothers to set this.) HTH Clemens