Current situation:
- The buffer_margin leads to interpolated packets buffer at inconvenient moments, which degrades sound quality.
- Turning the buffer_margin to zero leads to interpolated packets when the buffer plays itself empty (because the playback is faster than the capture side) and just isn't big enough to act as buffer. Without a prebuffering mechanism this problem occurs from the begin (even if playback and capture side match in speed), with prebuffering the problem only occurs as described, after a while after which the buffer has been played empty. Of course the jitter buffer will adjust after a few losses due to being too small, but will hit the same problem again soon.

Jitter Buffer design change suggestions:
- The current jitterbuffer has no concept of how big it wants to be, it only notices when it gets too small (because packets come late in that case) or gets too big (lots of packets coming early), and adjusts relatively (size +1 or size - 1). The new jitter buffer should have a concept of how big it wants to be (based on experience aka old data), this could be called "target_size".
- The Jitter Buffer should try and maintain the target_size by dropping ticks or pushing interpolated data, but only when it detects an opportune moment (e.g. a chunk of silence). Maybe if the situation gets urgent target_size may also be adapted not so optimal moments.
- Before the first valid data is returned via jitter_buffer_get is naturally a very opportune moment to buffer up to target_size (where target_size is still at its default value which the user can set, since there is no "history" yet that could have resulted in a new view of the required target_size.