[alsa-devel] PCM delay compensation
mznyfn at 0pointer.de
Mon Feb 23 17:24:32 CET 2009
On Mon, 23.02.09 08:45, Takashi Iwai (tiwai at 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 at 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
> 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!
This is *not* a simple incompatibility with mplayer. The patch is
borked. This has nothing to do with changing semantics and creating
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the Alsa-devel