Remove dependecy toward libsndfile on all OS #757

mantognini · 2014-12-22T20:32:18Z

This implements #604. It's a rebase of feature/no_libsndfile_osx onto master (which includes feature/no_libsndfile) so be extra careful when proofreading it. Hopefully I haven't made any mistake but there were a lot of conflicts so...

What's done & what's to be done:

Android (all libs included)
Android – make loading sound compatible with APK
iOS (all libs included)
Linux (no binary to be provided)
OS X (all libs included)
Window (all libs included)

It also includes the base step toward #620.

MarioLiebisch · 2014-12-23T12:31:23Z

I've fixed Android compiling and linking in my own branch.

Commit 3b05ee1 fixes code issues, while 2498028 includes precompiled binaries.

There's still the open issue of the new audio file loading not trying to load ressources bundled inside the APK though (will have a look at this as soon as possible before opening another PR on this branch).

MarioLiebisch · 2014-12-23T12:37:22Z

src/SFML/System/FileInputStream.cpp

+namespace sf
+{
+////////////////////////////////////////////////////////////
+bool FileInputStream::open(const std::string& filename)


This would need some way of abstraction for Android, i.e. allowing the user to either load something off the sd card (i.e. current solution) or something inside/relative to the APK file. Maybe consider all relative paths to point to the APK file? Or should this be put into another new stream class?

All the loadFromFile functions in SFML already contain Android specific code, to use the dedicated ResourceStream class (which, I imagine, takes care of this problem). Can't all this stuff be mixed nicely?

Probably. It just needs some nice and convenient way to determine what the user wants.

Had a look at the whole new ...InputStream structure and I guess it's best to leave this part alone and instead modify Android's ResourceStream to provide the same interface as FileInputStream (so they're easily replaced).

Note that some loadFromFile functions (such as Shader) don't do anything regarding that matter. But we should probably discuss that on the forum. ;-)

mantognini · 2014-12-23T14:26:28Z

@MarioLiebisch you should probably drop a line here otherwise ChronicRat might work for nothing.

mantognini · 2014-12-26T14:21:16Z

Since only Android is missing, and it requires more works, I suggest we go on with reviewing this and merge it. Android stuff can be added later.

MarioLiebisch · 2014-12-26T16:32:10Z

Just keep in mind that it breaks Android.

mantognini · 2014-12-26T17:17:46Z

That's a good point. I'll add your first two commits I guess.

mantognini · 2014-12-26T17:37:29Z

Here, can you check that it's working on Android? Thanks. (I haven't added config_types.h because it's not used by ogg.h nor by os_types.h and it's a file auto generated for a specific platform.)

MarioLiebisch · 2014-12-26T18:33:57Z

It will build and link properly, but in this state it's unable to load asset files. Not sure what happens if you try to load files off the sd card/internal memory (might be a starting point for testing).

config_types.h is there since it's included and won't be found when compiling (haven't had a closer look though).

mantognini · 2014-12-26T19:02:43Z

config_types.h is there since it's included and won't be found when compiling (haven't had a closer look though).

Ha, I missed the #else in os_types.h...

Maybe it should go into a dedicated directory for android (like we used to do it with sndfile on Windows/Mac/Android) since it's platform specific. And does this file change with the different Android architectures?

MarioLiebisch · 2014-12-30T08:11:52Z

Would be another idea. It shouldn't change, since it really just holds the names of integers with a fixed length. Theoretically it might change between compilers, but considering the Android version compiles with GCC by default anyway...

mantognini · 2015-01-08T16:54:03Z

@MarioLiebisch Just to be sure, there's absolutely no difference in config_types.h across all different supported archs (mips, armeabi, armeabi-v7a, x86)?

Assuming it is the case, then:

@LaurentGomila (and others): until now we had extlibs/headers/libsndfile/{android,osx,windows}. Should we also have extlibs/headers/ogg/{android,ios,osx,windows} to follow the same spirit or do we just don't care and add config_types.h directly in extlibs/headers/ogg? Alternatively we could edit os_types.h to contain android default value (with the proper #elif statement). What is your opinion on the subject?

LaurentGomila · 2015-01-08T17:23:38Z

If it's the same then there's no reason to duplicate it per platform. There's no "spirit", let's just be pragmatic ;)

MarioLiebisch · 2015-01-08T19:20:54Z

From what I can tell, the header file is exactly the same for all Android architectures (compared armeabi, x86, and x86_64) as long as we're forcing GCC to be used.

Not sure regarding other platforms and/or compilers though.

mantognini · 2015-01-08T20:04:46Z

If it's the same then there's no reason to duplicate it per platform.

Alright. So I've checked and got the same file on OS X than @MarioLiebisch on Android. I don't know about iOS, Linux or Windows (@eXpl0it3r, since you've build them, do you know?).

For reference, config_types.h for Android is here.

eXpl0it3r · 2015-01-08T22:48:19Z

I've only built the FLAC libraries which didn't require any config_types.h. The OGG libs etc. were built by @LaurentGomila.

mantognini · 2015-01-09T05:05:59Z

Right, sorry about that. So, Laurent? ;)

mantognini · 2015-01-29T15:29:55Z

I just checked on Linux and the file is different. Don't know about Windows.

Even though we don't provide Linux binaries, it's not that hard to make a special rules for Android in src/SFML/Audio/CMakeLists.txt.

mantognini · 2015-01-29T15:42:20Z

@MarioLiebisch I've updated (rebased + force pushed) the branch, can you check that it now build fine on Android? Thanks.

MarioLiebisch · 2015-01-29T21:11:18Z

Okay, this just needs a minor fix for the paths (the way you did it won't work since the relative path (ogg/config_types.h) won't work. I'm fixing this with the next commit I push right after this comment.

This leaves just the minor issue of the Android version trying to read the audio files from the file system rather than the assets. I've modified FileInputStream for testing and it works, but I think we should make ResourceStream a public AssetInputStream or RessourceInputStream to allow users to pick either one. SFML funtions taking paths should use that one by default.

What do you think?

MarioLiebisch · 2015-03-04T08:44:16Z

Fixed already - really just been two changes at the same position in the file.

mantognini · 2015-03-04T08:44:48Z

👍

mantognini · 2015-03-05T17:16:21Z

have all issues been fixed or am I mistaken?

LaurentGomila · 2015-03-05T17:27:39Z

Yes, I think we are good to go.

eXpl0it3r · 2015-03-09T09:34:28Z

This PR has been added to my merge list, meaning it will be merged soon, unless someone raises any concerns.

mantognini · 2015-03-09T09:36:12Z

I've got some, sorry. :-P

I'm pretty much done reviewing it and just spot minor typos. Won't be long.

mantognini · 2015-03-09T09:49:47Z

Done. Nothing else for me.

a-maly · 2015-03-09T14:05:08Z

It is not possible to register your own file reader/writer that has been internally registered, just for the fact that you used to search forward instead of backward.

for (ReaderFactoryArray::const_iterator it = s_readers.begin(); it != s_readers.end(); ++it)

I'm just writing to let you know.

MarioLiebisch · 2015-03-09T14:07:28Z

@a-maly Hm... yeah, overwriting built-in filters sounds like a neat tidbit some might want to do.

LaurentGomila · 2015-03-09T16:19:54Z

I suggest that we release it now, get some feedback, and work more on it later if needed. Unless something is broken, this PR must be merged now :p

mantognini · 2015-03-09T19:38:10Z

I guess we could add a priority system, or something similar, in SFML 3 but I believe that for now this is enough. Most people will simply use the default implementation (which should be good enough in any case) I guess.

So let's proceed as-is. :-)

eXpl0it3r · 2015-03-09T23:09:47Z

👏 🎉 🍸

Now let's wait for all the bug reports. 😄

mantognini · 2015-04-13T07:50:29Z

Now let's wait for all the bug reports.

Got one! 😋

It's a slight oversight that can lead to some hard-to-debug issues: InputStream is copyable. While it should be alright with the current implementation of MemoryInputStream, it is not good with FileInputStream.

There is one thing I'm not sure of: since InputStream prior to that merge was not exported, no one could be using it before, right?

If that's the case we can just make it inherit from NonCopyable and we're done. Otherwise we can make FileInputStream (and optionally MemoryInputStream too) inherit from NonCopyable.

LaurentGomila · 2015-04-13T08:07:43Z

FileInputStream was not copyable when it used a std::ifsteam, but now with FILE* it is indeed a problem. But there's no reason to disallow copy at the base class level, so let's just do it for FileInputStream.

mantognini · 2015-04-13T08:08:28Z

Alright, will create a PR for that then.

mantognini added feature m:config m:sfml-audio s:unassigned labels Dec 22, 2014

mantognini added this to the 2.3 milestone Dec 22, 2014

mantognini mentioned this pull request Dec 22, 2014

Drop libsndfile in sfml-audio #604

Closed

MarioLiebisch reviewed Dec 23, 2014
View reviewed changes

mantognini self-assigned this Dec 23, 2014

mantognini removed the s:unassigned label Dec 23, 2014

This was referenced Jan 2, 2015

Add homebrew support #620

Closed

Relaxed cmake installation rules regarding OS X framework dependencies #767

Merged

mantognini force-pushed the feature/no_libsndfile_all_os branch from 8b8f02b to 69839e2 Compare January 29, 2015 15:40

MarioLiebisch and others added 7 commits March 4, 2015 09:36

Android: Restored old file reading behavior for audio stuff

3424467

Updated Flac, ogg, vorbis, vorbisenc and vorbisfile for MinGW and MSVC

66eab23

Marked the FLAC/Vorbis/Ogg variables as advanced

af4dac6

Removed last references to libsndfile

f17ea58

Enabled sfml-audio on iOS

6ab8d43

Fixed incorrect sample count reported by the WAV sound file reader

42a6967

Updated copyright year and Laurent's email address

0c2f306

MarioLiebisch force-pushed the feature/no_libsndfile_all_os branch from ff9e1a6 to 0c2f306 Compare March 4, 2015 08:44

Fixed a few typos/style issues

aa9a6de

eXpl0it3r merged commit aa9a6de into master Mar 9, 2015

eXpl0it3r deleted the feature/no_libsndfile_all_os branch March 9, 2015 23:09

mantognini mentioned this pull request Apr 13, 2015

Made FileInputStream non copyable #865

Merged

mantognini removed their assignment Apr 30, 2015

Bertram25 mentioned this pull request Jul 3, 2015

Crash at startup when using SFML Audio 2.3 OpenDungeons/OpenDungeons#832

Closed

tsjost mentioned this pull request May 21, 2016

Game stops as opening cutscene starts rwengine/openrw#27

Closed

Uh oh!

Remove dependecy toward libsndfile on all OS #757

Remove dependecy toward libsndfile on all OS #757

Uh oh!

Conversation

mantognini commented Dec 22, 2014

Uh oh!

MarioLiebisch commented Dec 23, 2014

Uh oh!

MarioLiebisch Dec 23, 2014

Choose a reason for hiding this comment

Uh oh!

LaurentGomila Dec 23, 2014

Choose a reason for hiding this comment

Uh oh!

MarioLiebisch Dec 23, 2014

Choose a reason for hiding this comment

Uh oh!

MarioLiebisch Dec 23, 2014

Choose a reason for hiding this comment

Uh oh!

mantognini Dec 23, 2014

Choose a reason for hiding this comment

Uh oh!

mantognini commented Dec 23, 2014

Uh oh!

mantognini commented Dec 26, 2014

Uh oh!

MarioLiebisch commented Dec 26, 2014

Uh oh!

mantognini commented Dec 26, 2014

Uh oh!

mantognini commented Dec 26, 2014

Uh oh!

MarioLiebisch commented Dec 26, 2014

Uh oh!

mantognini commented Dec 26, 2014

Uh oh!

MarioLiebisch commented Dec 30, 2014

Uh oh!

mantognini commented Jan 8, 2015

Uh oh!

LaurentGomila commented Jan 8, 2015

Uh oh!

MarioLiebisch commented Jan 8, 2015

Uh oh!

mantognini commented Jan 8, 2015

Uh oh!

eXpl0it3r commented Jan 8, 2015

Uh oh!

mantognini commented Jan 9, 2015

Uh oh!

mantognini commented Jan 29, 2015

Uh oh!

mantognini commented Jan 29, 2015

Uh oh!

MarioLiebisch commented Jan 29, 2015

Uh oh!

MarioLiebisch commented Mar 4, 2015

Uh oh!

mantognini commented Mar 4, 2015

Uh oh!

mantognini commented Mar 5, 2015

Uh oh!

LaurentGomila commented Mar 5, 2015

Uh oh!

eXpl0it3r commented Mar 9, 2015

Uh oh!

mantognini commented Mar 9, 2015

Uh oh!

mantognini commented Mar 9, 2015

Uh oh!

a-maly commented Mar 9, 2015

Uh oh!

MarioLiebisch commented Mar 9, 2015

Uh oh!

LaurentGomila commented Mar 9, 2015

Uh oh!

mantognini commented Mar 9, 2015

Uh oh!