Seek breaks span

[yara-blue]

Seek might need padding silence when resample rate or channel count change. Since the consumer has no way to know they have.

Alternative, make seek an exception and make the consumer recall sample_rate, channel count & span len.

[PetrGlad]

We may require that all variable sources are wrapped into something like UniformSourceIterator, so in most cases spans can only change channels, not sample rate...

[yara-blue]

would not help since seek is implemented at the decoder level. Those inherently do not have a uniform sample rate. And we can not resample to such a uniform source if the spans are not correct.

[PetrGlad]

At least it would help to not care about the sample rate changes downstream, in sources that come after decoders.

With decoders themselves, I am thinking of more comprehensive test harness that would generate both various source audio files and random seeks, something like property testing but for our case.

[yara-blue]

At least it would help to not care about the sample rate changes downstream

it would, but it would come at a performance cost. Hifi-resampling is performance intensive, resampling everything at the edges might be wasteful. Maybe we can make the resampler very lazy, that would help....

Honestly I think we would need a prototype before making any decision. A rodio fork that only supports a few sources (lets say queue & mix) and works by informed resampling at the input. With informed I mean that idea I had earlier with the output communicating its preferred sample rate down and everything adjusting along the way.

After I finish fixing queue I can work on the informed sample rate bit, once that's done you could make the prototype. Then we have to figure out some workloads to compare the implementations with. If the performance difference is positive or trivial the code simplifications might be worth it.