Messages

1

Audio / Re: Ogg Vorbis files don't play correctly on big-endian systems

« on: October 18, 2017, 11:23:14 pm »

Code: [Select]

bool is_big_endian()
{   
    sf::Uint16 n = 1;
    return *reinterpret_cast<char*>(&n) == 0;
}

It's not 100% portable, but I'm guessing it's portable enough for the systems SFML is likely to run on. I'm also guessing it gets mostly optimized away when you turn up optimization. But these are just guesses. Maybe someone with more expertise on endianness can chime in. Or I'll do some research.

2

Audio / Ogg Vorbis files don't play correctly on big-endian systems

« on: October 18, 2017, 01:36:12 am »

Ogg Vorbis files sound like static when played on big-endian systems using SFML. This is because ov_read in SoundFileReaderOgg.cpp requires you to specify the endianness that you want the samples in, and it's currently always passed 0, corresponding to little-endian.

I've tested a solution that checks system endianness to pass the right argument to ov_read on both x86-64 (little-endian) and big-endian PowerPC, and it seems to fix the problem.

FWIW, I've read the discussion on endianness in https://github.com/SFML/SFML/pull/357, and I believe this is one of those rare cases where we have to check endianness, because, for whatever reason, ov_read can't be invoked to automatically use the native byte order.

Example Ogg Vorbis File
Documentation for ov_read

Example code (invoke on big-endian system with sound file name argument):

Code: [Select]

#include <SFML/Audio.hpp>
#include <SFML/System.hpp>

int main(int argc, char** argv)
{
    sf::SoundBuffer sb;
    sb.loadFromFile(argv[1]);

    sf::Sound s(sb);
    s.play();
    sf::sleep(sf::seconds(2.5));
}


3

Feature requests / Re: Support for extensible format PCM wave files

« on: September 27, 2017, 12:20:42 am »

Sure. By the way, I found that SFML 2.1 supports this wave format, on account of using libsndfile. I suppose you could consider this a regression, but then again, the switch away from libsndfile probably caused a lot of "regressions".

For the purposes of branch naming, workflow, would you prefer to consider this a feature or a bug fix?

4

Feature requests / Support for extensible format PCM wave files

« on: September 26, 2017, 07:17:07 am »

SFML only supports wave files with the PCM format tag. However, there are PCM wave files that use the "extensible" tag. The extensible format supports PCM and non-PCM formats, and things like mapping channels to speaker positions. Any audio that can be put in a PCM format wave can be put in an extensible format wave.

I stumbled on this issue after trying to load some wave files I had converted using sox. Turns out it's because it uses the extensible format when outputting a wave file with a bit depth greater than 16. Other sound processing applications might use this tag for PCM data. I found that Audacity can be configured to save wave files in this format, at least.

Would you like SFML to support this format? By support, I mean accepting integer-encoded PCM audio in a file with the extensible format tag, not supporting non-PCM formats or extra features (such as the channel-mapping feature mentioned above). If so, I would be happy to open an issue and create a pull request. Support just requires adding a little more header parsing.

The rationale for adding this feature is that it shields users from having to be concerned about a low-level detail--whether their PCM wave file is using the regular PCM format tag or the extensible tag.

Example of an unsupported file.

Wave File Specifications