Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: OpenAL issues in SFML code  (Read 2427 times)

0 Members and 1 Guest are viewing this topic.

FRex

  • Hero Member
  • *****
  • Posts: 1846
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
OpenAL issues in SFML code
« on: August 03, 2014, 04:26:53 pm »
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*:
Quote
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
Quote
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:
Quote
Deleting buffer name 0 is a legal NOP.
Back to C++ gamedev with SFML in May 2023

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: OpenAL issues in SFML code
« Reply #1 on: August 03, 2014, 07:40:47 pm »
Yes, I know that OpenAL doesn't need the original data anymore, but I need to keep it to implement the getSamples() function. So yes, splitting into 2 classes is the only solution if we want to improve memory usage.

Quote
Deleting buffer name 0 is a legal NOP.
Ok.
Laurent Gomila - SFML developer