Using 1.1 spec from openal.org I've seen a couple discrepancies in the sf::SoundBuffer:
1. the samples vector is kept when it's not needed at all, this is uncompressed sound, it takes (relatively) a lot of space (compared to most things people do, like short strings, ints, sf::Textures which live on GPU memory not normal RAM etc.). This is not needed*:
void alBufferData (ALuint bufferName, ALenum format, const ALvoid *data, ALsizei size, ALsizei frequency);
The data specified is copied to an internal software, or if possible, hardware buffer.
and
The application is free to reuse the memory specified by the data pointer once the call to alBufferData returns. The implementation has to dereference, e.g. copy, the data during alBufferData execution.
*There is a 'use case'. Buffer can save to file, so it needs the samples for that, but that is like keeping sf::Image inside sf::Texture all the time instead of just creating one for loading. It's also probably not the most used feature so maybe it's not worth potentially doubling the memory used just for ease of saving the buffer back.
If that spec applies to OpenAL Soft (and it probably does..? it's a spec after all..) then this means there should be two classes, one that is OpenAL buffer, just like we have OpenGL texture and one that is software buffer just like there is software image, with same convenience function like texture has that will make a temporary software buffer, load it and then load from it to AL.
Right now, if you want to yourself edit the sounds in code, stitch, mix etc. them, you will load them into AL as well, which is a waste. And if you just want to play them in AL, you will keep them in memory, which is again a waste.
2. This is very minor - there is an if check in destructor to not call alDeleteBuffers on buffer that is 0, but that's not needed:
Deleting buffer name 0 is a legal NOP.
