OpenAL sound BUG (trying to stop first sound and immediately play a second one)?

Solar2D General Questions/Discussion
1

Hi,

In my game I need to:

  1. play sound 1
  2. wait
  3. stop sound 1
  4. play sound 2 (immediately)

I’ve implemented it using the old API and everything used to work just find.
Today I’ve tried to migrate it to the new OpenAL API, and I found out that the second sound is not being played every time…

I saw that both sounds use the same channel (makes sense since that channel is free after stopping the first sound).
Is it possible that there is a race condition between the stop and play methods which causes this problem?

Here is a sample code which demonstrates the problem:

  1. load 2 sounds
  2. wait for 2 seconds, and play the first sound
  3. wait for another 0.5 second
  4. stop the first sound and immediately play the second sound

When I test it with 2 sounds (the first one should last more than 0.5 second) I get that the second sound is not being played every time…

[code]
– load sounds
– sound1 length = ~4 seconds
local snd1_snd = audio.loadSound( “sound1.caf” )
– sound1 length = ~0.5 second
local snd2_snd = audio.loadSound( “sound2.caf” )
local snd1_cnl = -1
local snd2_cnl = -1

local function timer2Cb( evt )

– stop sound1
print( "stop channel " … snd1_cnl )
audio.stop( snd1_cnl )
if ( true == audio.isChannelActive( snd1_cnl ) ) then
print( “channel " … snd1_cnl … " is still active…” )
end

– play sound2
local free_cnl = audio.findFreeChannel()
snd2_cnl = audio.play( snd2_snd, { channel = free_cnl } )
print( "play sound2, snd2_cnl = " … snd2_cnl )

end

local function timer1Cb( evt )

– play sound1
snd1_cnl = audio.play( snd1_snd )
print( “----------” )
print( "play sound1, snd1_cnl = " … snd1_cnl )

– stop sound1 in 1 second
timer.performWithDelay( 500, timer2Cb)

end

– play sounds in delay
timer.performWithDelay( 2000, timer1Cb, 0 )
[/code] [import]uid: 9536 topic_id: 4337 reply_id: 304337[/import]

2

We reproduced this bug and filed bug 2510 to track this.

This problem seems to be very similar to this Apple bug reported here at OpenRadar:
http://openradar.appspot.com/radar?id=807401

My theory is there is a race condition deep inside Apple’s implementation which is causing this. Unfortunately if that’s true, that means we can’t really do anything to fix this and must wait for Apple.

A possible workaround is to tell findFreeChannel() to start looking for a free channel at snd1_cnl+1, e.g:

local free_cnl = audio.findFreeChannel(snd1_cnl+1)
However, I encourage you to file a bug with Apple at
https://bugreport.apple.com

For now, you can simply refer to the bug at OpenRadar and provide any specific information about your app. Your bug will be marked as a duplicate, but this "votes’ for a bug and gives them additional information. After, I get more time to poke at this, I’ll file a new more specific bug and will ask you to file a new bug to reference that one as well.

I encourage anybody else affected by this bug to do the same and file a bug with Apple. This is the procedure we need to follow to get them to fix their bugs.
[import]uid: 7563 topic_id: 4337 reply_id: 14800[/import]

3

Thanks ewing, for your update,

Since I don’t use Apple’s SDK directly, I don’t feel free to file a bug at OpenRadar…

Thank you for the workaround, I guess I’ll use it (or another).

Hoping to see this bug fixed soon,
EZ [import]uid: 9536 topic_id: 4337 reply_id: 15012[/import]

4

For the record, I filed bug 8857655 at Apple’s Bug Reporter which references the other bug I mentioned on Open Radar. I do encourage everybody to file a bug on Apple’s Radar referencing 8857655. You don’t have to say much except that you are affected by this bug. [import]uid: 7563 topic_id: 4337 reply_id: 16353[/import]