I have this if I run an audio file quickly. I only actually need to repeat about 150-160ms until it starts with this error. This is one short audio file. Its even worse when I have many.
17dTesting Error with clearing buffer from source: Invalid OperationWarning: audio error: Failed to clear buffer from source: Invalid Operation
Warning: audio error: Could not bind data to source: Invalid Operation
What happens when you run the code in the Corona Simulator?
Corona Simulator Windows works exactly as it should and always has (timer now and then out of sync as expected)
Corona Simulator Mac has no errors but I can hear the audio occasionally cut out (more like a slow attack as a little bit of it comes through )
This is all i am doing:
function playSoundBass()
audio.stop(1);audio.play(bassDrum,{channel=1});
end
timer.performWithDelay(140,playSoundBass,-1)
You may be running into a bug in Apple’s OpenAL library.
But that said, if you want the sound to loop, then I recommend that you enable looping as shown below. This tells the platform to loop audio playback automatically which will always work without error.
audio.play(bassDrum, {channel = 1, loop = -1})I dont want to put the audio on a loop - Its a tiny hit sound effect that would end up like a drill or buzz sound . I want it to trigger when I want. It by no means is a loopable sound file.
The timer code was just an example to demonstrate the problem of slightly fast audio triggering. Im not asking much at that speed. You can do it by either sequencer or even manually by clicking on an item quickly like a double click. Something isnt right if I cant do that dont you think? I have made audio apps a few years ago using Corona and never had this problem back then.
I’m just telling you what the difference is on the implementation side on our end. We use the OpenAL library on all platforms, which is an open cross-platform standard for implementing audio much like how OpenGL works. We’ve been using the same version of OpenAL library on Windows and Android because neither Microsoft or Google have there own implementation. But Apple does maintain their own OpenAL library and it changes with OS updates. Sometimes there are bugs in Apple’s implementation that either you or us have to work-around. I don’t like it anymore than you do, but that the only platform differences in audio that I’m aware of. So, bottom line, a work-around needs to be found.
What if after you stopped the audio you played it millisecond later via a timer? Perhaps that’ll give Apple’s audio engine the time it needs to finalize the audio.stop() before letting you play audio again on the same channel.
Or what if instead of doing an audio.stop() in your timer, you just audio.seek() back to the beginning of the sound (set it to zero) and then re-play it? That may be a more efficient way of handling it… on all platforms really.
I’m just trying to think of a solution that’ll help you today. I hope the above helps out.
OKay so found a temporary work around. I changed audio.loadSound to audio.loadStream
Now it SEEMS to have fixed the problem. I SEEM to be able to hammer away with no cut outs. So far.
I would have thought this would have the opposite effect and audio.stream not able to trigger samples quickly.
Must have sent the second you posted that reply 
I will also look at the audio seek an alternative solution in case I get any other problems.
Any idea why audio stream is working but audio sound isnt?
With audio.loadStream(), Corona has more control over how the decoded audio data is handled because our code has to stream the audio data to the audio engine ourselves. The audio.loadSound() involves pushing the entire audio buffer over to the platform’s audio engine for it to manage itself, which typically yields better performance at the cost of memory (ie: we’re not constantly decoding and copying audio data to the audio engine on another thread, which is what streaming involves).
What happens when you run the code in the Corona Simulator?
Corona Simulator Windows works exactly as it should and always has (timer now and then out of sync as expected)
Corona Simulator Mac has no errors but I can hear the audio occasionally cut out (more like a slow attack as a little bit of it comes through )
This is all i am doing:
function playSoundBass()
audio.stop(1);audio.play(bassDrum,{channel=1});
end
timer.performWithDelay(140,playSoundBass,-1)
You may be running into a bug in Apple’s OpenAL library.
But that said, if you want the sound to loop, then I recommend that you enable looping as shown below. This tells the platform to loop audio playback automatically which will always work without error.
audio.play(bassDrum, {channel = 1, loop = -1})I dont want to put the audio on a loop - Its a tiny hit sound effect that would end up like a drill or buzz sound . I want it to trigger when I want. It by no means is a loopable sound file.
The timer code was just an example to demonstrate the problem of slightly fast audio triggering. Im not asking much at that speed. You can do it by either sequencer or even manually by clicking on an item quickly like a double click. Something isnt right if I cant do that dont you think? I have made audio apps a few years ago using Corona and never had this problem back then.
I’m just telling you what the difference is on the implementation side on our end. We use the OpenAL library on all platforms, which is an open cross-platform standard for implementing audio much like how OpenGL works. We’ve been using the same version of OpenAL library on Windows and Android because neither Microsoft or Google have there own implementation. But Apple does maintain their own OpenAL library and it changes with OS updates. Sometimes there are bugs in Apple’s implementation that either you or us have to work-around. I don’t like it anymore than you do, but that the only platform differences in audio that I’m aware of. So, bottom line, a work-around needs to be found.
What if after you stopped the audio you played it millisecond later via a timer? Perhaps that’ll give Apple’s audio engine the time it needs to finalize the audio.stop() before letting you play audio again on the same channel.
Or what if instead of doing an audio.stop() in your timer, you just audio.seek() back to the beginning of the sound (set it to zero) and then re-play it? That may be a more efficient way of handling it… on all platforms really.
I’m just trying to think of a solution that’ll help you today. I hope the above helps out.
OKay so found a temporary work around. I changed audio.loadSound to audio.loadStream
Now it SEEMS to have fixed the problem. I SEEM to be able to hammer away with no cut outs. So far.
I would have thought this would have the opposite effect and audio.stream not able to trigger samples quickly.
Must have sent the second you posted that reply
I will also look at the audio seek an alternative solution in case I get any other problems.
Any idea why audio stream is working but audio sound isnt?
With audio.loadStream(), Corona has more control over how the decoded audio data is handled because our code has to stream the audio data to the audio engine ourselves. The audio.loadSound() involves pushing the entire audio buffer over to the platform’s audio engine for it to manage itself, which typically yields better performance at the cost of memory (ie: we’re not constantly decoding and copying audio data to the audio engine on another thread, which is what streaming involves).