On Mon, May 05, 2008 at 12:22:10PM +0200, tom at dbservice.com wrote: > Quoting Colin Guthrie <gmane at colin.guthr.ie>: > > Actually just having a very quick glance at the Alsa API docs, it > > doesn't mention that this value should be 0 if there are no samples to play: > > > > http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m.html#ga0d9e14a4be65209eb549e48a9f07302 > > > > Closest it says is: "It's positive and less than buffer size in normal > > situation". > > > > So perhaps this is an invalid assumption at the wine side? > > However this part: > > Delay is distance between current application frame position and sound > frame position. I'm not an alsa expert. But what application normally want to know from this call is: If i write some bits of audio *now* how long will it take before it's played. Which is used for audio/video synchronisation. If you change the pulse plugin to not report network latency, then audio/video synchronisation will break. > suggests that it indeed can be zero. Or why would a soundcard have a > gap between the read and write positions if it has played everything? That it *can* be zero, doesn't mean it *has* to become zero though. The root of this issue is that you (and the alsa API mostly is too) are assuming to be talking to a soundcard, but pulseaudio isn't a soundcard. So there are some subtle differences... > If Wine uses a wrong assumption, then please clarify the function description. > > > Is there perhaps a more appropriate API call they can use to do whatever > > test they are doing? > > What Wine needs to know, is whether a particular sample has already > been played or not. It does 'bytes_written - delay_in_bytes' to find > out how much of the written data the soundcard has already played. If > there is a better test for it, please explain. Don't know, sorry Sjoerd -- Ah, but a man's grasp should exceed his reach, Or what's a heaven for ? -- Robert Browning, "Andrea del Sarto"
