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