David Chocholatý

Just a little sum up. To make this PR ready, the last thing from my side is to finish the documentation and descriptive comments, if the previous changes will pass...

> sorry for the nitpicks again.... Absolutely no problem, this is how I should have written it the first time, I just did it too much automatically. Now, it should...

Perfect, thank you very much for merging.

The main difference is, that in the previous version the maximum amount of frames that can be provided into the RubberBand is set. From some RubberBand discussion, it just serves...

> Just to clarify, we still reversed the interaction with rubberband. Rubberband is asking us for data instead of us handing it data. Correct? Yeah, that's right. To just clear...

> This is ambiguous to me. Do you mean we fill rubberband with a bunch of samples that are just 0 (so silence in practice), or do we call its...

> So this version basically feeds rubberband silence until we have real audio data to serve? Right, exactly.

> > When the last block of the input buffer is processed and the amount of frames that RubberBand requires is greater than the rest of the input buffer frames,...

> And my main question is still, why does rubberband not do all of this internally by default if it's better? RubberBands recommends the "pull" model for real-time usage because...

> Ok thanks. I think you've answered all of my questions for now. It probably makes sense to summarize some of that info and put it in the code for...