Author Topic: Some weird audio problems (Read 25598 times)

zac · « **on:** October 10, 2008, 05:02:53 pm »

Now, I am encountering some further problems with the sf::Music class.
First, the Music clicks from time to time (I think when the buffer is reloaded) and is not fluent. Other music players did not have any problems with these files.
(No, this is not the clicking bug with the optimizations for ogg-Files, I encountered this problem too but setting optimization to -O instead of -O2 for std_vorbis.c fixed it)
The CPU power for playing Music is kind of extraordinary too (every 2 seconds, I think on reloading the buffer, it consumes up to 80%) for an ordinary 4 minute ogg music file with 128 bps.

The other problem is kind of weird:
Most sound files shorter than one buffer (I am taking 2*44100 samples as buffer for it reduces clicking noises) do not even work. They are loaded successfully (OpenFromFile returns true for this .wav-file), but Play simple does nothing, while longer music files work without any problems (except this clicking noise).
Do I have to build in another interface for playing sf::Sound's to fix this?
Because I wanted the soundfiles to be replacable without changing the code, I really dislike this idea... what if someone wants to exchange a little notification sound or the initialization sound of an application with some longer piece of music? This would, for sf::Sound, stay in memory until the application dies (I really need a call-and-forget interface for playing Music, so I am thinking about an own soundManager with its own thread, but this is surely a nice amount of work). And for the normal application state, it would consume even more CPU power and memory than the other solution...

Ah yes, and sometimes (somehow by random, but not very often) if the sound device is already opened by another player, my app gets a SIGSEGV signal from out of the "Play()" call.

Currently testing on the following system:
64 bit Ubuntu
AMD Athlon 64 3500+

Laurent · « **Reply #1 on:** October 10, 2008, 05:35:23 pm »

A lot of improvements have been made to the audio module, you should try the latest sources from SVN.

zac · « **Reply #2 on:** October 10, 2008, 06:03:23 pm »

Okay. Will see if that works.

zac · « **Reply #3 on:** October 10, 2008, 06:16:16 pm »

But make does not work anymore with the new makefiles. This is kinda funny...

Quote

sudo make install
Makefile:5: *** missing separator. Schluss.

Ah. Now it works... Dunno why it did not work ??.??

zac · « **Reply #4 on:** October 10, 2008, 08:10:43 pm »

Now, with the new version of the Audio-Lib, the problem with the sound (interruptions, clicks) vanished.
But now, the whole thingy takes 100% of the CPUs power...

Edit: Ah, think I found the problem. One of the two soundfiles was corrupted...
Btw... great library

thanks.

Laurent · « **Reply #5 on:** October 10, 2008, 08:33:30 pm »

Great, I'm glad to see that the new version *really* fixes this kind of bugs

zac · « **Reply #6 on:** October 10, 2008, 10:58:06 pm »

After experimenting a bit, something strange (again):
I have now a map which stores file names of sound files as keys and Music* as values.
It works well... but only the first time.
When the music is stopped (or finished), the Music (that was dynamically allocated before) is deleted and the pointer in the map is set to NULL (while the key stays in the map). Now, if I want to play the same piece of music again (or another piece of music, I suppose...), I use this line of code:

Code: [Select]


musics[fname] = new Music;

which immediately kills my application with a SIGSEGV (Access violation).

It is NOT the map. I tested

Code: [Select]

musics[fname] = (Music*)123; in the line before, and this does NOT lead to an Access violation.

Strange:
This seems also to affect sf::String (or maybe sf::Font maps??), because the strings in the Messagebox (my handler for SIGSEGV) look pretty fucked up (with other SIGSEGVs I had before, they mostly looked quite normal.)

Normally, Music* m = new Music; m = new Music; works without exceptions... this is quite strange. Maybe it has to do with the fact that the code that controls the maps, adds new Music* to the map and deletes the old ones runs in a special thread?
All accesses to the map and to the music requests are secured with a sf::Mutex.

Well, it couldn't get weirder: As I checked Music* m = new Music; m = new Music; after starting the Music (or Sound), I realized that the SIGSEGV vanished.... so I removed these two instructions, and the SIGSEGV was there again. So I put these instructions back in - and it works again.
Are there any global/static vars possibly not initialized?

Behaviour for Sound is exactly the same.
One single static pointer seems to be sufficient, so this is not that bad.

Laurent · « **Reply #7 on:** October 11, 2008, 09:49:12 am »

There are two possible issues :
- Multi-threading : if OpenAL behaves like OpenGL, then you can only use the audio context in the thread which created it (ie. the main thread)
- Initialization : if you have globals there might be a problem too; I have to check this

zac · « **Reply #8 on:** October 11, 2008, 02:01:20 pm »

Hm... the thread calling "Music* globalMusicPtr = new Music;" is the main thread while the Music is played by another one, this works fine. The other threads do not execute these commands, so the context seems to be thread-global.