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

Author Topic: Possible changes in the audio API  (Read 9806 times)

0 Members and 1 Guest are viewing this topic.

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Possible changes in the audio API
« 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
▼ Download
• 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
▼ Download

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
▼ Download

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.
« Last Edit: March 24, 2013, 04:42:34 pm by Tex Killer »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Possible changes in the audio API
« Reply #1 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?
Laurent Gomila - SFML developer

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Possible changes in the audio API
« Reply #2 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.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Possible changes in the audio API
« Reply #3 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.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Possible changes in the audio API
« Reply #4 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:
  • Declare constructors that can be invoked with one argument as explicit.
  • Don't use manual memory management (new, delete) and especially not the one from C (malloc, free).
  • Use the constructor initializer list.
  • Use a uniform naming convention (parameters, member variables).
  • Don't declare loop variables like k outside the loop.
  • Try to make code more simple and readable, or use at least some comments to make intentions clear. Also correct indentation.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Possible changes in the audio API
« Reply #5 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.
Laurent Gomila - SFML developer

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Possible changes in the audio API
« Reply #6 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.
« Last Edit: March 24, 2013, 04:46:17 pm by Tex Killer »

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Possible changes in the audio API
« Reply #7 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?
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Possible changes in the audio API
« Reply #8 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++.

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
Possible changes in the audio API
« Reply #9 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.
Want to play movies in your SFML application? Check out sfeMovie!

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Possible changes in the audio API
« Reply #10 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.

Ceylo

  • Hero Member
  • *****
  • Posts: 2325
    • View Profile
    • http://sfemovie.yalir.org/
    • Email
Possible changes in the audio API
« Reply #11 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.
Want to play movies in your SFML application? Check out sfeMovie!

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Possible changes in the audio API
« Reply #12 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.

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Possible changes in the audio API
« Reply #13 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?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Possible changes in the audio API
« Reply #14 on: February 24, 2012, 09:23:20 pm »
No :)
Laurent Gomila - SFML developer

 

anything