Cross platform Sound API/solution for IOS and Android?

[Cambiata]

I'm looking for a way to handle multi channel audio playback on mobile devices,
preferrably a solution that also works on desktop targets.

Does someone have experience of using FMOD, BASS, OpenAL or other external sound APIs from Haxe?

Unfortunately, Andy Li's hxRtAudio seems to be desktop only.
AIR is a theoretical alternative, but it doesn't seem to handle SampleDataEvent stuff well on mobile platforms.

/ Jonas

[Joshua Granick]

If you were to look into alternatives to what we are using now (OpenAL/AVAudioPlayer, SoundPool/MediaPlayer, SDL_mixer), I would possibly consider OpenAL.

I think it would be possible to use it on the desktop targets without too much trouble, especially because there appears to be an SDL_mixer-like wrapper for it. It also seems to be an API that's designed for games and sound mixing more than other alternatives.

I believe I saw something about OpenAL for Android, and am sure it could work for BlackBerry and webOS as well.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

--

Using Opera's revolutionary email client: http://www.opera.com/mail/

[James Hofmann]

Seconding OpenAL. It's a lower-level solution than e.g. SDL_mixer, since it doesn't handle file formats for you, but it also seems to work better for most use-cases.

Icculus did a lecture on open-source gamedev recently which includes several interesting audio library mentions(having trouble picking all of them out, he kind of skips around):

http://www.youtube.com/watch?v=r3wDnOAjrtk 

A lot of these libraries would be excellent for binding, at least on cpp target - and their source might be a good basis for some Haxe-native ports too.

[Tynril]

OpenAL isn't officially supported on Android - OpenSL ES is. OpenAL Soft does have a backend to OpenSL ES, but with software decoding. Also, note that OpenAL, despite its name, is not open-source. OpenAL Soft is an LGPL implementation of OpenAL, but as the name says, it's using software decoding.

The issue here is hardware/software decoding of sounds. There is no open-source library that does hardware acceleration on both iOS and Android (not considering the desktop). The "best" way is usually to use the native sound engine of the specific platforms to achieve hardware acceleration. I'd love to see an abstraction layer on that on NME, but I think the only viable way is to do it manually, using platform-specific tools, if we want hardware acceleration (and we do - we really do, right?).

[Cambiata]

Thank you guys for great feedback!

A fully cross compatible NME SampleDataEvent implementation with hardware acceleration would be great! :-) Not a trivial task, I understand.

but I think the only viable way is to do it manually, using platform-specific tools, if we want hardware acceleration (and we do - we really do, right?).

Samuel, you mean hacking together solutions with target platform APIs using Objective-C for IOS/Java for Android, and use those as externs from Haxe? Or is there a more straightforward way?

[Joshua Granick]

Well, that is sort of what NME is using right now.

I uses the native OpenAL or AVAudioPlayer implementation on iOS (code written in Objective-C), depending on whether you are playing sounds or music.

On Android, it uses the SoundPool and MediaPlayer APIS, also based on whether you are playing sounds or music.

On other targets we use SDL_mixer, with the MixChunk or MixMusic APIs.

If we were able to move to OpenAL instead of SDL_mixer, it could potentially improve the sound features for Windows, Mac, Linux, BlackBerry and webOS at once. iOS is already using OpenAL for sounds.

That just leaves Android, but Android sound is already unique, anyway.

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en

[bjorn]

There is an effort underway to add support to Android and iOS to PortAudio. I realize this may not help you today, but FYI.

[Hugh]

Yes, nme does support  NME SampleDataEvent.

As for HW acceleration - you provide it raw samples, so there is no decoding acceleration to be had - or are you talking about mixing different channels?

The main problem with the SampleDataEvent API is that it is based on an array of stereo-interleaved floats, which then get converted to sint16.

The is no way to do, say, mono sint16 samples to avoid the conversion or extra data.  I might add a "back door" for this at some stage.

Hugh