From mboxrd@z Thu Jan 1 00:00:00 1970 From: Colin Guthrie Subject: Re: alsa pulse bugs Date: Mon, 05 May 2008 10:44:29 +0100 Message-ID: References: <20080505103410.zv8dezd9z44cksoc@dbservice.com> <20080505111126.lhtr3bwyo0sg4wc4@dbservice.com> Reply-To: General PulseAudio Discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pulseaudio-discuss-bounces@mail.0pointer.de Errors-To: pulseaudio-discuss-bounces@mail.0pointer.de To: pulseaudio-discuss@mail.0pointer.de Cc: alsa-devel@alsa-project.org List-Id: alsa-devel@alsa-project.org Colin Guthrie wrote: > tom@dbservice.com wrote: >>> Re the snd_pcm_delay() including network latency (#3945), this clearly >>> makes sense for network streams. Does you proposed fix include this >>> delay (albeit with the improvement that it also will drop to 0 if there >>> are no samples queued)? >> snd_pcm_delay() should not include any network latency. The API is >> defined as 'read pointer - write pointer', and applications expect >> that. Or at least they expect that when all samples are played that >> the delay drops to zero. > > With the caveat of very limited technical knowledge, I can agree on the > latter point (drop to 0 when all samples are played), but if it was > implemented sans net-delay in pulse would this not cause e.g. a-v sync > issues when playing via alsa to a networked PA server? If so then this > fix would introduce another bug. 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? Is there perhaps a more appropriate API call they can use to do whatever test they are doing? Col