ogg sound is incorrect if using sink

[gui1117]

the beginning of the sound is not correct.

full example can be found there: https://github.com/thiolliere/rodio_debug

I'm on linux

extern crate rodio;
use std::thread::sleep;
use std::time::Duration;
use std::io;
use std::io::BufReader;
use std::fs::File;
use std::io::Read;
use rodio::Source;

fn main() {
    let endpoint = rodio::get_default_endpoint().unwrap();


    // this sound is correct
    let source = rodio::Decoder::new(File::open("audio.ogg").unwrap()).unwrap();
    rodio::play_raw(&endpoint, source.convert_samples());
    sleep(Duration::from_secs(1));

    // this sound is not, the beginning is lower than it should
    let source = rodio::Decoder::new(File::open("audio.ogg").unwrap()).unwrap();
    let sink = rodio::Sink::new(&endpoint);
    sink.append(source);
    sink.detach();

    sleep(Duration::from_secs(10));
}

[tomaka]

They play the same for me. Please be more precise by what you mean with "lower".

[gui1117]

the audio heard sound like https://github.com/thiolliere/rodio_debug/blob/master/wrong_output.ogg (created with audacity)

[est31]

I can reproduce.

[tomaka]

I investigated a bit more, and realized the reason why they were playing the same for me is that I copied the example and the sound on my local dirty version of rodio :duh:.

The problem comes from here: https://github.com/tomaka/rodio/blob/master/src/queue.rs#L110-L139 Changing the threshold to 1 fixes it, but obviously it's not a clean fix.

[tomaka]

This code is responsible for chaining multiple sounds one after the other, and is always used in the case of a Sink. Basically the problem is that in order to chain sounds we want to know in advance when there is a boundary between two sounds (for optimization purposes).

But because of the way ogg decoding is implemented, there is no way to know when we are at the end of an ogg file and have to guess instead. In this situation the guess probably happens to be very wrong.

[tomaka]

#118 "fixes" this issue, but we should leave this open because it's not a proper fix.

[est31]

I have code inside my ogg decoder to get the length of a stream, I could expose it. I am working right now on a big update to add various improvements (the new version requires Rust 1.18). Is it enough if such a function is available in 2 weeks?

[est31]

Hmm I think I don't want to add it to the public interface of the new ogg crate version just now...

What is possible already now though is to use the ogg_metadata crate to get the length in samples: https://docs.rs/ogg_metadata/0.4.0/ogg_metadata/fn.read_format.html