Re: What does snd_pcm_delay() actually return?

[Lennart Poettering <mznyfn@0pointer.de>]

On Fri, 13.06.08 08:13, Takashi Iwai (tiwai@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 
   return 0.

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
   for that.

(Since this matches Lennart's original interpretation of the situation
he's now happy... ;-))

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net         ICQ# 11060553
http://0pointer.net/lennart/           GnuPG 0x1A015CC4