From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lennart Poettering Subject: Re: Misusing snd_pcm_avail_update() Date: Thu, 22 Jan 2009 23:20:15 +0100 Message-ID: <20090122222015.GB9379@tango.0pointer.de> References: <20090120025727.GA30499@tango.0pointer.de> <49758B71.8090605@ladisch.de> <20090120142614.GA27494@tango.0pointer.de> <49761C79.8060605@ladisch.de> <20090120202933.GA17626@tango.0pointer.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from tango.0pointer.de (tango.0pointer.de [85.214.72.216]) by alsa0.perex.cz (Postfix) with ESMTP id 395D21037E3 for ; Thu, 22 Jan 2009 23:20:16 +0100 (CET) Content-Disposition: inline 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: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org On Wed, 21.01.09 01:39, Takashi Iwai (tiwai@suse.de) wrote: > > The function should look like this: > > > > snd_pcm_sframes_t snd_pcm_busy_for(snd_pcm_t *pcm); > > > > I called the prototype "busy for" since effectively the value I am > > looking for is the time the card will be busy with the data it already > > has, and doesn't need any new data. > > Isn't it snd_pcm_delay() that was originally designed for? No. Let me summarize the meaning of snd_pcm_update_avail(), snd_pcm_delay() and my snd_pcm_busy_for() to opefully make clear where the differences are: snd_pcm_update_avail() -- returns how many samples can be written right now without blocking. snd_pcm_delay() -- returns how many samples will be played before the samples that are written now can be heard. snd_pcm_busy_for() -- returns how many samples will be played before ALSA would enter an underrun situation if no further samples are written. snd_pcm_update_avail() and snd_pcm_busy_for() return metrics that are solely dependant on the size and metrics of the hardware buffer and its current indexes. snd_pcm_delay() also includes information about any extra latency that comes after the playback buffer. Onle snd_pcm_update_avail()/snd_pcm_busy_for() are influenced by "fast starts" as done by the USB driver's double buffering and by block-based transfer. Hmm, I am trying my best to explain why I want this function and what exactly it should do. Any chance I can convince you guys that this function really matters for timer-based audio scheduling? > Did you check my previous patch? You mean the one that makes snd_pcm_delay() for USB devices actually include the extra latency that comes after the playback buffer? No, I didn't check that one yet. It takes so much time to patch the kernel and test things... I'll try too finally do it this WE. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4