Fix crash in resampler

[duysqubix]

I noticed that when using small buffers and rapidly changing ratio, the resampler tries to access samples outside of the old buffer buf1, causing a crash.

My solution is to simply use the oldest sample we have. Not sure if this is good enough, but works for me.

Original issue: faiface/beep#152

[MarkKremer]

If this is reproducible it needs fixing but I don't want to accept the PR just yet because I don't know if it fixes the root of the problem.

[MarkKremer]

A comment on another issues:

Old issue, and I'm not sure what in particular causes it, but I think it may be related to using a Resampler with the same old and new sample rates, e.g. beep.Resample(4, 48000, 48000, stream). Something about the math involved with the resampling may result in funny values when the sample rates match.

edit: Actually, now I'm getting the same panic I was getting before, even though I am resampling from 44.1KHz to 48KHz. I am able to trigger it by replaying from the same stream over and over and over. Here is a screenshot of a debugger window with relevant values listed in case it helps in determining what's happening: https://i.imgur.com/um4xylV.png

The screenshot linked above:

[MarkKremer]

As mentioned in the issue and seen in the screenshot, the buffer is extremely small. However, the Resampler only ever shrinks the buffers when the source Streamer provides only a part of the requested samples. This is not allowed. From the dobblock above the Streamer.Stream() interface method:

// There are 3 valid return pattterns of the Stream method:
//
//   1. n == len(samples) && ok
//
// Stream streamed all of the requested samples. Cases 1, 2 and 3 may occur in the following
// calls.
//
//   2. 0 < n && n < len(samples) && ok
//
// Stream streamed n samples and drained the Streamer. Only case 3 may occur in the
// following calls.
//
//   3. n == 0 && !ok
//
// The Streamer is drained and no more samples will come. If Err returns a non-nil error, only
// this case is valid. Only this case may occur in the following calls.
Stream(samples [][2]float64) (n int, ok bool)

If the source streamer returns n < len(samples) samples, in the following call the streamer must be fully drained. The only way Resampler.buf1 becomes small is because the source streamer returns a small number of samples multiple times in a row.

Assuming you didn't write any custom streamers, we need to check all existing streamers to see if they implement this behavior properly to fix this problem...

[MarkKremer]

Relevant bug in flac.Decode: #126 (comment)

[MarkKremer]

The Resampler has been rewritten with extra attention paid to buffer offsets. This issue should be fixed now. Feel free to re-open if you run into this problem again.