Update on slow audio - Need your help!

Do you have an android device? Can you spare a few minutes? If so, you can help diagnose a problem that significantly slows down loading on android when using chrome or chromium based exporters (Phonegap, Crosswalk).

1. DL the latest chrome for android

2. DL the latest Firefox for android (yes, there's FF for android. It's actually quite good.)

3. Run the following test in both FF and Chrome. http://www.scirra.com/labs/bugs/webaudiodecode/

4. Test both OGG and AAC and note the time taken for each. You should end up with 4 different scores, 2 for each browser.

5. Go to this chrome bug report: https://code.google.com/p/chromium/issu ... ?id=424174

6. Star it.

7. Post your results, along with your device details. Particularly, your cpu information (model, how many cores).

7a. If you don't know about your cpu, use the following app to find out: https://play.google.com/store/apps/deta ... puid.cpu_z

That's it. BTW, while everything helps, scores for single core, hexa(6)-core, and octo(8)-core devices are particularly useful.

currently running the test, however you know there is something really wrong when ashley is thinking about having a javascript decoder for the ogg vorbis sounds to compensate for the chrome slow decoding.

EDIT : posted, 51,79 s on chrome to decode against 12,69 s on firefox, definitively a stupid time to wait when the download time was between 10,03 s and 13,28 s.

since AAC made chrome for android crash once during the decode, I did not insist.

TiAm I just saw that my phone is actually using 1 cpu I think, so testing on it may be useful perhaps?

EDIT:reported it on the chromium bug report

I tested it with a Samsung Galaxy Core Plus.

CPU: Dual-core 1,2 GHz ARM Cortex-A9

Decode times:

Firefox (OGG): 10.4s

Firefox (M4A): Before I updated Firefox, it did it in 20.38s, after the update it just crashes.

Chrome (OGG): 35.14s

Chrome (M4A): 26.55s

Aphrodite

Yes, thanks for testing the phone too. That's an interesting result; it shows that chrome is decoding slower period, even when the number of cores is only one (so threading wouldn't matter). Unfortunately, it seems like chrome is particularly slow at decoding ogg.

glerikud

Thanks for testing. Can you post those result on the bug report too? It helps to reiterate to the chrome devs that this speed discrepancy can be replicated on many different devices.

Can you post those result on the bug report too?

Of course.

asm.js has been proven to reach close-to-native speeds, and puts control of audio decoding in our hands (e.g. we can run it over multiple threads with web workers, instead of hoping the browser does that). It would have other benefits like allowing platforms that don't support Ogg Vorbis but support Web Audio (Safari, soon IE) to use the Ogg Vorbis files for sound effects. So it's something I'm interested in looking in to even if this bug gets fixed. And if it doesn't, then we can work around it ourselves too.

asm.js has been proven to reach close-to-native speeds, and puts control of audio decoding in our hands (e.g. we can run it over multiple threads with web workers, instead of hoping the browser does that). It would have other benefits like allowing platforms that don't support Ogg Vorbis but support Web Audio (Safari, soon IE) to use the Ogg Vorbis files for sound effects. So it's something I'm interested in looking in to even if this bug gets fixed. And if it doesn't, then we can work around it ourselves too.

That sounds awesome, especially since it would let us use open formats on Safari and IE.

Since you are willing to consider this, have you looked at opus at all? I don't think it's that much slower than ogg, but it allows for some hefty reductions in bitrate, especially for vocal content (nearly transparent at 32kbps).

http://en.wikipedia.org/wiki/Opus_%28audio_format%29

Ashley it just feels weird to me that implementing a decoder with javascript (even asm.js) can outperform a direct browser implementation, however, for the sake of only using one audio format, I agree (well, we still will need m4a for when the web audio api is not supported nor the chosen format).

All existing C2 content already has Ogg Vorbis audio. Switching format to something like Opus would be tricky because everyone would have to re-encode/transcode their audio files.

All existing C2 content already has Ogg Vorbis audio. Switching format to something like Opus would be tricky because everyone would have to re-encode/transcode their audio files.

That's true. I hadn't considered that. Trans-coding low bitrate files = bad.

Vorbis is still a great codec too. If this idea works out, and we can use ogg everywhere, and get faster decoding on android...I'll be happy.

I've heard good things about Opus (pun intended?) and it seems the most likely candidate for the one format that plays everywhere somewhere in the distant future, so I hope we can move to it eventually... but right now adding a third format in to the mix doesn't add much!

Ashley

Over on the chromium bug report for this issue, rtoy brought up the following issue:

[quote:3ps4qm9u]One additional item that can cause slow decoding. If the sample rate of the encoded audio files does not match the sample rate of the AudioContext, the audio file is resampled to the sample rate of the context. A high quality sinc resampler is used for this and can consume quite a bit of CPU.

So for those who reported slow decoding using the example URL, it would be good to know what the context sample rate was. (You can go to http://rtoy.github.io/webaudio-hacks/tests/osc.html which plays a tone and also displays the context sample rate.)

Could you work up a new version of the audio decoding test with 44.1khz and 48khz samples, so that test takers can eval both?

Any updates on this? Will this be fixed soon?

How do other games/apps deal with it (the ones that are not made in C2)? Why do they load almost instantly (e.g. Red Ball 4)?

Any updates on this? Will this be fixed soon?

How do other games/apps deal with it (the ones that are not made in C2)? Why do they load almost instantly (e.g. Red Ball 4)?

Not as far as I know. One of two major issues with audio in C2, the other being that we have no good way of manually clearing decoded audio out of memory, which can lead to a big pileup of decoded audio in ram (which doesn't always empty at the most opportune times).

(which doesn't always empty at the most opportune times).

are you saying it does empty at some point? I thought all audio stayed loaded throughout the game.