Playback artifacts in dynamic_mixer when using --release

[BonsaiDen]

There seems to be some kind of timing related issue that only manifests itself when building with --release.

Once https://github.com/tomaka/rodio/blob/master/src/dynamic_mixer.rs#L112 evaluates to true and casues next to return None the underlying audio buffer seems to still contain some non-zero samples and thus generates some very audible clicking noise which stays even when new inputs are added to the mixer. Even worse, the more sounds are played the more artifacts accumulate.

~~A "quick fix" seems to be to return Some(S::zero_value()) on line 113. However, I suspect that this might not be very performant so another potential "solution" seems to return just self.samples_rate() of these S::zero_value() frames, which seems to flush out the artifacts.~~

~~I haven't opened a PR for this yet since I don't think that I have profound enough knowledge of the library or audio programming in general to tell whether this fixes the actual underlying issue, or if I'm just applying band-aids here :)~~

Update: Further testing revealed that this still doesn't help all the time.

System: Linux 64 bit Ubuntu 14.10, Pulseaudio.

PS: I've uploaded a zip with my test sounds and a recording of the artifcats they cause:

https://www.dropbox.com/s/qttxa1taqi72poz/sounds.zip?dl=0

[gui1117]

same for me dynamic mixer sources are never dropped, the issue may be in UniformSourceIterator.

[gui1117]

I've got a minimal failing example:

extern crate rodio;

use std::io::BufReader;
use rodio::Source;

fn main() {
    let source = ::rodio::buffer::SamplesBuffer::new(1, 44100, vec![1i16, 2, 3, 4, 5, 6]);
    let source = ::rodio::source::ChannelVolume::new(source, vec![0.5, 0.5]);
    let source = rodio::source::UniformSourceIterator::<_, i16>::new(source, 2, 44100);

    // runs forever
    let output = source.collect::<Vec<_>>();
}

if I use some prints I got that ChannelVolume next function returns some, some, some, ..., some, none, some, none, some, none, ... This behavior probably disturb UniformSourceIterator

[gui1117]

I'm not sure but I don't think the doc force sources to always return None after the first None.

depending on that the issue is on channelvolume side or uniformsourceiterator side