Deallocations causing real-time issues in UniformSourceIterator

[LinoBigatti]

While reviewing real-time issues in the source code of a custom Source, which uses UniformSourceIterator, RT-sanitizer noticed the following call to free, which is not real-time safe:

==3137==ERROR: RealtimeSanitizer: unsafe-library-call
Intercepted call to real-time unsafe function `free` in real-time context!
    #0 0x558ee21b2218 in free /home/runner/work/rtsan-libs/rtsan-libs/llvm-project/compiler-rt/lib/rtsan/rtsan_interceptors_posix.cpp:781:36
    #1 0x558ee3f3f462 in _$LT$alloc..raw_vec..RawVec$LT$T$C$A$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::hb7b789cbf687a464 /home/lino/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/raw_vec/mod.rs:406:18
    #2 0x558ee3f0a31a in core::ptr::drop_in_place$LT$alloc..raw_vec..RawVec$LT$f32$GT$$GT$::hbbace72dc3778dc1 /home/lino/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:524:1
    #3 0x558ee3f09f43 in core::ptr::drop_in_place$LT$alloc..vec..Vec$LT$f32$GT$$GT$::ha086ab91020cee54 /home/lino/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:524:1
    #4 0x558ee2192d9a in rodio::conversions::sample_rate::SampleRateConverter$LT$I$GT$::into_inner::h1bd55bdb7682e840 /home/lino/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rodio-0.21.1/src/conversions/sample_rate.rs:96:5
    #5 0x558ee204f660 in _$LT$rodio..source..uniform..UniformSourceIterator$LT$I$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::ha02484dbde2a47d6 /home/lino/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rodio-0.21.1/src/source/uniform.rs:82:21
    #6 0x558ee2081e56 in _$LT$rodio_scheduler..Scheduler$LT$I$GT$$u20$as$u20$core..iter..traits..iterator..Iterator$GT$::next::haca8445718b4f9eb /home/lino/prj/coop-editor/rodio_scheduler/src/lib.rs:404:28
    
(The callstack then continues a bit further, omitted for clarity...)

SUMMARY: RealtimeSanitizer: unsafe-library-call /home/lino/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/raw_vec/mod.rs:406:18 in _$LT$alloc..raw_vec..RawVec$LT$T$C$A$GT$$u20$as$u20$core..ops..drop..Drop$GT$::drop::hb7b789cbf687a464

I believe this is caused by the inner source of the UniformSourceIterator being dropped/taken and then bootstrapped again inside the body of UniformSourceIterator::next: https://github.com/RustAudio/rodio/blob/47dab16f79f02fe1c327a89c814c3e3f8498647b/src/source/uniform.rs#L82-L85 However, this behaviour dates back to at least 2015 from the history I've seen.

Is there a reason behind this design? Ideally I'd like to send a PR fixing it, but I would need some pointers first.

[roderickvd]

It's when a span ends at which point it's no longer guaranteed that the channel count and sample rate are the same, and it has to re-init to adapt. We're planning to take out spans because they're causing way more problems than they're worth for the edge cases they intend to solve. But that's gonna take quite some effort.

Whether the span ever will end depends on the source and potentially decoder you're using.

Beyond UniformSourceIterator I think there are a lot of places in Rodio where allocations and deallocations are taking place. It'd be nice to optimize all that for your real time use case; but just saying that today there may be more places where this bites.

[roderickvd]

In cpal too by the way although for ALSA I’ll soon be submitting a PR to fix that.

[yara-blue]

Is there a reason behind this design? Ideally I'd like to send a PR fixing it, but I would need some pointers first.

I'm trying to free up time to overhaul Rodio's design which makes a lot of parts (like this) way more complex then they need to be. (See the queue and its many unresolved issues). That is the proper way to fix this.

Until then I'd rather not change anything, since we are bound to delete it anyway.