Confusion with Corona's loadSound() function and OGGs - the recommended Android sound format.

Solar2D General Questions/Discussion
#1

Just thought we’d let people know about this issue we have come across. Corona ARE aware of it but in the meantime we thought it best to warn anyone who is stuck with the same problem.

We were struggling with Open AL errors which we initially attributed to the fact that we were altering the pitch of the sounds using al.pitch. However we then made a test app which would load our sound files one at a time in increasing size order.

With mp3, caf and wav all of the sounds loaded. With ogg our devices failed to load:

NOOK Color: ogg 15 = 81kb (720kb uncompressed)
HTC Desire HD: ogg 19 = 100kb (941kb uncompressed)
Nexus 7: ogg 23 = 127kb (1425kb uncompressed)
HTC Sensation: ogg 24 = 210kb (1560kb uncompressed)

None of these files are particularly big (in fact they are quite small), yet every other audio type managed to load files up to the largest size (18.3mb uncompressed).

As our sounds need to loop seemlessly, using either loadStream() or .mp3 files is not suitable, and .wav files make the overall app size far too big.

Another post has identified problems using oggs on Nook Color: http://developer.coronalabs.com/forum/2012/10/06/nook-color-sound-doesnt-work
but it appears to affect all Android devices that we have tested on.

Can anyone else confirm that they have had issues using loadSound() for oggs, or share any fixes that they may have found?
[import]uid: 84115 topic_id: 32292 reply_id: 332292[/import]

#2

Please do not spread mis-information about your problem. loadSound DOES support Ogg on Android. Your problem is you are loading long/huge files (over a minute long) with the API and the devices you specified are running out of memory.

As I tried to explain to you directly, all audio must be fully decompressed into raw PCM so the fact that your Ogg files are hundreds of kilobytes doesn’t represent that they are really 20MB in RAM size. That is a lot of memory because Android has other processes and also has the overhead of the Java VM.

For your specific problem, since you don’t have this problem for mp3 or wav, it looks like there may be some inefficiency or bug in the Ogg Tremor decoder which in turn also might be cascaded to ALmixer. I haven’t had a chance to examine this code in more detail. And I told you that you have multiple workarounds/solutions:

  • Use mp3
  • Use wav
  • Lower the sampling rate to 22kHz or 11kHz. Your files are at 44kHz which will negatively affect RAM, performance, and latency.
  • Remember you have to use mono sounds for pitch shifting. (Mono cuts the size by half.)
  • Remember that for seamless looping, packetized formats like MP3 and Ogg are not reliable anyway.
  • Try using a different Ogg encoder or different bitrate. As I said directly to you, my suspicion is that the metadata in the Ogg is misreporting the duration of the file which is causing ALmixer to create the wrong size buffer which results in some painful memory copies which may be where memory is blowing up for you because your files are so huge.

And if all else fails, the entire backend is open source. You can help improve it!
ALmixer:
https://www.assembla.com/code/almixer_isolated/mercurial/nodes
Ogg Tremor:
http://wiki.xiph.org/Tremor

One thing I would like is a native OpenSL ES decoder backend which could possibly sidestep these issues and also finally give AAC/MP4 support for Android.
[import]uid: 7563 topic_id: 32292 reply_id: 128460[/import]

#3

Hi Eric,

It’s certainly not our intention to spread mis-information, just to let other developers know about this important problem so that they do not spend days looking into it as we have.

As Alan mentioned in his post above, the Nexus 7 fails to load an ogg that is just 127kb and 8.2 seconds long. Are you saying that this is unreasonably large or are you getting different results at your end?

On the same device an 18.3MB uncompressed WAV and the 1.5MB mp3 equivalent load fine. So it appears that the loadSound ogg ‘performance’ is at least a factor of 10 poorer than other formats. This is why we referred to it as “not working”. I do not think that this is an unfair comment.

Regarding your points:

  • mp3: we’re currently using this but due to the increased padding at the end of the files we get a LOT of audible pops when the sounds loop. It sounds nasty.
  • wav: our audio app requires a lot of high quality sounds. ogg files = 14.2MB; mp3 files = 11.7MB; wav = 131MB.
  • lower sampling rate: it’s an audio app. Sound quality is everything. It should also match the 44kHz iOS version.
  • mono: both the .caf iOS version and mp3 Android version both use stereo sounds and pitch shifting successfully. Brilliant! We <3 Corona.
  • packetised formats: this is our understanding too but we are assured that oggs suffer much less from this than mp3. Hopefully as little as the great sounding aac cafs on iOS.
  • our sound guy has tried multiple methods of ogg compression and I have tried Audacity also. Please feel free to recommend something though and we will try it.

Ultimately, we need to release an Android version of Finger Hoola that matches the high quality of its iOS sibling.

I’m afraid neither our bandwidth nor low-level coding skills are sufficient to start modifying AL Mixer or Ogg Tremor - part of the reason we’re using Corona in the first place. We hope that the simple app we built for you to demonstrate the problem can still help.

We do appreciate the support but we also believe that this is an important Corona issue that affects more than just us and we wanted to make sure people are aware of it.

Best,
Ian [import]uid: 29093 topic_id: 32292 reply_id: 128478[/import]

#4

Updated title of thread so as to not spread inaccurate information. [import]uid: 52491 topic_id: 32292 reply_id: 128488[/import]

#5

Out of curiosity I extended the test further on the Nexus 7 and again it successfully loaded the largest file, now a 53.8MB wav that is 5:20 long. The equivalent 4.04MB mp3 also loaded fine. [import]uid: 29093 topic_id: 32292 reply_id: 128506[/import]

#6

Please do not spread mis-information about your problem. loadSound DOES support Ogg on Android. Your problem is you are loading long/huge files (over a minute long) with the API and the devices you specified are running out of memory.

As I tried to explain to you directly, all audio must be fully decompressed into raw PCM so the fact that your Ogg files are hundreds of kilobytes doesn’t represent that they are really 20MB in RAM size. That is a lot of memory because Android has other processes and also has the overhead of the Java VM.

For your specific problem, since you don’t have this problem for mp3 or wav, it looks like there may be some inefficiency or bug in the Ogg Tremor decoder which in turn also might be cascaded to ALmixer. I haven’t had a chance to examine this code in more detail. And I told you that you have multiple workarounds/solutions:

  • Use mp3
  • Use wav
  • Lower the sampling rate to 22kHz or 11kHz. Your files are at 44kHz which will negatively affect RAM, performance, and latency.
  • Remember you have to use mono sounds for pitch shifting. (Mono cuts the size by half.)
  • Remember that for seamless looping, packetized formats like MP3 and Ogg are not reliable anyway.
  • Try using a different Ogg encoder or different bitrate. As I said directly to you, my suspicion is that the metadata in the Ogg is misreporting the duration of the file which is causing ALmixer to create the wrong size buffer which results in some painful memory copies which may be where memory is blowing up for you because your files are so huge.

And if all else fails, the entire backend is open source. You can help improve it!
ALmixer:
https://www.assembla.com/code/almixer_isolated/mercurial/nodes
Ogg Tremor:
http://wiki.xiph.org/Tremor

One thing I would like is a native OpenSL ES decoder backend which could possibly sidestep these issues and also finally give AAC/MP4 support for Android.
[import]uid: 7563 topic_id: 32292 reply_id: 128460[/import]

#7

Hi Eric,

It’s certainly not our intention to spread mis-information, just to let other developers know about this important problem so that they do not spend days looking into it as we have.

As Alan mentioned in his post above, the Nexus 7 fails to load an ogg that is just 127kb and 8.2 seconds long. Are you saying that this is unreasonably large or are you getting different results at your end?

On the same device an 18.3MB uncompressed WAV and the 1.5MB mp3 equivalent load fine. So it appears that the loadSound ogg ‘performance’ is at least a factor of 10 poorer than other formats. This is why we referred to it as “not working”. I do not think that this is an unfair comment.

Regarding your points:

  • mp3: we’re currently using this but due to the increased padding at the end of the files we get a LOT of audible pops when the sounds loop. It sounds nasty.
  • wav: our audio app requires a lot of high quality sounds. ogg files = 14.2MB; mp3 files = 11.7MB; wav = 131MB.
  • lower sampling rate: it’s an audio app. Sound quality is everything. It should also match the 44kHz iOS version.
  • mono: both the .caf iOS version and mp3 Android version both use stereo sounds and pitch shifting successfully. Brilliant! We <3 Corona.
  • packetised formats: this is our understanding too but we are assured that oggs suffer much less from this than mp3. Hopefully as little as the great sounding aac cafs on iOS.
  • our sound guy has tried multiple methods of ogg compression and I have tried Audacity also. Please feel free to recommend something though and we will try it.

Ultimately, we need to release an Android version of Finger Hoola that matches the high quality of its iOS sibling.

I’m afraid neither our bandwidth nor low-level coding skills are sufficient to start modifying AL Mixer or Ogg Tremor - part of the reason we’re using Corona in the first place. We hope that the simple app we built for you to demonstrate the problem can still help.

We do appreciate the support but we also believe that this is an important Corona issue that affects more than just us and we wanted to make sure people are aware of it.

Best,
Ian [import]uid: 29093 topic_id: 32292 reply_id: 128478[/import]

#8

Updated title of thread so as to not spread inaccurate information. [import]uid: 52491 topic_id: 32292 reply_id: 128488[/import]

#9

Out of curiosity I extended the test further on the Nexus 7 and again it successfully loaded the largest file, now a 53.8MB wav that is 5:20 long. The equivalent 4.04MB mp3 also loaded fine. [import]uid: 29093 topic_id: 32292 reply_id: 128506[/import]

#10

I just committed a fix in the OggTremor/SoundDecoder interface which I think will resolve this problem. It will appear in the next daily build.
[import]uid: 7563 topic_id: 32292 reply_id: 128707[/import]

#11

That’s brilliant Eric! It will be a HUGE relief to have a working Android version. Can’t wait to test it out :-).

Many Thanks,
Ian [import]uid: 29093 topic_id: 32292 reply_id: 128710[/import]

#12

I just committed a fix in the OggTremor/SoundDecoder interface which I think will resolve this problem. It will appear in the next daily build.
[import]uid: 7563 topic_id: 32292 reply_id: 128707[/import]

#13

That’s brilliant Eric! It will be a HUGE relief to have a working Android version. Can’t wait to test it out :-).

Many Thanks,
Ian [import]uid: 29093 topic_id: 32292 reply_id: 128710[/import]