Esenthel,

is there any reason in particular why you limit the speed of a sound to 2? I know that this is not a limit of openAL. And once a sound is loaded into memory, it doesn't really need more cpu time to play it faster.

Playing it at higher speeds is not always good because it deforms the sound, but can be useful. Right now I have no other option as to create a second sound at a faster speed myself and include 2 versions of the sound.

I think there is no need for a limit like this, but perhaps there's something to it I didn't think of?

Regards,

yvan

Hi,

That's because the secondary thread would need to run at higher frequency to check if the sound buffers got emptied and need to be reupdated.
Also playing at higher speeds has a bit bigger impact on CPU and memory usage.
I'll check if I can do something about it

Thanks! Perhaps you could allow it only for sounds which are cached into memory beforehand?

Hi,

I've just increased the max sound speed to 3 (through engine source macro MAX_SOUND_SPEED).

Please keep in mind that on Android there's a hard limit of 0.5 .. 2.0 speed limit for most devices due to OpenSL/device limits.

Thanks! I didn't expect a reply on that anymore

Meanwhile, I've been working to get my sound engine running on iOS and Android. Not done yet, but progress is good:

https://github.com/yvanvds/yse-soundengine

What API are you using to have sound on Android? Is it OpenSL too?

I'm using the JUCE library for reading soundfiles and for the audio callback. The advantage is that it's crossplatform and supports windows, mac, linux, iOS and Android. On android i suspect it uses openSL as a backend, but I'm only writing a single stereo stream to the device. All the rest is done in software.

Because I suspect you'll think this is a real bad idea, I will also give you my reasoning for this :-)

The main reason for writing this library is that I'm not satisfied with existing sound engines. I want to combine advanced 3D audio, software synths, DSP processing (like filters, fourier transforms etc.), and algoritmic composition tools into one package. OpenSL is way too limited for that. By using openSL 90% of the intended features would not work on Android or iOS.

And by making it into a static library the unused parts are stripped away anyway, so it's not as bloated as it may sound.

People often think that doing all audio processing in software takes a lot of cpu power. But in fact it's not that much. I did a test last week and it took 700 sounds to get the cpu of my nexus5 at 100%. Normal use takes only few percent of the available processing power.

On top of that I have written a virtualization system that allows you to play only the X most important sounds. I have not tested that on android but on my main computer i can render about 2000 sounds at the same time, without virtualization.

But with virtualization turned on and rendering the 100 most important sounds, I can have about 80.000 sounds active before there are any glitches. Since CPU's get faster all the time I don't worry too much of having all done in software.

I've only started development last year, so I think it's a good idea to focus on what devices will be capable of in a few years.

BTW: I'm very proud to announce that the library is now completely lock-free (if you don't count a few atomics) and spreads out the actual processing over as many cpu's as there are available!

(04-13-2014 10:47 PM)yvanvds Wrote:  Because I suspect you'll think this is a real bad idea

Not at all, I had in mind the benefits of doing that before reading the rest of your post

Well if you consider other sound engines, OpenAL, DirectSound, etc. then in the end I guess they end up doing the same as you do in your engine. It's all about mixing all sound sources, and outputting them into the correct channels (mono/stereo/5.1 etc.)
If you do it manually, through your own codes, then you end up having more freedom and same exact behavior on all platforms.

Current implementation in EE manages to work the same everywhere, although there are a few drawbacks:
-OpenSL limitations of sound speeds
-no reverb
-no limiting to only some important sounds (all sounds that are requested to played, all are processed)

Your approach is attractive, and if I had unlimited time on my hands, I'd probably try doing something similar.