Version 1.0 Roadmap

[mackron]

This issue is for tracking and discussion of the roadmap for version 1.0 of miniaudio. If you have any suggestions feel free to leave a comment.

• High Level API
• dr_vorbis and integration into miniaudio
• PulseAudio refactor
• Expose if device is default
• Custom backends
• Custom resampler backends
• Update amalgamator to remove namespaces from dr_* libraries and completely decouple dr_libs from miniaudio
• Update documentation
• Add documentation generation for API reference

A few intermediary releases will be done prior to version 1.0 which will include some of the above items. In particular, the next big release (version 0.11) should hopefully include the high level API.

The timeline is end of this year or early next year, but as we all know it always takes longer than you think. If you want to make a request for the 1.0 release, please bear this in mind as I want to get this out in a reasonable amount of time. The ASIO backend and MIDI won't be making the 1.0 release (if at all).

[frink]

Love it!

I'm excited about the inclusion and the exclusions. MIDI needs a lot more thought before it can be considered and ASIO needs more recent research to see if it is still the only option for low latency in Windows...

Kudos!!!

[raysan5]

@mackron personally, I think it's a quite demanding roadmap for 1.0. I'm not an expert on audio but implementing the High Level API, the dr_vorbis library or the Documentation seems to be really lot of work and time. As I said, I'm not an expert and I neither know the real scope of some points (what are the exact completion-state expected) but it seems to me like a long-term roadmap.

I just think this way because I used to do the same with raylib roadmap and it soon became quite stressful because all intended features/implementations used to take really lot of work... and the feeling is not good...

My recommendation: define small goals with clearly defined results and focus on short-term implementations.

[mackron]

Yep, still lots of work to do, but it's doable. The high level stuff is just the basics required for a simple 3D engine for games so it should be reasonable. For the Vorbis stuff I've booked in leave from work with the intention of working on it so hopefully I can get a decent chunk of it done. The remaining points are fairly easy I think. But as I said in the original post, I'll be doing at least one intermediary release. In fact the bump to 1.0 will probably be largely uninteresting.

[meshula]

My use of miniaudio is with LabSound and libnyquist for file r/w. So you already know my preferences about what might be in the main file :)

Assuming asio is the asio lib intended for the C++ stdlib, it's on the (short) ban list for my projects. I'm not going to go into details, but I had to maintain its use in a large, well known, project. The maintenance burden and endless new gotcha-bugs ultimately drove me to move to a much simpler implementation on older, unfashionable technology.

All that said, I love miniaudio, and thanks for all the work you put into it!

[mackron]

No, the ASIO stuff we're talking about is an audio backend often used in the pro audio space. No need to worry about any C++ stuff getting into miniaudio. :)

[meshula]

Ah, nice; looked it up :) The longer you don't implement ASIO, the longer I don't need to buy new toys!

[mackron]

Support for custom backends has been added to the 1.0 release plan.

[mackron]

Version 0.10.22 has been released with the PulseAudio refactor, default device detection and support for custom backends. That knocks three items off the list.

[frink]

It also looks like the High Level API is getting close too!!!

[mackron]

The high level API has now been released so that item is now ticked off.

[Keithcat1]

With the high-level API, not-so-mini-audio is almost on par with BASS from un4seen.com, congrats. It would be nice to have support for an encoding format that supports compression though.
Also pan in decibels?

[mackron]

Yeah the name hasn't aged well...

The encoding API is that kind of secondary feature which I put in there for a specific purpose (outputting raw output to a wav file has been useful for testing purposes). It needs some iteration, but adding support for a built-in compressed encoding format is unlikely just because of the maintenance burden versus the primary goals of the library (it's not trying to be FFmpeg). That said, I'm thinking at some point I'll add support for custom encoders like I do for decoders so people can plug in their own encoders like libopus or whatnot.

[mackron]

Moving this over to the Discussions section.