SFML community forums

General => General discussions => Topic started by: Tex Killer on November 03, 2011, 03:47:07 pm

Title: Possible changes in the audio API
Post by: Tex Killer on November 03, 2011, 03:47:07 pm
Hello guys...
Laurent told me to create a new topic about my sugestion on the audio API.
My point here is that users cannot play chained parts of songs in a decent way with the current API. I've made some changes on my local version of SFML trying to accomplish something like that. Here is a version I changed a little from the one I'm currently using to show you:

EDIT: Code updated and upgraded.
I've renamed the class to Playlist, and changed some of the C fashion design of mine (the best I could with my limited C++ knowledge)
Now it is possible to return to a previous item during execution, and you can limit how many times it returns.
It is still not equal to my local version, but it can accomplish pretty much the same.


Inside src/SFML/Audio:
• Playlist.cpp (http://pastebin.com/SPVQ2JPN)
 ▼ Download (http://www.mediafire.com/?7b8h6k4n9566ecv)
• You also have to alter CMakeLists.txt and add this lines among the similar others:
Code: [Select]
    ${SRCROOT}/Playlist.cpp
    ${INCROOT}/Playlist.hpp
Inside include/SFML/Audio:
• Playlist.hpp (http://pastebin.com/72nX9g39)
 ▼ Download (http://www.mediafire.com/?r15obpp1l2pr6pz)

Inside include/SFML you have to alter Audio.hpp and add this line among the similar others:
Code: [Select]
#include <SFML/Audio/Playlist.hpp>I think these are the only changes, but I may be wrong. I've made a minimal example showing how to create a list and add sounds to it specifying (or not) the start and end positions in milliseconds:
• Main.cpp (http://pastebin.com/cbu5q1RR)
 ▼ Download (http://www.mediafire.com/?ob1w1h5ohsb6934)

By the way... How hard would it be to incorporate a library like FAAD2 on SFML to make it possible to use AAC sounds? I think this format is the one with the best compression at the moment.

PS: Sorry about any english errors... English is not my main language.
Title: Possible changes in the audio API
Post by: Laurent on November 03, 2011, 04:02:30 pm
Thanks for your contribution. Why don't you add it on the wiki? :)

Quote
By the way... How hard would it be to incorporate a library like FAAD2 on SFML to make it possible to use AAC sounds? I think this format is the one with the best compression at the moment.

FAAD2 is GPL, so it can't be used directly by SFML.
But is the difference significant, compared to OGG/Vorbis for example?
Title: Possible changes in the audio API
Post by: Tex Killer on November 03, 2011, 04:29:56 pm
Laurent, from my experience it is, as OGG and MP3 are quite similar.

I've googled some comparison tests over the internet, and found these:
http://forums.anandtech.com/showthread.php?t=2168530
http://www.stereophile.com/content/mp3-vs-aac-vs-flac-vs-cd-page-2

It is hard to judge the quality of music files, but I think the difference is big enough to be noticeable, specially at lower bitrates.

Sorry for the noobish question, but why can't it be used on SFML? I don't know much of these licenses.
Title: Possible changes in the audio API
Post by: Laurent on November 03, 2011, 05:00:26 pm
If SFML used a GPL library, it would have to be GPL as well. Which is of course not what I want.
Title: Possible changes in the audio API
Post by: Nexus on November 05, 2011, 02:47:04 pm
Tex Killer, I think this feature fits better as an extension than with direct SFML. But you should correct your code, some things I noticed:
Title: Possible changes in the audio API
Post by: Laurent on November 05, 2011, 03:07:48 pm
Quote
Tex Killer, I think this feature fits better as an extension than with direct SFML

It can't be an extension, because it has to use sf::SoundFile which is not public.
Title: Possible changes in the audio API
Post by: Tex Killer on November 05, 2011, 03:20:25 pm
Nexus, thank you for your tips. The thing is: I've changed only what took to make the code work without my engine. I'm programming my engine using C standard (but compiling it as c++, because of some c++ libs I'm using). That is why the mallocs and frees, and the variables being declared on top of functions. About the variable names standard, what is it that is wrong in my code? I didn't get it about the identation as well.
Thanks for the feedback, by the way.
Title: Possible changes in the audio API
Post by: Nexus on November 05, 2011, 03:38:19 pm
You should decide to use either C++ or C, at least per file. And as soon as you use only one C++ feature, you should follow C++ style, since it's usually easier and less error-prone than C style. ;)

The variable names are inconsistent. For parameters, you use the identifiers BufferSize, file or Data. For member variables, you use currentKey or myDuration. And the indentation is sometimes unclear, because statements in the same scope don't start in the same column. Or did you maybe mix tabs with spaces?
Title: Possible changes in the audio API
Post by: Tex Killer on November 05, 2011, 03:49:54 pm
Damn Notepad++... I usually code in code::blocks, and there the tabs turn into four spaces. Notepad++ keeps the tabs, but shows them as four spaces, as it seems. My bad, sorry for that.

My goal was to, later, be using C on it all, removing the SFML layer and working directly with opengl/openal and stuff, but I'm beginning to review that, as it may be bad for compatibility. The thing is I treat things (specially graphics) in a diferent way that SFML does, and have to adapt the output to match SFML standards.

Anyway, you can replace whatever tabs you can find to four spaces, and it should be idented.

I don't know what you said about constructors either. I'm not very used to C++.
Title: Possible changes in the audio API
Post by: Ceylo on November 05, 2011, 08:13:08 pm
A little note: even if the sources of libFAAD2 are under GPL it doesn't mean you can use them freely. The compiled decoder is still covered by the AAC patents and you'll have to pay if you want to distribute your software (except if it's distributed as source code only).


AAC royalties are US$ 0.48 per unit with a maximum annual payment per product of US$ 32 000.
Title: Possible changes in the audio API
Post by: Tex Killer on February 22, 2012, 10:21:18 am
Guys, I've updated the code to the last SFML 2 version as of today, changed a lot of C fashioned code and improved the functionality:

Now it is possible to register return points. It is also possible to limit how many times it returns, or to let it always returns.

The class was also renamed to Playlist, as I think that is a better name.

Please, test it and see if you can think of any changes that would improve the code.
Title: Possible changes in the audio API
Post by: Ceylo on February 22, 2012, 01:49:08 pm
Is returnTo the index of the item the playlist should continue to after the current item has finished playing ?

Otherwise it looks really interesting although some more documentation would be welcome.
Title: Possible changes in the audio API
Post by: Tex Killer on February 22, 2012, 07:38:27 pm
Yes, it is the index.

0 is before the first item, 1 is between the first and the second, and so on.
The AddItem method returns the item index, but I guess it does not help much.
Title: Possible changes in the audio API
Post by: Tex Killer on February 24, 2012, 09:19:02 pm
Anyone else gave it a try?

Laurent, are you planning on putting this sort of feature in SFML 2.0?
Title: Possible changes in the audio API
Post by: Laurent on February 24, 2012, 09:23:20 pm
No :)
Title: Possible changes in the audio API
Post by: Tex Killer on February 25, 2012, 12:52:50 am
Why?
Title: Possible changes in the audio API
Post by: Laurent on February 25, 2012, 09:26:32 am
It's too high-level, and very specific. However I'll try to provide more tools so that writing such a class doesn't require hacking into SFML sources.
Title: Possible changes in the audio API
Post by: Tex Killer on February 25, 2012, 10:22:55 am
It allows the configuration of any playlist, with loops and anything else one would want to do with return points. Why is it too specific?

About the high level, I guess it makes things simplier, and fits SFML.
Title: Possible changes in the audio API
Post by: Laurent on February 25, 2012, 02:15:27 pm
Quote
It allows the configuration of any playlist, with loops and anything else one would want to do with return points. Why is it too specific?

How many users need a playlist? Definitely not a majority.

Quote
About the high level, I guess it makes things simplier, and fits SFML.

Don't misunderstand the "Simple" of SFML. It means that what SFML provides is made simple, not that it will simplify everything that the user would need to do (like an audio engine would do).
Title: Possible changes in the audio API
Post by: model76 on February 25, 2012, 04:44:43 pm
Quote from: "Laurent"
I'll try to provide more tools so that writing such a class doesn't require hacking into SFML sources.


I look forward to seeing what you come up with, Laurent!
The audio part of SFML could use a little love in this regard.
Title: Possible changes in the audio API
Post by: Tex Killer on February 26, 2012, 09:20:51 am
I don't think this simplifies anything, it just increases the sf::Music funcionality.

But it is okay. I guess I'll wait for those changes you've said and make this code apart from SFML when it comes.
Title: Possible changes in the audio API
Post by: tobybear on February 26, 2012, 05:02:25 pm
Quote from: "Laurent"
It's too high-level, and very specific. However I'll try to provide more tools so that writing such a class doesn't require hacking into SFML sources.

Well I think it does definitely make sense to have such a functionality, though not necessarily as part of the SFML base package. What I would love most is that Laurent finds a way so that Soundfile can be accessed from outside without having to modify SFML base sources and have Tex Killer's class available as an optional download (from the wiki for example) that simple can be dropped into the project, sort if like an extension.