Add ma_decoder_init_with_tell() for Custom Backends Requiring onTell

[j4587698]

Problem Description

When implementing a custom decoder backend (e.g., using FFmpeg or other I/O systems), the current ma_decoder_init() function forces onTell to be NULL. This prevents custom backends from using the onTell callback to retrieve critical information like the actual file size, which is necessary to calculate total frames or duration.

Use Case

For example, in an FFmpeg-based backend:

1. The onTell callback is needed to determine the file size via avio_size().
2. Without knowing the file size, the decoder cannot accurately calculate PCM frame counts or durations.
3. This limitation forces developers to use workarounds (e.g., pre-reading the entire file), which is inefficient.

Proposed Solution

Add a new initialization function:

ma_result ma_decoder_init_with_tell(
    ma_decoder_read_proc onRead,
    ma_decoder_seek_proc onSeek,
    ma_decoder_tell_proc onTell,  // <-- New parameter
    void* pUserData,
    const ma_decoder_config* pConfig,
    ma_decoder* pDecoder
);

This function would allow passing a custom onTell callback, mirroring the flexibility of onRead and onSeek.

Impact

• Backward compatibility is preserved (existing ma_decoder_init() remains unchanged).
• Enables proper support for custom backends requiring onTell.
• Minimal code changes needed (likely an internal refactor to accept onTell).

[mackron]

It's funny you mention this because coincidentally I've been doing a maintenance pass on dr_mp3 which is what provides MP3 support for miniaudio, and it was just the other day I needed to add an onTell callback to it. I'm going to need to add support for it to miniaudio anyway for dr_mp3, so this is definitely on the table. Not sure exactly in what form it'll take just yet. I might just add a separate function like you suggested for the 0.11.x cycle, but just break the API in the dev-0.12 branch. Will report back on what I decide.