Tracking issue for audio engine rewrite

This tracks landing the changes from https://github.com/RustAudio/rodio-experiments into Rodio. This involves integrating the new rubato resampler and specializing it where possible.

Background:

For a long time we've had mysterious bugs round spans. Spans allow a source to change parameters (sample-rate and channel count) during playback. We've concluded that spans where a mistake as correctly handling audio that at any point is:

really hard to do correctly.
impossible to optimize well leading to bad performance.

Most audio should be converted to the playback parameters at the very start of the audio pipeline. To make this easier we are adding two new source types. Both do not allow parameters to change, one fixes this at runtime the other needs the parameters known at compile time.

Approach

This is a large overhaul at around 7700 lines of code (ignoring docs & comments). To keep things reviewable we'll do this in reasonably sized PRs of around 500 lines. Help is greatly appreciated!

Phase one

Implementation in: #903 and #904

land const source
remove experimental from fixed source
land try-into adaptors/convertors between sources (others in phase two)
note overhaul in Readme
land most basic generators

Phase two

Implementation in: #905 and #910

channel conversions
resampler and integrate with rubato

Phase three:

Implementation in: #911

land one effect and pure_effect! macro
land all other effect
deprecation warning on effects in DynamicSource that are not sound

Phase four

add new combinators [a, b, c].mixed() etc.
add all generators (noise etc, function gen. etc)

Phase five

rename current source to dynamic source
add Source = DynamicSource type alias with deprecation warning
Remove placeholders

Phase six

port all examples
re-add controls to automatic gain control
rewrite Rodio main docs
update porting guide (needs to be really nice this time :3 )
prepare and make announcements

Small chores

check the new queues for: fix: don't re-invoke exhausted source during keep-alive silence #913

Open Questions

Do we deprecate Source in favor of DynamicSource?
Do cons sources and the ConstSource trait get default generics?

One point for discussion:

Should the ConstSource have a default generic? as in should it be:

trait ConstSource<SR=44100, CH=2> { ... }

Such that it can be used as:

fn takes_a_const(source: impl ConstSource)

Or

fn takes_a_mono_const(source: impl ConstSource<CH=1>)

If we do we should do the same for the generators (for now only silence but we will land others soon see #901)

For now I've gone with no default generics. While removing them would be a breaking change adding is not*, so we can safely postpone the decision.

*: this gets complicated but let's just say it is not breaking...

@PetrGlad

Since this is a rather big effort I'd love to spread out the review load a little. @PetrGlad do you have time by change to review some of this? Each PR is around 500 lines when compared to the previous (so 1a compared to 1b etc). I'd also love your take on this @iluvcapra.

The larger effort is to add two new source traits that both forbid sample rate and channel count from changing. This enables a bunch of optimizations (or rather saves us from doing a bunch of checks) and makes Rodio simpler and more correct. In time we will be moving over functionality from the current Source trait to these two new traits: (FixedSource and ConstSource).

I've not been following the development for a while, frankly do not have much energy for everything :). I do not really mind larger PRs as long as they single-purposed. The change would be big, so anyway everything has to be checked anyway. I will look at those this weekend.

Since this changes the API anyway. Was it considered to use frame count (multiply of number of channels in a source) as seek unit? Using sample count is a constant source of errors (mistakes can unintentionally swap channels).
The buffers do not necessarily should be structured as list of frames, they can stay as plain sequences of interleaved samples, but the APIs would always assume the minimal seek unit is a frame (set of samples at certain moment in time).
Or was this idea abandoned for some reason?

@PetrGlad

Hey @PetrGlad, glad to see you back in action and helping review!

I think working in frames would be great too. I remember @yara-blue and I kicked it around but couldn't make it work. Can't find it on the repo anymore, maybe it was in Discord? Anyway I vaguely remember it was an issue with the const generics or something?

We've got this in the ecosystem: https://docs.rs/dasp_frame/latest/dasp_frame/

I had to fix my sleep again :)
I have a comment regarding those const sources. I would expect them to be interchangeable with sources whose parameter are set at run-tine (during initialization). Is this going to be supported?
Span-less API is a long lasting discussion, and I am wondering if supporting const can be left to a later extension/improvement. One can for example to have a couple implementation to demo that those versions are now possible, but start with completing sources whose parameters are initialized at run-time.

Regarding using frames as a seek unit, I see that the new API uses Duration, in that case it is less relevant. Maybe Duration is sufficient for most cases, but seeks would not be "sample perfect".
A bit less convenient but simpler API would be to have a common Duration->frame-number convertor method/function and allow picking frame number directly. Alternatively frame-seeking could be a trait that is implemented only whenever it makes sense.
I would not necessarily suggest the change, just to make sure that the choice is conscious.

@PetrGlad

I have a comment regarding those const sources. I would expect them to be interchangeable with sources whose parameter are set at run-tine (during initialization). Is this going to be supported?

Well I thought that was impossible, turns out I was wrong. We might still want three distinct implementations for some sources (one const, one fixed and one dynamic), simple because const might allow more optimizations. That will have to wait till const_trait_methods get stabilized. But that is fine, we can fine tune things later.

See the playground below on how we can do this:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=08efa451291a2f6171ce9e65a4754a47

I'm strongly considering taking the above and reworking everything into that. Will take a bit though it's a lot of work. @PetrGlad what do you think of it? Also @roderickvd If you got the time could you give that playground a quick look I'd love you're take. Both of you feel free to say if it needs some documentation to make clear what is going on. I considered adding some but I did not want to make it even longer.

Span-less API is a long lasting discussion, and I am wondering if supporting const can be left to a later extension/improvement.

We could, it might still be worth to bring them along now so we are sure the current module structure and APIs make sense when offering users a switch.

@roderickvd

@roderickvd and @PetrGlad if you have half an hour this weekend please give the above a look. I'm planning to start implementation somewhere next week.

Just to keep a reference https://rust-lang.github.io/rfcs/0911-const-fn.html

It looks like ConstSource would be a marker trait? It seems that even const trait functions, had they been supported would not help since we would want both const and non const sources.
Since DynamicSource would normally be used in only special cases (when the actual source genuinely have spans), and should normally be fed through resampler, I'd prefer not to require mentions of spans unless it is actually necessary.
Maybe

#![allow(unused_variables, dead_code)]
use std::time::Duration;

trait FixedSource: Iterator {
    fn sample_rate(&self) -> u32;
    fn channel_count(&self) -> u16;
    fn total_duration() -> Option<Duration>; // I guess it is not always known?
}

trait DynamicSource: FixedSource {
    fn current_span_len(&self) -> Option<usize>;
}

trait ConstSource<const SR: u32, const CH: u16>: FixedSource {}
....

My doubt here is that presence of current_span_len changes meaning of other getters: one may accidentally require FixedSource and expect parameters to not change, but actual implementation may also be a DynamicSource so returned values could potentially change. If everything is derived from dynamic source then users accepting sources would have to either assert (span_len==none) or handle spans anyway.
Maybe DynamicSource should be a distinct trait in this case:

trait FixedSource: Iterator {
    fn sample_rate(&self) -> u32;
    fn channel_count(&self) -> u16;
    fn total_duration() -> Option<Duration>; // I guess it is not always known?
}

trait DynamicSource: Iterator {
    // yes, the declaration looks duplicated, but the contract is different from one in FixedSource
    fn sample_rate(&self) -> u32;
    fn channel_count(&self) -> u16;
    fn total_duration() -> Option<Duration>; // I guess it is not always known?

    fn current_span_len(&self) -> Option<usize>;
}

trait ConstSource<const SR: u32, const CH: u16>: FixedSource {}
....

Here FixedSource & friends would genuinely not need to care about spans anymore.DynamicSource adapters would know that they should handle spans at compilation time.
Or, maybe, something like

trait StreamShape {
    fn sample_rate(&self) -> u32;
    fn channel_count(&self) -> u16;
}

trait FixedSource: StreamShape, Iterator {
    fn duration() -> Option<Duration>; // Maybe a different name, to emphasis difference with DynamicSource
}

// The declaration of getters is shared, and users will not confuse it with FixedSource
trait DynamicSource: StreamShape, Iterator {
    fn total_duration() -> Option<Duration>; // I guess it is not always known?
    fn current_span_len(&self) -> Option<usize>;
}

trait ConstSource<const SR: u32, const CH: u16>: FixedSource {}
....

or the variation on this idea:

trait FixedSource: Iterator {
    fn shape() -> StreamShape;
    fn duration() -> Option<Duration>; // Maybe a different name, to emphasis difference with DynamicSource
}

trait DynamicSource: Iterator {
    fn current_shape() -> StreamShape;
    fn current_span_len(&self) -> Option<usize>;
    fn total_duration() -> Option<Duration>; // I guess it is not always known?
}

The last 2 options are probably my favorites. Maybe also duration getter could also be part of StreamShape. In that case current_span_len() would actually be current_shape().duration() (could be stubbed with a default implementation for compatibility):

trait DynamicSource: Iterator {
    fn current_shape() -> StreamShape;
    fn total_duration() -> Option<Duration>; // I guess it is not always known?
}

We're not 1.0 yet so we can change the API, but since many projects already use rodio we can have a dedicated branch for breaking changes to polish API before switching.

Or, while I am at it...

trait StreamShape { // Probably could even be a struct, since normally it will not change once initialized.
    fn sample_rate(&self) -> u32;
    fn channel_count(&self) -> u16;  
    fn duration() -> Option<Duration>;
}

trait FixedSource: StreamShape, Iterator {
}

trait DynamicSource: Iterator<FixedSource> {
  fn total_duration() -> Option<Duration>;
}

In short I'd keep DynamicSource and Fixed/Const sources separate. Only case where they can potentially be interchangeable is only while first span lasts. Accepting this is not worth all the risks that we wanted to avoid with this change. I Imagine we should have explicit adapters that accept DynamicSource as input and provide span-less output. We can have a default one with default resampler, and set of some usual channel count convertor presets, users may provide their own if they are unhappy with the defautls. I'd like Iterator<impl FixedSource> idea in case we want to support this case even after the rewrite. I think some codecs still actually need spans anyway?

@PetrGlad

Looks nice. The chain gives us const, fixed and dynamic upcasting for free.

Amplify only takes const sources, because SR and CH sit on the struct. A fixed source with runtime parameters (like a decoder) can't go into it - @PetrGlad is that what you were asking about? How about moving SR and CH from the struct to the impl:

struct Amplify<S>(S);

impl<S: DynamicSource> DynamicSource for Amplify<S> { /* delegate to S */ }
impl<S: FixedSource> FixedSource for Amplify<S> {}
impl<const SR: u32, const CH: u16, S: ConstSource<SR, CH>> ConstSource<SR, CH> for Amplify<S> {}

Two small things:

total_duration() is missing &self (and returns Duration where Source returns Option<Duration>).
A type could implement ConstSource for several SR/CH pairs, so callers would need a turbofish which isn't so ergonomic. Would using default generics make sense?

Regarding current_span_len: a dynamic source can't be passed as a FixedSource, so shouldn't that be OK? We could continue have fixed sources return None.

What I would like do separate is Dynamic versus Fixed/Const sources. I think they should not be interchangeable without explicit conversion. And thus it is perfectly OK, even desirable, for their APIs to be separate/incompatible. In the API sketches above I tried to maintain that. Anyone wanting to connect over this boundary this should do this conversion explicitly - we should provide default conversion connectors both ways for backwards compatibility and for cases Dynamic source is genuinely required. The default in the examples should be span-less API.

Those 2 APIs can share some definitions. For example, description of a span's stream is identical to description of Fixed/Const source's stream, both in shape and semantics. This is what some versions of my API sketches above make explicit. Although it makes new DymanicSource API incompatible too, could still be a good choice for 1.0.

Here is the version that I would prefer spanless-api-prototype-petr/src/source_new.rs:

I decided to keep StreamShape as struct (not 2 separate getters) to emphasis that it does not change after the source initialization.
The API prefers span count to avoid rounding errors, Duration is still available as convenience.
In this version DynamicSource is just an Iterator. This is something I would like to see in 1.0. It can be renamed to not conflict with what we have now for smother upgrades.

@roderickvd

I would like to see actual use cases for ConstSource. I could imagine that number of channels is known at compile time. But sample rate would depend on system's defaults, and duration depends on the audio fragment. These 3 parameters define a stream {sample rate, channel count, number of frames} which ones should be const? Are there cases where const sources can be helpful in practice? I understand that const versions are introduced to facilitate optimizations, but it looks to me that trying to make those convenient no matter what we complicating code back again. The whole point of span-less API was to simplify and streamline code... I'd prefer to keep const implementations option available for cases where it helps but only make that option convenient to the extent it does not complicate the rest of the code much...

@roderickvd What are default generics?

Thanks for that prototype and detailed response! I've been ill for a few weeks so I'm a little behind. I hope to give you all a more in depth reply later, but there is a bunch of stuff I need to catch up with first!

I would like to see actual use cases for ConstSource. I could imagine that number of channels is known at compile time. But sample rate would depend on system's defaults, and duration depends on the audio fragment. These 3 parameters define a stream {sample rate, channel count, number of frames} which ones should be const?

Some use cases of the top of my head:

You have a neural net that has been trained on specific parameters (for example for noise cancelling) and you wish to make that available as an effect.
You're building a communication system and you have a wire format with fixed parameters

I'd say the first is the strongest motivator.

Navigation Menu

Repository navigation

Tracking issue for audio engine rewrite #901

Background:

Approach

Phase one

Phase two

Phase three:

Phase four

Phase five

Phase six

Small chores

Open Questions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for audio engine rewrite #901

Description

Background:

Approach

Phase one

Phase two

Phase three:

Phase four

Phase five

Phase six

Small chores

Open Questions

Activity

yara-blue commented on Jul 22, 2026

yara-blue commented on Jul 29, 2026

PetrGlad commented on Aug 22, 2026

PetrGlad commented on Aug 24, 2026

roderickvd commented on Aug 24, 2026

PetrGlad commented on Sep 7, 2026

PetrGlad commented on Sep 7, 2026

yara-blue commented on Sep 7, 2026

yara-blue commented on Sep 13, 2026

PetrGlad commented on Sep 13, 2026

PetrGlad commented on Sep 13, 2026

PetrGlad commented on Sep 13, 2026

roderickvd commented on Sep 20, 2026

PetrGlad commented on Sep 27, 2026

PetrGlad commented on Sep 27, 2026

yara-blue commented on Sep 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions