[PERF] MP3 seeking gets progressively slower in long files with MiniAudio-backed decoder.

[ctompos]

1. Describe the Performance Issue

Seeking within long MP3 files appears to become progressively slower as the target position gets later in the file when using SoundFlow's built-in MiniAudio MP3 decoder path. I have not verified whether the issue exists when using the FMPEG module.

2. Area of the Library Affected

The suspected culprit is:

SoundFlow’s built-in MiniAudio-backed MP3 decoder seek path, specifically:
StreamDataProvider.Seek(...)
→ MiniAudioDecoder.Seek(...)
→ ma_decoder_seek_to_pcm_frame(...)

3. Scenario Causing Slowness

Seeking within long MP3 files appears to become progressively slower as the target position gets later in the file when using SoundFlow's built-in MiniAudio MP3 decoder path.

In my app, Auzi, playback is using SoundFlow 1.4.1. Auzi delegates seeking directly to SoundFlow, and the slowdown appears to happen inside the MiniAudio decoder seek call rather than in the app's own playback layer.

4. Expected Performance

Seeking to an arbitrary position in a long MP3 should be roughly bounded and should not scale linearly with the target timestamp, at least when the input stream is seekable.

5. Actual Performance

For a long MP3 file, seeks near the beginning complete quickly, but seeks later in the file take much longer.

Example timings from the same file:

Target position	Seek time
00:00:30	21 ms
00:10:00	391 ms
00:30:00	809 ms
01:00:00	1210 ms
02:00:00	2421 ms

This makes timeline scrubbing feel increasingly delayed on long MP3s.

6. Minimal Reproducible Example (MRE) (Highly Recommended)

A minimal repro should be possible with a long seekable MP3 file:


using System.Diagnostics;
using SoundFlow.Backends.MiniAudio;
using SoundFlow.Providers;
using SoundFlow.Structs;

using var engine = new MiniAudioEngine();

using var stream = File.OpenRead(args[0]);
using var provider = new StreamDataProvider(engine, AudioFormat.DvdHq, stream);

var formatInfo =
    provider.FormatInfo
    ?? throw new InvalidOperationException(
        "Stream data provider did not report audio format information."
    );

foreach (var seconds in new[] { 30, 600, 1800, 3600, 7200 })
{
    var sampleOffset = checked(seconds * provider.SampleRate * formatInfo.ChannelCount);

    var sw = Stopwatch.StartNew();
    provider.Seek(sampleOffset);
    sw.Stop();

    Console.WriteLine($"{TimeSpan.FromSeconds(seconds)}: {sw.ElapsedMilliseconds} ms");
}

7. Profiling Data (if available)

SoundFlow Version

1.4.1

.NET Version

.NET 10

Operating System

Windows 11, macOS Tahoe, Ubuntu 25.10

Architecture

Windows and Ubuntu (x64), macOS (ARM64)

Audio Backend Used (if known)

MiniAudioEngine usage varies by OS.

Specific Audio Hardware (if relevant)

No response

Audio Buffer Size / Sample Rate

No response

9. Additional Context

No response

Requirements Checklist

• I have searched the existing issues to ensure this performance issue has not already been reported.
• I have provided a clear description of the issue and the scenario.
• I have included performance metrics if possible.
• I have considered providing an MRE.
• I have completed the environment information.

[ctompos]

A possible fix would be for SoundFlow to enable miniaudio’s MP3 seek-table support when it is working with a seekable MP3 stream. In current miniaudio, this appears to be supported through ma_decoder_config.seekPointCount. If SoundFlow’s bundled miniaudio version includes this field, SoundFlow could set it for seekable MP3 streams. If not, updating miniaudio or using the equivalent dr_mp3 seek-table APIs may be needed.

This would probably be best limited to seekable streams, since building the seek table may require scanning the file during decoder initialization. That tradeoff seems reasonable for local MP3 playback: opening a long file may take a little longer and use a bit more memory, but seeking later in the file should become much faster and more predictable.