At Thu, 12 Jun 2008 22:52:25 +0200, Lennart Poettering wrote: > > On Wed, 11.06.08 18:56, Takashi Iwai (tiwai@xxxxxxx) wrote: > > > > could you please explain what exactly snd_pcm_delay() returns? > > > > > > Some applications (such as WINE) assume it is the time that would pass > > > until we reach an underrun if we would stop writing any further data > > > to the PCM device. > > > > > > Other applications (such as most media players) use it for time > > > synchronisation. i.e. assume that it is the time that passes until a > > > sample I write to a PCM device now would take to be played. > > > > As James already pointed, the correct answer is the latter. > > In the driver implementation level, snd_pcm_delay() simply returns the > > difference between appl_ptr and hw_ptr. It means how many samples are > > ahead on the buffer from the point currently being played. > > > > However, if you stop feeding samples now, snd_pcm_delay() returns the > > least time XRUN occurs. So the first understanding isn't 100% wrong. > > 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. > In the USB audio case, the playback buffer is in normal memory, right? > Every now and then a bit of it is dma'd to the usb controller and sent > over the USB wire, then on the receiving side it is buffered again and > then passed to the DAC. Correct? The hw_ptr in this case is the > pointer into the system memory buffer where the data will be read from > next and sent to the usb wire. It shouldn't be so in a restricted manner. > 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. > Or again, in other words: is the delay that is caused by the fact that > after the data is read from the DMA buffer it still has quite a > bit time to travel to the speakers included in snd_pcm_delay(), or is > it not? No. It's appl_ptr - hw_ptr per definition. In the ALSA framework, it's so simplified. And yes, this is suboptimal in some implementation cases. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
