SFML community forums
Help => Audio => Topic started by: Laurent on April 11, 2009, 01:02:08 am
-
Hi
I know that some of you are waiting for a Music::SetPlayingOffset function. I added it today to the sfml2 branch, so I'd be happy to get some feedbacks :)
Important for Linux users
This version requires at least libsndfile 1.0.18, which might not be in the official Linux repositories (1.0.17 seems to be the latest), so you might have to download it and compile it.
-
Great to hear that. I'll check that out later.
Oh, btw, for the developers using Debian testing:
Package: libsndfile1
Version: 1.0.18-2
-
I know this is an older thread, but I figured it would be better than starting a completely new one for my question which is directly related.
Is it possible to backport this SetPlayingOffset function into the svn trunk (what I think is referred to as 1.6)? That's what I'm currently using at the moment, and so far I can't get 2.0 working.
I really need the functionality to seek in music files (well really at the moment all I need is a Reset() function that resets the current offset to 0, since I need to play, stop, and then play again from the beginning of a music file). Maybe it would be easier to create a reset function than a random seek time one? Either way, it would be a big help for me if I could find some way to do this. Even a tutorial on how to port the audio code from 2.0 back into 1.6 and I can do it myself, or at least try :P If somehow this feature already exists and I missed it.. sorry about that, I just don't see anything like it atm.
Any help in this would be greatly appreciated. Thanks!
-
Is it possible to backport this SetPlayingOffset function into the svn trunk (what I think is referred to as 1.6)?
No, I'm sorry. The features in trunk are frozen, I'm only making it more stable and robust until SFML 2 comes and replaces it. And this new feature requires many modifications to the code.
so far I can't get 2.0 working
What's your problem?
well really at the moment all I need is a Reset() function that resets the current offset to 0, since I need to play, stop, and then play again from the beginning of a music file
Why don't you call Stop() and then Play(), to reset your music?
-
It chokes on the Window - Win32 compiling code, still trying to figure out if/how I can get it to compile here. Here's a quick excerpt:
In file included from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:36:
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/Joystick.cpp:29:1: warning: "_WIN32_WINNT" redefined
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/windows.h:48,
from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.hpp:32,
from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.cpp:28,
from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:35:
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/windef.h:20:1: warning: this is the location of the previous definition
In file included from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:35:
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.cpp: In member function 'void sf::priv::ContextWGL::CreateContext(sf::priv::ContextWGL*, unsigned int, const sf::ContextSettings&)':
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.cpp:291: error: 'PFNWGLCREATECONTEXTATTRIBSARBPROC' was not declared in this scope
There's more, but I suspect it's because of some windows thing which I'm trying to figure out too. Backend btw is just a small file to simplify compilation using the SFML system constants and #includes of the .cpp files.
Also, Play(), Stop(), and then Play() was what I was doing, since I figured that Stop reset the timer :) Only, it does nothing to reset the current time, at least in the 1.6 trunk that I'm using (which is only a month old). At first I noticed that after playing a music file, stopping it for a scene and then coming back, nothing was played. It registers as status::playing, but if you print out the GetPlayingOffset() results it stays at the last known point.
I can understand wanting to keep the trunk feature frozen though. Maybe there's a bug with Stop if it's apparently supposed to reset the counter? I suppose it could just be my fault too (probably) and I'll double check my code again for playing too.
-
Yeah, I just checked again, and it does indeed only play until the first stop, and the next time a music is played, I hear nothing. Printing the offset directly after a Stop() is called has some interesting results too. It's never 0 (except for the first time when the music actually plays), but it doesn't seem to be static either. One music track I was testing with had the offset be from 60 to 90 and fluctuate. At first I thought that was because it was looping and not playing, but I turned looping off for it and the same thing happened...
Maybe my best bet is to get 2.0-svn compiling I think.
-
It chokes on the Window - Win32 compiling code
Do SFML and its samples compile?
If so, you should provide a minimal and complete example that reproduces the problem you get.
Only, it does nothing to reset the current time, at least in the 1.6 trunk that I'm using (which is only a month old). At first I noticed that after playing a music file, stopping it for a scene and then coming back, nothing was played. It registers as status::playing, but if you print out the GetPlayingOffset() results it stays at the last known point.
Looks like a bug in SFML ;)
Yeah, I just checked again, and it does indeed only play until the first stop, and the next time a music is played, I hear nothing
Ok, I'll check this and let you know.
-
Well, I couldn't get the svn 2.0 to compile via the Makefile, since I'm in windows/mingw not linux, and visual studio 2005 builds the library (but not the samples, though that's probably because I'm missing certain libraries like QT).
I fixed one of the error messages by adjusting the glext include to reference my existing glext files (which are more updated that the ones on sfml's svn), but I still get some errors relating to defines:
In file included from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:36:
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/Joystick.cpp:29:1: warning: "_WIN32_WINNT" redefined
In file included from c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/windows.h:48,
from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.hpp:32,
from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/ContextWGL.cpp:28,
from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:35:
c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/windef.h:20:1: warning: this is the location of the previous definition
In file included from c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Backend.cpp:38:
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp: In member function 'void sf::priv::WindowImplWin32::ProcessEvent(UINT, WPARAM, LPARAM)':
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:643: error: 'WM_XBUTTONDOWN' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:655: error: 'WM_XBUTTONUP' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp: In static member function 'static sf::Key::Code sf::priv::WindowImplWin32::VirtualKeyCodeToSF(WPARAM, LPARAM)':
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:753: error: 'VK_OEM_PLUS' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:754: error: 'VK_OEM_MINUS' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:757: error: 'VK_OEM_COMMA' was not declared in this scope
c:/Documents and Settings/UserName/Desktop/Repositories/Gamestone/Libs/SFML/Window/Win32/WindowImplWin32.cpp:758: error: 'VK_OEM_PERIOD' was not declared in this scope
make[2]: *** [CMakeFiles/gamestone.dir/Libs/SFML/Window/Backend.cpp.obj] Error 1
make[1]: *** [CMakeFiles/gamestone.dir/all] Error 2
make: *** [all] Error 2
Looks like it might be a problem with mingw's symbols for certain input types? I'll look more into it later, now I need to get to bed (stayed up so late today :P)
-
What's your version of MinGW / gcc?
SFML 2 compiles fine with MinGW, I think you have a problem with your compiler (maybe an old version, or bad settings).
-
When you say it compiles fine with MinGW, how are you compiling? I only see a regular Unix makefile (which if run in MinGW fails because I don't have X11 installed, which I obviously wouldn't have building for windows :P), and then I see build scripts for visual studio, xcode, and codeblocks. Is there a windows-mingw specific makefile somewhere in here?
My version of gcc is:
$ gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)
Using TDM-MinGW from here:
http://www.tdragon.net/recentgcc/
Everything else seems to compile fine, and I haven't changed any settings for the compiler from the default install. Still looking into it though, since visual studio apparently had no problem with that particular code.
-
I commented out the WM_XBUTTONDOWN and such symbols in the WindowImplWin32.cpp file that were problematic, and everything compiled fine afterwards. So I don't have access to mouse XButtons (what are xbuttons anyway?) on the mouse and a couple keys on the keyboard, but it compiled.
Did the Ogg reading code get removed from SFML audio in 2.0? I have problems opening such files, saying they aren't implemented. Also having problems with previously working opengl code for displaying sprites so it's not the only problem.
I guess for now I'll just go back to the 1.6 code (now that I have the latest svn downloaded I'll update to the latest 1.6 code, even though looking at the logs it doesn't seem that much has changed in the last month) and continue onward. Maybe there's a simpler way to just get music files to reset in that, and like you said, sounds like a bug or something.
-
When you say it compiles fine with MinGW, how are you compiling?
Currently with Code::Blocks. There's no direct makefile for MinGW.
I commented out the WM_XBUTTONDOWN and such symbols in the WindowImplWin32.cpp file that were problematic, and everything compiled fine afterwards. So I don't have access to mouse XButtons (what are xbuttons anyway?) on the mouse and a couple keys on the keyboard, but it compiled.
I don't know how they do but the Win32 API support (especially constants) is always incomplete in MinGW. Maybe you should try an official version of MinGW ? I know that a 4.x was (finally) released a few weeks ago.
Did the Ogg reading code get removed from SFML audio in 2.0? I have problems opening such files, saying they aren't implemented
You have to use the new libsndfile DLL provided with SFML 2.
Also having problems with previously working opengl code for displaying sprites so it's not the only problem.
Changes were made to this area. Until the documentation comes, you can read the corresponding topics on the forum and look at the samples (the OpenGL on,e in this case).
Maybe there's a simpler way to just get music files to reset in that, and like you said, sounds like a bug or something.
Yep :)
I'll look into that soon.
-
When you say it compiles fine with MinGW, how are you compiling?
Currently with Code::Blocks. There's no direct makefile for MinGW.
I commented out the WM_XBUTTONDOWN and such symbols in the WindowImplWin32.cpp file that were problematic, and everything compiled fine afterwards. So I don't have access to mouse XButtons (what are xbuttons anyway?) on the mouse and a couple keys on the keyboard, but it compiled.
I don't know how they do but the Win32 API support (especially constants) is always incomplete in MinGW. Maybe you should try an official version of MinGW ? I know that a 4.x was (finally) released a few weeks ago.
Did the Ogg reading code get removed from SFML audio in 2.0? I have problems opening such files, saying they aren't implemented
You have to use the new libsndfile DLL provided with SFML 2.
Also having problems with previously working opengl code for displaying sprites so it's not the only problem.
Changes were made to this area. Until the documentation comes, you can read the corresponding topics on the forum and look at the samples (the OpenGL on,e in this case).
Maybe there's a simpler way to just get music files to reset in that, and like you said, sounds like a bug or something.
Yep :)
I'll look into that soon.
Ahh gotcha on the codeblocks thing, yeah I haven't used that in years.
I did see that they are starting to finally get around to GCC 4.0 in mingw, and I tried it a little while ago for a different issue. Certainly that is a possibility. Though with the other problems and changes to opengl and such I think I'll just stick with 1.6 for now since I know it works aside from the sound issue. I have a class project that I'm working on, and there are plenty of other areas I can finish up in the meantime in the next 2 weeks, and I might be able to hack my code so that it reopens the sound file or something in case.
Also, I don't use DLLs (compile from source), so I know the ogg thing wasn't pertaining to that. In fact, I keep tabs on the libraries like libsndfile and make sure they are up to date, so the libsndfile I am using is 1.0.20. I noticed that in Audio/ there are no longer any Ogg specific source files like there are in 1.6, so that's why I was asking. I thought maybe the ogg reader derived classes were moved elsewhere into a plugin or something.
Thanks for the help so far, I hope I can get this game finished well enough for this class, and then I can post up about it on the other forum board (along with the engine I'm writing).
-
Also, I don't use DLLs (compile from source), so I know the ogg thing wasn't pertaining to that. In fact, I keep tabs on the libraries like libsndfile and make sure they are up to date, so the libsndfile I am using is 1.0.20
You have to use libsndfile as a DLL because of its licence.
On Windows, SFML currently uses version 1.0.18 so maybe it is incompatible with your 1.0.20. You should try to use the DLL provided in the SDK.
I noticed that in Audio/ there are no longer any Ogg specific source files like there are in 1.6, so that's why I was asking. I thought maybe the ogg reader derived classes were moved elsewhere into a plugin or something.
It was added to libsndfile, that's why I was able to remove a lot of ogg/vorbis specific stuff in the audio module :)
-
Also, I don't use DLLs (compile from source), so I know the ogg thing wasn't pertaining to that. In fact, I keep tabs on the libraries like libsndfile and make sure they are up to date, so the libsndfile I am using is 1.0.20
You have to use libsndfile as a DLL because of its licence.
On Windows, SFML currently uses version 1.0.18 so maybe it is incompatible with your 1.0.20. You should try to use the DLL provided in the SDK.
I don't see how there would be a problem with licensing. Libsndfile is LGPL, my project is LGPL, and SFML is zlib. Is there a conflict between these that I haven't heard of? Besides, I don't use dlls or anything related to shared libraries because I'm making the code as cross platform as possible (and easily usable on systems like the iphone). So static linking from compiled sources is much much easier for me to do :) I guess I'm also a bit of a purist in that I like to compile what I'm using unless it's a system library (like OpenGL or OpenAL) ;)
I noticed that in Audio/ there are no longer any Ogg specific source files like there are in 1.6, so that's why I was asking. I thought maybe the ogg reader derived classes were moved elsewhere into a plugin or something.
It was added to libsndfile, that's why I was able to remove a lot of ogg/vorbis specific stuff in the audio module :)
Ah well that makes sense I guess about the 2.0 audio changes :P Still for now I'm going to stick with 1.6 since it already works fine except for this strange bug. I wonder if it activates the same on my macosx box... Hmm, I will check into that.
-
I don't see how there would be a problem with licensing. Libsndfile is LGPL, my project is LGPL, and SFML is zlib. Is there a conflict between these that I haven't heard of?
No :)
If your project is LGPL itself then it's fine.
Besides, I don't use dlls or anything related to shared libraries because I'm making the code as cross platform as possible (and easily usable on systems like the iphone). So static linking from compiled sources is much much easier for me to do
Ok I see. I do the same (whenever possible), but now the Linux guys want me to make it possible to link against shared libraries (so that users can update to newer versions of these libraries). And I think they're right ;)
-
I tried the play/stop/play stuff with the current trunk (SFML 1.6), it works fine.
The code I used is the Sound sample, with Music.Play() replaced with
Music.Play();
sf::Sleep(2);
Music.Stop();
Music.Play();
Make sure that you recompiled SFML from scratch ("make clean", or "rebuild" in IDE) and that there's no version of any DLL (including OpenAL) that could conflict with it.
If it doesn't help, you can try the Sound sample like I did. If it works then you probably have an error in your own code.
-
I tried the play/stop/play stuff with the current trunk (SFML 1.6), it works fine.
The code I used is the Sound sample, with Music.Play() replaced with
Music.Play();
sf::Sleep(2);
Music.Stop();
Music.Play();
Make sure that you recompiled SFML from scratch ("make clean", or "rebuild" in IDE) and that there's no version of any DLL (including OpenAL) that could conflict with it.
If it doesn't help, you can try the Sound sample like I did. If it works then you probably have an error in your own code.
I just tested out the Sound sample according to your changes, and it does work. It was very easy to test out the sample with my existing build system by just replacing the contents of my main.cpp file with the sample Sound.cpp :D I'm glad the samples here are pretty small and easily readable, also goes to show how much little setup is needed to get something running (one of the reasons I really like this library).
Anyway, it looks like I was doing everything you are doing, except for one thing. I wasn't using those sf::Sleep commands anywhere. Commenting out the one you put in there into the sample recreates the same issue I am having. So I guess I'm having some kind of threading problem? Not giving enough sleep time inbetween calls to the SFML audio components? Is there some sort of guide to follow on how/when to put those calls in? Should I be putting sf::sleep calls in my mainloop for each music file that is playing? I've done some multithreaded programming before, but it's never been my strong point :P
Putting a Play(), sleep(2), stop(), play(), sleep(2), in my code, is giving me a similar thing as before, where it starts playing, stops, and then doesn't play again on the second play(). Any tips?
At least I'm getting this resolved though and it looks like it's just a matter of proper threading :)
-
I wasn't using those sf::Sleep commands anywhere. Commenting out the one you put in there into the sample recreates the same issue I am having. So I guess I'm having some kind of threading problem? Not giving enough sleep time inbetween calls to the SFML audio components?
So you mean that you call Stop() right after Play()?
Anyway, calling play/stop/play without any delay (ie. commenting the sf::Sleep call) still works for me.
Should I be putting sf::sleep calls in my mainloop for each music file that is playing?
No, it should work fine under all circumstances. If there's any issue related to multi-threading, then it's a bug in SFML ;)
Putting a Play(), sleep(2), stop(), play(), sleep(2), in my code, is giving me a similar thing as before, where it starts playing, stops, and then doesn't play again on the second play(). Any tips?
Hum? Isn't it the exact same thing that I did?
-
I wasn't using those sf::Sleep commands anywhere. Commenting out the one you put in there into the sample recreates the same issue I am having. So I guess I'm having some kind of threading problem? Not giving enough sleep time inbetween calls to the SFML audio components?
So you mean that you call Stop() right after Play()?
Anyway, calling play/stop/play without any delay (ie. commenting the sf::Sleep call) still works for me.
Should I be putting sf::sleep calls in my mainloop for each music file that is playing?
No, it should work fine under all circumstances. If there's any issue related to multi-threading, then it's a bug in SFML ;)
Putting a Play(), sleep(2), stop(), play(), sleep(2), in my code, is giving me a similar thing as before, where it starts playing, stops, and then doesn't play again on the second play(). Any tips?
Hum? Isn't it the exact same thing that I did?
Yeah, before I was just calling them one after another, I thought they automatically took care of all the threading/timing stuff (and there's nothing on the tutorial page about using sf::sleep that I saw).
I modified the sample code to recreate what I was experiencing:
void PlayMusic()
{
// Load an ogg music file
sf::Music Music;
if (!Music.OpenFromFile("lepidoptera.ogg"))
return;
// Display music informations
std::cout << "lepidoptera.ogg :" << std::endl;
std::cout << " " << Music.GetDuration() << " sec" << std::endl;
std::cout << " " << Music.GetSampleRate() << " samples / sec" << std::endl;
std::cout << " " << Music.GetChannelsCount() << " channels" << std::endl;
// Play it
Music.Play();
sf::Sleep(2);
Music.Stop();
Music.Play();
sf::Sleep(2);
// Loop while the music is playing
while (Music.GetStatus() == sf::Music::Playing)
{
// I don't have this loop of waiting while playing in my code, so commenting out below is more in line
// with what I am doing (even though I probably should be using it I guess now)
// Leave some CPU time for other processes
//sf::Sleep(0.1f);
// Display the playing position
std::cout << "\rPlaying... " << std::fixed << std::setprecision(2) << Music.GetPlayingOffset() << " sec ";
}
std::cout << std::endl;
}
Doing this has it play for a few seconds, stop, and then nothing comes out of the speakers after that.
I'm probably the one doing something wrong here I imagine. I can understand the initial sleep call after play I guess, but is the loop of sleep calls necessary, or only for this sample?
-
Still works for me.
But wait. My first modification works for you, but yours, where you add a sf::Sleep(2) after the second play, doesn't work anymore?? I'm lost :shock:
Regarding the sf::Sleep calls, you don't need them at all in a real program, it's just like this in the sample to let the program live as long as the music is playing.
-
Still works for me.
But wait. My first modification works for you, but yours, where you add a sf::Sleep(2) after the second play, doesn't work anymore?? I'm lost :shock:
Regarding the sf::Sleep calls, you don't need them at all in a real program, it's just like this in the sample to let the program live as long as the music is playing.
Nevermind, my bad, I misspoke when I said the first example you gave me with Sound.cpp didn't have the bug. I just went back to that again and I get the same thing :P I think it was because originally I didn't know how long the real track was and that I heard anything at all made me think it works :P Then I heard the full thing and did the later modifications on my own. But yeah, I get the same result, it starts, stops, and then never starts playing again.
Ok, good to know about the sleep commands. Then maybe there's something else going on here.....
-
Ok :D
So, I come back to my first suggestions:
Make sure that you recompiled SFML from scratch ("make clean", or "rebuild" in IDE) and that there's no version of any DLL (including OpenAL) that could conflict with it.
You can also send me an example compiled on your machine, so that we can make sure that it's not a an external DLL that is conflicting.
-
Ok :D
So, I come back to my first suggestions:
Make sure that you recompiled SFML from scratch ("make clean", or "rebuild" in IDE) and that there's no version of any DLL (including OpenAL) that could conflict with it.
You can also send me an example compiled on your machine, so that we can make sure that it's not a an external DLL that is conflicting.
Well I'm pretty sure its not make clean, as I've done that a lot. I'll do it again though and see. I'll upload my compiled exe to a filehosting site in a bit and put a link here.
-
I think I solved the problem :D I'm pretty sure now it was the OpenAL dll I was using, which is odd but whatever. I substituted the openal32.dll file that is distributed with SFML-svn, and viola, it started playing like expected on the sample code.
I guess the official OpenAL dll is experiencing some technical difficulties.
I will try this on my own game and see if fixes the bug there too.
EDIT: Hooray! It indeed works now fine in my own game :) So it was just the OpenAL dll all this time, man I feel like an idiot now :P Sorry for taking up so much of your time on this, I really appreciate all the help though!
-
I'm glad you solved this problem :)