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
