Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Lennart Poettering <mznyfn@0pointer.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: PCM delay compensation
Date: Mon, 23 Feb 2009 17:28:04 +0100	[thread overview]
Message-ID: <s5hskm586ej.wl%tiwai@suse.de> (raw)
In-Reply-To: <20090223162431.GB22083@tango.0pointer.de>

At Mon, 23 Feb 2009 17:24:32 +0100,
Lennart Poettering wrote:
> 
> On Mon, 23.02.09 08:45, Takashi Iwai (tiwai@suse.de) wrote:
> 
> > 
> > At Sun, 22 Feb 2009 00:45:04 +0100,
> > Lennart Poettering wrote:
> > > 
> > > On Tue, 07.10.08 17:32, Takashi Iwai (tiwai@suse.de) wrote:
> > > 
> > > > Hi,
> > > 
> > > Sorry for the overly long delay.
> > > > 
> > > > the patch below (to the latest sound git tree) adds the extra delay
> > > > count for USB-audio driver.  This change will appear as the return
> > > > value of snd_pcm_delay().
> > > > 
> > > > Could you check whether it's appropriate behavior you've wanted?
> > > 
> > > I have now tested this patch on the current 2.6.29-rc5 kernel. The
> > > effect is that snd_pcm_delay() returns always increasing values, as if
> > > the playback never proceeds. Most movie players which need that call
> > > to synchronize video frames hence stall completely.
> > 
> > OK, that's bad.  However, the increased value of snd_pcm_delay() is
> > exactly the effect.  The usb-audio always prefetch the buffer in
> > advance.
> > 
> > That means, changing (or "fixing") snd_pcm_delay() would cause many
> > regressions with many apps -- thus basically we are not allowed to
> > change the semantics any more at this too late point.
> > 
> > I feel it's better to introduce another kernel-side API to give a
> > better sync/timing information, and mark snd_pcm_delay as obsolete for
> > future (although we can never deprecate such a basic API).
> 
> No, snd_pcm_delay() with this patch is clearly broken: it apparently
> increases at the same speed as the hw ptr, ignoring the app
> ptr. i.e. after 5 min of playback the delay will be reported a 5 mins!
> After 10 min of playback the delay will be reported as 10 mins!

Ah, then it must be a buggy patch indeed.  It didn't appear in my
some test cases at that time, so didn't check after that.

Maybe some delay account in complete callback wasn't correct.
Another item to my TODO list. 


thanks,

Takashi

  reply	other threads:[~2009-02-23 16:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 15:32 PCM delay compensation Takashi Iwai
2008-10-29  9:33 ` Takashi Iwai
2009-02-21 23:45 ` Lennart Poettering
2009-02-23  7:45   ` Takashi Iwai
2009-02-23 16:24     ` Lennart Poettering
2009-02-23 16:28       ` Takashi Iwai [this message]
2009-02-23 16:33         ` Takashi Iwai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s5hskm586ej.wl%tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=alsa-devel@alsa-project.org \
    --cc=mznyfn@0pointer.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox