[pulseaudio-discuss] useless timer ?

[Lennart Poettering]

On Thu, 10.06.10 17:42, pl bossart (bossart.nospam at gmail.com) wrote:

> In my never ending crusade against wakeups, I found out that when a
> stream is opened with the PA_STREAM_AUTO_TIMING_UPDATE flag, a timer
> is configured in steady state to fire every 1.5 seconds, then the
> timing information is updated.
> stream.c: #define AUTO_TIMING_INTERVAL_END_USEC (1500*PA_USEC_PER_MSEC)
> 
> However the documentation says that the timing information is updated
> when a write is performed. With the current settings, PulseAudio
> buffers up to 2 seconds, and half of this will be in the ALSA ring
> buffer. Conclusion: the client will write new data more often than
> this 1.5 s timer, and update the timing information. Plus when time
> interpolation is used, there's really no reason to update the
> information every 1.5s, every 10s would do.

Hmm, the client only asks for a timing updating if the seeking triggered
by a write corrupted the timing info and we hence need new data. A
normal write (i.e. with offset=0 and seek=PA_SEEK_RELATIVE) should no
trigger a timing update.

> So am I missing something or is this a useless wakeup? And even if it
> served a purpose, why was 1.5s selected?

Well, the logic is actually exponential: we start with 10ms and then
double that an top out at 1.5s. We had to pick some way to end this. But
you are right, this would probably make sense to pick a bit larger given
that the server-side wakeup is tuned to 2s.

Lennart

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