<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - The client has not a chance to provide data, when absolute offset is used in a stream without prebuffering and underrun happend for long time" href="https://bugs.freedesktop.org/show_bug.cgi?id=103103#c16">Comment # 16</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - The client has not a chance to provide data, when absolute offset is used in a stream without prebuffering and underrun happend for long time" href="https://bugs.freedesktop.org/show_bug.cgi?id=103103">bug 103103</a> from <a class="email" href="mailto:tanuk@iki.fi" title="Tanu Kaskinen <tanuk@iki.fi>"> Tanu Kaskinen</a> <pre>I found out why the overruns happen even in the "fixed" version. Adjusting the write amount in write_samples() to compensate for the jump doesn't help, because pa_stream_write() subtracts only the write length from the internal requested_bytes variable. The jump is not taken into account, so pa_stream_writable_size() will keep returning non-zero values even though in reality the buffer has been filled completely. pa_stream_write() actually has a comment about this: /* This is obviously wrong since we ignore the seeking index . But * that's OK, the server side applies the same error */ s->requested_bytes -= (seek == PA_SEEK_RELATIVE ? offset : 0) + (int64_t) length; I don't know why Lennart didn't bother fixing this properly in <a href="https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=373b5efe51238b0ad34cb9a9d8fc61b973afdad8">https://cgit.freedesktop.org/pulseaudio/pulseaudio/commit/?id=373b5efe51238b0ad34cb9a9d8fc61b973afdad8</a> So in conclusion: the requested_bytes tracking needs to be fixed at the client side, and judging from the comment, apparently there's a similar problem at the server side.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>