I’m surprised you can notice a difference. To make sure, you are using audio.loadSound() and not audio.loadStream(), correct? loadStream has much higher start up latency.
[import]uid: 7563 topic_id: 13409 reply_id: 62579[/import]
@ewing: to be clear ewing, we ONLY use loadStream() on large music files, otherwise we’re loadSound() for our SFX mp3s. We take the hit for preloads on the loadSound() but the loadStream() we’ve just not been having good luck; specifically we cannot get audio.rewind() or audio.seek() to work on streamed audio.
But back to the issue in this thread; when attempting to fire off an mp3 that is brought into ram via loadSound() and specifying a channel, there is a delay. A significant delay. It’s obvious because we’re using timer.performWithDelay(1000ms, audio.play(), 60) where the sound is a 1s tic-tock of a clock. [import]uid: 74844 topic_id: 13409 reply_id: 62616[/import]
Very odd about the lag. If you look at the ALmixer source code, you’ll see that that there isn’t a whole lot of difference between auto-assignment and manual assignment. In fact, manual assignment should actually be slightly faster. There is a little overhead in calling stop, but I don’t think it should be significant.
Do you see the same performance lag between iOS, Mac, Android, and Windows? The code is the same for all platforms in this case. The only difference is the underlying OpenAL implementation.
If you see the problem on iOS and not Mac, then this might be an Apple performance bug, in which case you should file a performance bug with Apple.
But also be warned that timer.performWithDelay isn’t necessarily a high performance clock. It is possible the audio system fires quickly, but the timer.performWithDelay is not calling back exactly when you request it.
For seek/rewind, make sure you understand the difference between seeking the channel and the stream. If you call the wrong one, you won’t get what you expect.
But at this point, I think you know more than me, so I will need good bug reports and test cases for both your performance problem and seek/rewind problem. [import]uid: 7563 topic_id: 13409 reply_id: 62620[/import]
@jerome82:
I only use the reserved channels for “long” audio that has been loaded with loadStream (i.e. background music etc). For all sound-effects I just let Corona choose a channel for me.
One thing I’ve noticed is that you can’t rewind an MP3 stream that has been stopped. If you want to rewind it you have to do so immediately before stopping it. I haven’t tried but maybe it’s the same for seeking?
[import]uid: 70847 topic_id: 13409 reply_id: 62624[/import]
>>One thing I’ve noticed is that you can’t rewind an MP3 stream that has been stopped.
Oh, let me try that. I think I had an audio.stop() from previous code so I just left it there… Also I just checked because I thought the API specified you needed to audio.stop(), but after looking at documentation again it DOES NOT say that. So let me verify audio.stop() is not being called. (Although I swear I tried every combination under the sun, but…) Be right back.
EDIT: Solution: Yes, I must have left audio.stop() in my code and this resulted in audio.rewind() NOT working. So thank you for that pointer! I now have the desired behavior and it’s reliable, most excellent. I am very grateful, thank you. [import]uid: 74844 topic_id: 13409 reply_id: 62671[/import]
Great news! Glad it worked. I was pulling my hair out (or what’s left of it) before I happened to try this.
It would be great to be able to rewind a stopped stream though… [import]uid: 70847 topic_id: 13409 reply_id: 62674[/import]
@ewing:
>>Very odd about the lag. If you look at the ALmixer source code,
I will take a look at that ALmixer source code, and if I can put together an example that demonstrates what I’m running into, I will get that to you / submitted.
Ultimately I think the solution is not to worry about prioritizing the SFX because 32 channels REALLY should be enough…but what got me going down this road in the first place was that I was having some SFX not fire, and it was happening when the audio overhead was not heavy, so it was concerning. This felt buggy to me… but it could be game code. SO, I thought I would try dedicated channels to see if that alleviated the issue; plus having a priority scheme for audio seems useful long-term anyway. But if the lag permeates some/all of the channel specification in audio calls, obviously that’s a deal breaker. [import]uid: 74844 topic_id: 13409 reply_id: 62673[/import]
In response to #25 from this thread, I pushed in a new workaround for the iOS 5.0 bug which hopefully resolves the lingering issues described in #25. Please test that. [import]uid: 7563 topic_id: 13409 reply_id: 62818[/import]
Tested and confirmed OK. The issues that I found are now resolved using 2011.645.
Thanks! [import]uid: 70847 topic_id: 13409 reply_id: 62828[/import]
We’ve actually found that all of our apps on the appStore currently that were built with Corona do not have any mp3 music playing anymore after updating to iOS 5 on an iPad device. In other words. Music works fine…upgrade to iOS 5…music stops working. Haven’t tested an iPhone yet but the fear is…they will stop working too.
So if we test locally a fresh update…still no music. Is there a fix? Will this daily build from yesterday solve this MAJOR audio problem? Games with no music and broken apps seem like an urgent matter for a SDK fix. [import]uid: 9492 topic_id: 13409 reply_id: 62937[/import]
Yes…I read that. I understand that existing apps might be broken due to the regression bug. But I ask if the last daily build fixes the issue for updates and new apps…as we are currently unable to play mp3 tracks using the load.stream API. Or do we not have streamed audio support anymore?
I understand that Ansca engineers might be struggling with getting Audio to work effectively…but 1000s of native apps seem to be able to play music okay in iOS 5. Can we? [import]uid: 9492 topic_id: 13409 reply_id: 62941[/import]
It’s not possible for anybody to *guarantee* if your particular app will work or not with the latest daily builds, however I can vouch for my apps.
All the audio issues that I had detected with iOS5 (see #25) have been solved with build 645, and my guess is that most of the apps having problems will work with this build.
The only way to know if *your* apps will work is that you download the latest build and test yourself. You mentioned that you have Corona apps on the appstore which means you have a license. You can go to the Daily Builds and download the latest one and recompile for testing.
[import]uid: 70847 topic_id: 13409 reply_id: 62950[/import]
I am testing this and finding that sound will play through the headphones on iPad 1 but not through the speaker. Are you aware of any differences between them? Should it work through both to your knowledge? [import]uid: 43692 topic_id: 13409 reply_id: 63554[/import]
@paul: are you saying you’re testing builds with 645 on iPad1 and not having audio come out the speaker BUT audio is heard through the headphone port?
I can tell you my app built with 645 running on my iPad1 has audio through the speaker. (BUT, my iPad1 has not been upgraded to iOS 5 just yet.) [import]uid: 74844 topic_id: 13409 reply_id: 63558[/import]
In fact I’ve resolved this now, not an issue. [import]uid: 43692 topic_id: 13409 reply_id: 63567[/import]
More than a year hence and sadly this is still an issue. I got a complaint from a customer and noticed upon checking the absence of sound on my iPad2. And, as stated earlier, there WAS sound using headphones.
When checking external button settings I realised I use the mute switch to lock orientation, which made me suspicious.
And yes: if I set the meaning of that switch to mute/unmute, then set the switch on (i.e. unmuted) and then set it to govern lock orientation again I DO have sound.
That is, even if the switch governs orientation lock and should not influence sound, its earlier muted position still is used by corona to mute sound. An earlier unmuted position produces sound (also when the switch is set to govern orientation lock). [import]uid: 63935 topic_id: 13409 reply_id: 138378[/import]
More than a year hence and sadly this is still an issue. I got a complaint from a customer and noticed upon checking the absence of sound on my iPad2. And, as stated earlier, there WAS sound using headphones.
When checking external button settings I realised I use the mute switch to lock orientation, which made me suspicious.
And yes: if I set the meaning of that switch to mute/unmute, then set the switch on (i.e. unmuted) and then set it to govern lock orientation again I DO have sound.
That is, even if the switch governs orientation lock and should not influence sound, its earlier muted position still is used by corona to mute sound. An earlier unmuted position produces sound (also when the switch is set to govern orientation lock). [import]uid: 63935 topic_id: 13409 reply_id: 138378[/import]