Hey Rob, can you give us approximate time on when this will be ready?
You can test new audio apis right now in latest daily builds. To test them insert this as first line of main.lua:
al = nil; if audio2 then audio=audio2; print("=====\>\> Using audio2 \<\<=====") end
I highly recommend to test your apps severely (sound especially) before submitting to Google Play. I you do, please, post your results here or in Slack. Changes only affect Android. Everything else is unchanged.
Thanks for the update!
The new Android audio apis seem promising. The Android audio lag is gone or not noticeable.
However, some sounds are not playing that worked before. I noticed some of these sounds dropped in the simulator as well. I’ll test more to see if I can determine why.
NOTE: Would it be helpful to provide you with a debug APK? I can provide one if you think it will help to resolve these issues and improve Android performance.
Hey, [member=‘rogkem’]. Thanks for checking it out! Yes, we are not using OpenAL for Android audio in new audio system, and using modern “low latency” android apis. We are actively working on it, so please, feel free to download very latest daily build and see if your issues was resolved. If they are not, I would appreciate if you could send me a test project to see what is going on. If you do, we would treat it with respect. PM for details.
P.S. Because we moved away from OpenAL, al.* apis are not working anymore. We may release OpenAL plugin separately in the future.
Hey vlads, what’s the ETA on a release date or beta for audio2?
It is in “beta” right now, and works pretty well for simple scenarios. To turn it on get latest daily build and add
al = nil; if audio2 then audio=audio2; print("=====\>\> Using audio2 \<\<=====") end
as the first line of main.lua.
Please note, this is temporary. audio2 will only be true on Android devices. This change doesn’t affect other platforms. You should not use “audio2” as a stand alone API.
Because this is in beta, you should throughly test your app to make sure sounds are working. Beta software is not intended for distribution, but for you to try it and look for bugs that we can address before making it public.
Rob
Guys, also I have this bug on my list, and in this moment working on new update,
can you please tell me which daily build I need for this fix? which you work with?
and does it seem safe to push this change to released App?
Btw, I see many html5 changes, that make me afraid to grab a new version…
and last question, what targetSdkVersion is recommended?
please help me , will be long night for me :(
Many thanks
It looks like the latest version with any Android audio fixes is 3249. HTML5 builds shouldn’t have any affect on Android builds, it’s a separate output channel. As always with daily builds, you should throughly test your app before you release with it.
Android audio changes are still in beta. They also need to be heavily tested in your app to make sure it’s behaving the way you want. Also I don’t know any one who has released with the new Android audio and while it will almost certainly address the OpenAL crashes, it doesn’t mean there won’t be other issues revealed until it gets on customer devices.
As far as targetSDKVersion we are still targeting 26 I think.
Rob
Does it mean we need to change all our app’s audio calls to something else in future with this audio2 API, or is it automatically used from build 3249 onwards? I have hundreds of audio calls in my game that will drive me nuts going through each to change it.
@jacques1, you absolutely should **NOT** change your audio.* calls to audio2. This is a temporary test solution that impact’s Android only builds. Please review this code:
if audio2 then audio=audio2; al = nil; print("=====\>\> Using audio2 \<\<=====") end
If that’s the first line of main.lua (or anytime before you call any audio.* API’s) and you are on a REAL Android device, audio2 will be true and we will map it to audio for you. We also erase any al.* assignments. These are undocumented and definitely not supported on Android. If you use any al.* calls you will need to wrap them.
When we publish this new audio system out of beta into general use, you won’t need to do this mapping, but it also won’t hurt to leave it.
If you build on an older build, audio2 won’t be defined and you will get the older OpenAL behavior on Android.
Keep in mind, even if you use an Android skin in the simulator, the simulator is still not Android and audio2 won’t be defined, but that’s okay, you want to use OpenAL in the simulator.
Rob
I gave this a try, put it at the top of my main.lua and I noticed that some sounds are not playing as well. I’m using daily build 3265.
al = nil; if audio2 then audio=audio2; print("=====>> Using audio2 <<=====") end
Caught a crash in a Pre-launch report:
Looks like a Vungle and audio library conflict???
Vungle engineers probably need to look at this…
04-18 02:08:20.139: D/AudioService(3347): getStreamVolume 3 index 80
04-18 02:08:20.139: D/AudioService(3347): getStreamVolume 3 index 80
04-18 02:08:20.159: E/VungleDevice(16615): error getting available bytes
04-18 02:08:20.179: I/Corona(16615): CheckForAds
04-18 02:08:20.179: I/Corona(16615): CheckForAdsVungle false false
04-18 02:08:20.219: A/google-breakpad(17129): -----BEGIN BREAKPAD MICRODUMP-----
… clipped …
04-18 02:08:20.239: A/google-breakpad(17129): -----END BREAKPAD MICRODUMP-----
04-18 02:08:20.259: W/google-breakpad(16615): ### ### ### ### ### ### ### ### ### ### ### ### ###
04-18 02:08:20.259: W/google-breakpad(16615): Chrome build fingerprint:
04-18 02:08:20.259: W/google-breakpad(16615): 1.63
04-18 02:08:20.259: W/google-breakpad(16615): 250
04-18 02:08:20.259: W/google-breakpad(16615): a62ada37-657b-4454-8f33-6399db62ca12
04-18 02:08:20.259: W/google-breakpad(16615): ### ### ### ### ### ### ### ### ### ### ### ### ###
04-18 02:08:20.259: A/libc(16615): Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 16934 (VungleAsyncMain)
04-18 02:08:20.279: D/AudioFlinger(3017): mixer(0xee280000) throttle end: throttle time(1)
04-18 02:08:20.289: V/AlarmManager(3347): remove PendingIntent] PendingIntent{db6b8a7: PendingIntentRecord{651c41a com.google.android.gms broadcastIntent}}
04-18 02:08:20.319: D/PackageManager(3347): setEnabledSetting : userId = 0 packageName = com.google.android.gms cmp = com.google.android.gms.locationsharing.service.LocationSharingSettingInjectorService newState = 1 callingPackage = 10021
04-18 02:08:20.329: I/TestSupport(14418): AwaitCommitOperation: uncommitted: FlagOverride(com.google.android.gms.auth_account, , Flag(auth_sig_override_enabled, true, 2, 0), false)
etc.
Engineering is looking into this.
Rob
Thank you. That thread is really about all crashes, we’re looking into this particular case at this moment (very similar crash).
It would be really helpful if you could provide a reproducible case of the crash. Backtraces rarely point to specific problems 
This is OpenAL connected, which means it is related to the sound. Could you try to test your game with sounds enabled, may be sending it to background and back, etc.
In this specific case I can see that crash is coming from doing some sound operations in body of main.lua
This is can be potentially very helpful to pinpoint where crash is coming from.
Basically, I can see from traceback that crash is invoked by something you call directly from main.lua (or subsequent functions). Not timers or events. Do you load/play sounds there or something else sound related? Did you make any related changes?
@vlads: thanks for looking into this.
Near the top of my main.lua, i ‘require’ several modules. One of them has/does sound operations as follows:
. . . . line 7: audio.reserveChannels( 14 ); line 8: audio.setVolume( 0.5 , {channel = 1} ); . . . line 27: bgMusic = audio.loadSound ( "audio/soundTrack.mp3"); . . . .
At the end of my main.lua i ‘goto’ a small scene (kind of a splash screen). That scene lasts for 2 seconds. When that scene triggers the ‘will hide’ event, the following audio code is executed:
bgMusicChannel = audio.play ( bgMusic, { channel=1, loops=-1, onComplete = bgMusicHandler } );
No other audio events occur until a scene or two later where i play various audio files and can switch the ‘bgMusic’ on or off.
Also, regarding reproducing the crash: I can’t. As pointed out by many developers in other posts, the only info i have about this crash I get from the play console. If it weren’t for them (google), i wouldn’t even know this crash existed.
Also, I tried your suggestion regarding sending the app to the background/foreground a few times while various sounds are being played. Guess what? Nothing crashed. Honestly, sometimes i think Google makes this stuff up. 
Thanks! We’ll try this out.
I hope you have better luck in crashing it.