system_audio_format.h
The operating system's own audio decoders.
#include <sonore/system_audio_format.h>- 2types
- 3other declarations
On this page
Design notes
WindowsMediaAudioFormat decodes through Media Foundation (a source reader asked for float PCM: MP3, AAC in M4A/MP4 or ADTS, WMA, ALAC, AC-3 -- whatever decoders the machine has installed). CoreAudioFormat does the same on macOS through Audio Toolbox's ExtAudioFile. Both land in the WavData every other reader here fills.
Why this is opt-in
The decoders compiled into audiofile.h open a file identically on every machine, and that is a property worth keeping as the DEFAULT: a format that opens on the user's Mac and silently fails on their collaborator's PC is a project that loads with an empty sampler and nothing saying why. So readAudioFile() still answers from its fixed set, and these decoders sit behind it only once an application asks -- enableSystemAudioFormats() -- for the formats it has decided are worth that trade (an M4A a user dragged out of their music library is the usual one).
Even then the built-in decoders go FIRST: a WAV, FLAC or MP3 opens through the SDK's own code whatever the OS has, and the OS only sees what they could not open -- a container they do not know, or a codec inside one they refuse.
Why Media Foundation is loaded at runtime
The N and KN editions of Windows ship without Media Foundation until the user installs the Media Feature Pack. A plugin LINKED against mfplat.dll does not fail to decode there -- it fails to LOAD, and the host reports a broken plugin with no reason. LoadLibrary at the first decode, from System32 only, turns that into isAvailable() == false. The handful of GUIDs needed are spelled out here for the same reason (they would otherwise come from mfuuid.lib); audio_io_test checks each against the SDK's own.
Paths, not URLs
MFCreateSourceReaderFromURL takes http:// as happily as a path, and a plugin that opens a socket because a string in a project file said so is doing something nobody asked for. The file is opened as a byte stream (MFCreateFile), which only knows the file system.
Offline-only, like every reader here: these allocate, block on disk and run a decoder, so they belong on a loader thread, never in process().
Types 2
Decoding through Windows Media Foundation.
Exists on every platform so code that names it compiles everywhere; isAvailable() is false off Windows, and on a Windows without Media Foundation installed.
Decoding through Audio Toolbox's ExtAudioFile on macOS: AAC and ALAC in M4A/CAF, MP3, AIFF-C codecs, and whatever else the system can read.
Functions 3
- fn
inline bool systemAudioFormatsAvailable()True when this platform has a system decoder this SDK can reach. Linux has none: there is no system codec API there, only libraries a user may or may not have, and the built-in set is the answer.system_audio_format.h:496 - fn
inline bool readAudioFileWithSystemCodecs(const char* path, WavData* out, std::string* error = nullptr)Decode through this platform's system decoder, whatever the file is -- bypassing the built-in ones. readAudioFile is the entry point that prefers the built-in decoders; this is for a caller that has decided otherwise.system_audio_format.h:503 - fn
inline void enableSystemAudioFormats(bool enable = true)Put the system decoders behind readAudioFile -- after the built-in ones -- or, with false, take them away again. Per module (a plugin's choice is its own), and safe to call while other threads are loading files.system_audio_format.h:524