Plugable audio formats

[dnperfors]

I was looking in the roadmap and on the forum and I saw that there are plans to implement different audio formats and that is is not possible to include MP3 support.
I looked in the source code (very quickly) and I found out that file formats are somewhat hardcoded, that made me think :idea:
What if it is possible to plug audio formats (seperate libraries) into the audio library? It will make it possible to get MP3 support (for the people who can use it) and it will make it easier to add more formats, even formats that are not used very much. And all this is possible without getting a lot of dependencies that are not used by a lot of people...

At the moment I have no idea how this should look like and where to put it, but I can take a look this weekend and give you an idea...

The same principle is possible with different image formats and even render systems...

When it is done well, the system will not get more complex for the user, because the functionality stays the same, only when he wants to have other audio support, he adds the plugin...

What do you think of this idea?

[Laurent]

This is usually a good idea for an engine, but I don't think it's necessary to have this kind of system for such a low-level API.

You have code for a new audio / image format ? Then I'll be glad to integrate it into SFML directly. There's no need to have a plugin system.

Same for renderers : everything can be static, as long as I keep only one renderer per platform (which is what I want to do).

The only problem is MP3, but I encourage people to use OGG as it's better and free.

[dnperfors]

No I don't have any formats available...

I understand your opinion. It makes sence... but you are restricting the user to use one kind of output system (rendering and sound I am talking about here)
But what when I want to give the end user the use of which system it uses (for example DirectX or OpenGL or DirectSound, OpenAL, OSS, ALSA or PulseAudio) This is not possible at the moment... But that is of course a whole diffrent discussion, so I don't go any further

[Laurent]

Actually, I think the user shouldn't care about what's used internally, as long as things remain simple and fast. There's really no point providing several back-ends for either audio or rendering, I just have to make SFML work for everyone.

Choosing the rendering API would make sense in a next-gen 3D engine, where one API can be slightly faster in some cases, implement some specific features, or have bad support on a platform; but in the case of SFML it would be useless in my opinion, as OpenGL is more than enough for the 2D stuff SFML does.

Regarding audio, I can't see any reason to choose one API or another as long as it works fine.

Developing flexible / modular / super powerful stuff is great, but sometimes there's just no point doing it

[rick_777]

I'm working on a cross-platform Video Editor (see sig), and I need to have a pluggable architecture so people can add support for different file encodings. Since MP3 is a VERY popular encoding (and actually the de-facto standard) in online video, not supporting it would be a disaster.

The same goes for audio devices: If I can output audio to a special USB device (say, a 10.2 surround sound studio, a streaming website or perhaps a virtual environment, or maybe even a compatibility layer for SDL audio), I'd need a pluggable architecture.

[Laurent]

I'll probably think about a plugin architecture for audio and image for the next version ; however this is not a proirity and I'm still not sure whether I'll implement it or not.

You obviously need a more flexible audio API ; maybe you should have a look at other libraries such as FMod, Audiere, SDL_mixer, OpenAL, ...