[alsa-devel] What does snd_pcm_delay() actually return?
mznyfn at 0pointer.de
Fri Jun 13 15:51:29 CEST 2008
On Fri, 13.06.08 08:13, Takashi Iwai (tiwai at suse.de) wrote:
> > uh? I think we have a misunderstanding here. What you are explaining
> > here would suggest that the first answer is the right one, but you
> > actually claim it is the second one? This doesn't make sense to me.
> > As far as I understood the "hw_ptr" is the index where the PCM data is
> > *read* from the playback buffer, While "appl_ptr" is where the data is
> > *written* to the playback buffer. Right?
> No, the hwptr is the point whether the data is being played... well,
> ideally. The hwptr can behind the actual point. But, it shouldn't be
> ahead the actual point.
Ah, that's good to know. Thanks for the clarification!
> > However, since the data is not dma'd
> > sample-by-sample but in a block at a time, the sample that is
> > currently hearable is still quite a bit before this index. Right? And
> > hence would snd_pcm_delay() when always defined as "appl_ptr - hw_ptr"
> > not really be suitable for synchronization because the hw_ptr is
> > always a bit ahead of what is actually being played -- and WINE's
> > interpretation would be right and the media player's (and mine)
> > wrong. In contrast to what James and you just said.
> It's a problem of usb-driver.
OK, so to summarize the situation:
a) snd_pcm_delay() should actually return write-to-hear latency. And
is supposed to be called *before* the next write and it will tell
you when that next write will reach the speakers, in the sound card
device time domain. For networked outputs it will most likely never
b) for the usb driver this is however broken and it returns the fill
level of the playback buffer
c) snd_pcm_hw_params_get_buffer_size() - snd_pcm_update_avail()
returns the fill level, but only works on mmap.
d) The snd_pcm_hw_params_get_fifo_size() was supposed to return the
'difference' between a) and c), but was never actually used
(Since this matches Lennart's original interpretation of the situation
he's now happy... ;-))
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net ICQ# 11060553
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
More information about the Alsa-devel