> 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. The Gstreamer folks use PA_SEEK_ABSOLUTE with a non-zero offset; when you use pulsesink you get this wakeup no matter what value is used for tlength. >> 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. It's probably ok to leave the code as is and fix the constants to be aligned with larger buffer sizes. What's not clear to me is how to go about this, shall the history be increased as well? Likewise what's the update value? If we could make this dependent on the max buffer size instead of hard-coded values it would be enough I guess.
