Proposal: switch iOS and Android audio to Superpowered

[badlogic]

See: http://superpowered.com/#axzz3bKHPWovT

Comments? I'm sick of Android's audio APIs.

[Tom-Ski]

Yesyesyes. Any ogg support?

----- Reply message -----
From: "Mario Zechner" notifications@github.com
To: "libgdx/libgdx" libgdx@noreply.github.com
Subject: [libgdx] Proposal: switch iOS and Android audio to Superpowered (#3173)
Date: Wed, May 27, 2015 9:37 AM

See: http://superpowered.com/#axzz3bKHPWovT

Comments? I'm sick of Android's audio APIs.

---

Reply to this email directly or view it on GitHub:
#3173

[badlogic]

No Ogg support.
On May 27, 2015 10:54 AM, "Tomski" notifications@github.com wrote:

Yesyesyes. Any ogg support?

----- Reply message -----
From: "Mario Zechner" notifications@github.com
To: "libgdx/libgdx" libgdx@noreply.github.com
Subject: [libgdx] Proposal: switch iOS and Android audio to Superpowered
(#3173)
Date: Wed, May 27, 2015 9:37 AM

See: http://superpowered.com/#axzz3bKHPWovT

Comments? I'm sick of Android's audio APIs.

---

Reply to this email directly or view it on GitHub:
#3173

—
Reply to this email directly or view it on GitHub
#3173 (comment).

[Tom-Ski]

Well I'm game. Would it be a good idea to keep the old audio and deprecate? Or just go for broke?

[badlogic]

We can keep both for now. Easy enough to have a config flag to pick the
backend.
On May 27, 2015 11:18 AM, "Tomski" notifications@github.com wrote:

Well I'm game. Would it be a good idea to keep the old audio and
deprecate? Or just go for broke?

—
Reply to this email directly or view it on GitHub
#3173 (comment).

[MobiDevelop]

Are you saying it has no ogg support at all?

[MobiDevelop]

After having a brief look over things, I'd favor going the extension route over replacing the backend audio implementations with this SDK.

[badlogic]

you have a point. missing ogg support is something i could add.
On May 27, 2015 3:16 PM, "Justin Shapcott" notifications@github.com wrote:

After having a brief look over things, I'd favor going the extension route
over replacing the backend audio implementations with this SDK.

—
Reply to this email directly or view it on GitHub
#3173 (comment).

[StanDem]

it would be much better than what we have now. even without ogg support.

[MobiDevelop]

Maybe, but someone would have to build the java wrapper and vet the licensing terms before we can find out.

[badlogic]

Yeah, i'll do that :)

On Tue, Jun 9, 2015 at 3:26 PM, Justin Shapcott notifications@github.com
wrote:

Maybe, but someone would have to build the java wrapper and vet the
licensing terms before we can find out.

—
Reply to this email directly or view it on GitHub
#3173 (comment).

[BlueRiverInteractive]

This would be awesome! Thanks Mario!

[StanDem]

Any news on that?

[badlogic]

Nope
On Jun 30, 2015 11:28 AM, "StanDem" notifications@github.com wrote:

Any news on that?

—
Reply to this email directly or view it on GitHub
#3173 (comment).

[dsaltares]

A few concerns:

• We need to be careful about the licensing terms.
• A lot of games use ogg as audio format, replacing the backend would force people to re-export/convert all ogg audio files. A flag sounds good but it may bloat the final package.
• The source is on GitHub, is ogg support something they or we can add? How do they deal with collaborators?
• Would making this backend an extension mean that the audio API for those who use the extension would be different? I wouldn't want to have 2 audio APIS, the built-in one and the extension one. I'd rather go for one or the other.
• mp3 and aac are subject to licensing fees, ogg isn't and wav sizes are too high. I'm no expert on audio formats nor licenses but it seems that abandoning ogg would leave Libgdx with no real alternative for lossy, high compression open audio format support. Am I missing something obvious here?

Let's keep Libgdx as open source friendly as possible!

[badlogic]

On Jun 30, 2015 12:31 PM, "David Saltares" notifications@github.com wrote:

A few concerns:

We need to be careful about the licensing terms.

Agreed, they are in our favor though, and we'll always have the default
impl as a fallback.

A lot of games use ogg as audio format, replacing the backend would force
people to re-export/convert all ogg audio files. A flag sounds good but it
may bloat the final package.

I do not think this is a concern if this is an extension.

The source is on GitHub, is ogg support something they or we can add? How
do they deal with collaborators?

Yes, we should be able to add this via the integer vorbis decoder by Xiph.

Would making this backend an extension mean that the audio API for those
who use the extension would be different? I wouldn't want to have 2 audio
APIS, the built-in one and the extension one. I'd rather go for one or the
other.

No, the API stays the same. Think switching out Gdx.sound.

mp3 and aac are subject to licensing fees, ogg isn't and wav sizes are
too high. I'm no expert on audio formats nor licenses but it seems that
abandoning ogg would leave Libgdx with no real alternative for lossy, high
compression open audio format support. Am I missing something obvious here?

We already have this 'problem' with the default implementation.

Let's keep Libgdx as open source friendly as possible!

Word

[dsaltares]

As long as we make it an extension and support an open audio format with high compression rates in all platforms I am sold.

[MobiDevelop]

As for licensing, people using the library are required to put somewhere conspicuous in their app "Audio by Superpowered" with their logo and link to their site, as well as put the same in their product listing in app stores... Which we'll want to make clear to users as this sort of thing is not required by libgdx itself.

[dsaltares]

In that case, I would vote for never making it part of core Libgdx but an
extension. One of the cool things of Libgdx is the freedom with which
people can use it, no logos and no bs like Unity, for instance.

Now the problem is, do we want to maintain the original core audio backends
PLUS this new extension?

On 1 July 2015 at 00:37, Justin Shapcott notifications@github.com wrote:

As for licensing, people using the library are required to put somewhere
conspicuous in their app "Audio by Superpowered" with their logo and link
to their site, as well as put the same in their product listing in app
stores... Which we'll want to make clear to users as this sort of thing is
not required by libgdx itself.

—
Reply to this email directly or view it on GitHub
#3173 (comment).

David Saltares Márquez

Software Developer
http://saltares.com

[MobiDevelop]

Of course we have to maintain the original core audio backends if this is an extension, otherwise it wouldn't make sense as an extension.

[dsaltares]

I know, but there was also the discussion of eventually making it part of the core. If it forces you to place their logo in the game, we can never make it the only sound backend for Android and iOS.

[badlogic]

We won't, it will stay an extension.
On Jul 1, 2015 4:30 PM, "David Saltares" notifications@github.com wrote:

I know, but there was also the discussion of eventually making it part of
the core. If it forces you to place their logo in the game, we can never
make it the only sound backend for Android and iOS.

—
Reply to this email directly or view it on GitHub
#3173 (comment).

[mttkay]

Built-in Pitch-Shifting

Want!

One of the first ideas I ever had for an Android app was to build an audio player where you could pitch shift with gestures :-P Just that there was no pitch shifting API. This would be great for games too (Braid anyone?)

[madpew]

Regarding Built-in Pitch shifting, isn't that already possible by setting the pitch of your sounds? I remember using short looped sounds + updating pitch to do engine-sounds with libgdx a while ago.

[mttkay]

It might be. Last time I checked was like 5 years ago.

On Sun, Aug 23, 2015 at 9:18 PM madpew notifications@github.com wrote:

Regarding Built-in Pitch shifting, isn't that already possible by setting
the pitch of your sounds? I remember using short looped sounds + updating
pitch to do engine-sounds with libgdx a while ago.

—
Reply to this email directly or view it on GitHub.

[milos1290]

Ok here are my experiences with Superpowered SDK.

I'm using cocos2d-x currently and i got tired of all platform specific Audio problems. So i've checked out Superpowered SDK and started digging. I must say it works really good, gapless loops, low CPU and memory usage on all platforms, fast. I've made a wrapper around SDK for iOS/OSX/Android, with caching, pitching and all other needed features for a "normal" not music oriented game, but of course its not without problems.

First of all i had problems with not stopping some of the mp3 files as well as other formats except WAV (WAV was always working flawlessly, but size is the biggest problem so i had to look for another solution). I've contacted authors of Superpowered SDK and they've told me to use AAC format, and i did, but the thing is it must be .aac (not m4a or any other), at first it was working good, but some of the small sounds couldn't be played, and i was getting File too small errors, so i had to switch some of the files to .wav (good thing is they are really small like 20-30kb). Also implementation for iOS and OSX is straightforward, but for Android i had to dig in with native asset manager to get needed sounds from assets directory, so a bit more to implement but its worth it (its all in c++ so i didn't have to make jni calls, except for apk path).

Overall as i said, it works really great, only thing that i'm concern is that some of the files couldn't be played due to small size or just failed to read file (this happens on Android if using .m4a) or EOF was not called, so there is no way to know when sound is finished playing.

Conclusion, keep it as extension for now.

[serhii-k]

Hi @milos1290, did you have to copy an audio file from the assets folder to a temporary place to get the access to it from Superpowered? Or have you found a solution without doing so?
Please, share your thoughts.
As far as I can understand, SP needs the full system path in its API calls (in SuperpoweredAdvancedAudioPlayer.open() and SuperpoweredDecoder.open()).
But I don't have any competence in JNI...

[milos1290]

No, you can read it directly from assets folder. There is native asset manager in ndk that can provide you with asset start position and length to read from.

[serhii-k]

Oh, wow. Thank you very much @milos1290 !

For someone who may need this in the future:
AAsset* asset = AAssetManager_open(mgr, filename, AASSET_MODE_STREAMING);
int descriptor = AAsset_openFileDescriptor(asset, &start_index, &file_size);
AAsset_close(asset);

[badlogic]

Not going to happen.

[Guy-kun]

@serhii-k I'm actually that person in the future trying to do this now: do you possibly have a bigger sample for how you managed to pass an asset for superpowered to load? I already have a working setup, just can't handle assets.

In your snippet, what filename are you passing and where is the manager coming from, the app's AssetManager via JNI?
Also, after getting the start index and size, what are you passing as the path to superpowered?

Any help would be appreciated as I'm exactly in the same predicament!

[serhii-k]

Hello @Guy-kun

http://www.megafileupload.com/ak6c/CrossExample.zip

Please, download this as a free user (click on such image two times).

Here are my experiments with Superpowered. It didn't suite my needs, so I decided not to use it that time. So, I can't actually remember what's going on there, I just tested different features of the library. But I remember that this example takes audio files from the assets instead of the app resources.

I hope it helps you.

[Guy-kun]

Thanks so much @serhii-k that helped a lot, after another day of tinkering I finally got it to work

To save someone time in the future, in the end this is as simple as calling

AAssetManager *mgr = AAssetManager_fromJava(localEnv, javaAssetManager);
AAsset* asset = AAssetManager_open(mgr, path, AASSET_MODE_STREAMING);
off_t start_index, file_size;
int descriptor = AAsset_openFileDescriptor(asset, &start_index, &file_size);
AAsset_close(asset);

player->open(apkPath,start_index,file_size);

and making sure to pass javaAssetManager through the JNI call retrieved from the activity using getContext().getAssets() as well as the apk path as provided by getPackageResourcePath()

Thanks again!

[serhii-k]

You are welcome @Guy-kun! :)

[jtrunick]

I'd appreciate any code that has been done on this!

[serhii-k]

CrossExample.zip

There are several good examples inside their SDK. These are just random changes to one of them.