audio.loadStream()

[burnsj002]

audio.loadStream() has horrendous latency on some older devices. Like the iPad mini, iPhone 5. Which is death during gameplay. It seems to get better after the APP runs for five minutes. What’s the best way to handle this?

I currently load 6  background music .wav files with audio.loadStream() at the beginning of the app before the main menu. 

I was thinking would it be better just to load only one background music with audio.loadSound() at a time. Only have one in memory when it’s playing? What’s the best practice of doing this?

Thanks!

[roaminggamer]

I would only preload the one I’m about to play.

I’m intrigued by the problem you say you are encountering and if you have a simple testbench that demonstrates this lag issue I think it would be super cool for you to post a link here to let other experts take a peek and maybe suggest changes.

What format is the sound file(s)? 

[burnsj002]

Here is a video I captured of the problem. I used Refector 3. The video is not lagging in anyway – this is how the sound is captured exactly on the iPhone 5. At the beginning the video goes black for a split second  and freezes at then end(this is not part of the iPhone 5 , it’s Reflector 3 recording…

But the sound is captured exactly what happens on the iPhone 5 listen to the entire video – the sound stops for almost 30 seconds!

https://www.dropbox.com/s/4m7393avkr7uanc/Loadsound_choppy.mp4?dl=0

[roaminggamer]

Sorry,  I need to see a project to help.  i.e. Code and an example that demonstrates the problem.  The basic parts of this are:

• main.lua - just the code needed to demonstrate the issue.
• config.lua - Basic settings 
• build.settings - Optional unless there is a setting required to for demonstrating the issue when building for a device.

Then I and others can look at the code and give proper feedback.  Anything other than that and I’d just be guessing.

Note: If the problem is only exposed when using composer.* then you’ll need to make a simple sample scene(s) that demonstrate the issue.  However, please keep the example (overall) as slim and simple as possible.  I don’t favor digging through unrelated code to help debug.

PS - By the way, I’m not asking for this to be a pain.  Making sample test benches is a standard method used by all coding pros to debug an issue.  Often times, when you go through the trouble to make a clean and simple testbench, the source of the issue becomes clear and you essentially self-solve.  In any case, this is useful for us (those who help) and later if you need to file a bug.

[anon63346430]

**audio.loadStream() **should be considered as preloading of a sound file not the start of playing it.  As with all large audio (and video) files the buffer has to filled first before it can actually start playing.

What I do is buffer audio streams as my game is loading and then when my scene is ready I will start playing the stream.  This way it is “lag free”.

As rg points out, a 30s delay is most likely code related rather than anything to do with the audio API.

[burnsj002]

Yeah, It’s my code.

Is it okay not to use audio.loadStream()  at all in a game?

I just load all the Sound FX at the beginning of the app. Then I load the background music one at a time as I need it with audio.loadSound().  It works great now:)

[rob]

@burnsj002, you need to separate the concept of “loading” and “playing”.  Loading gets the sound in memory.  Sound files can be large depending on stereo vs. mono, sample rates, and other features. 

Let’s say for example a short sound like a weapon firing sound or a beep takes a second to load with audio.loadSound(), it will likely take a second to open with audio.loadStream() as well. But a 5-minute background track may take 30 seconds to load (I’m making up times just to use as an example, and are not realistic times). You don’t want your app to stop doing anything for 30 seconds if you use audio.loadSound(), but your app will continue without delay if you use audio.loadStream().  In either case, doing:

audio.load???()

audio.play()

back to back may have a noticeable lag because it takes time to open the audio file, and load in enough (in the case of loadStream() or the whole file in the case of loadSound()) to be able to start playback.

Preloading your short sounds before you need them is a best practice. Using audio.loadStream() on your soundtracks is the best practice and a brief delay there shouldn’t be an issue.

Rob

[burnsj002]

I figured out I made two mistakes.

 audioPlayFrequency = 22050

The wav. file I was playing was 48000  (Hz)

I changed the audioPlayFrequency = 44100

I changed the .wav file to  44100 (Hz)

It works perfect now:)

[roaminggamer]

Some devices don’t support 22K, 11K, etc.  That’s a tricky one.

Glad you got it worked out.

[roaminggamer]

I would only preload the one I’m about to play.

I’m intrigued by the problem you say you are encountering and if you have a simple testbench that demonstrates this lag issue I think it would be super cool for you to post a link here to let other experts take a peek and maybe suggest changes.

What format is the sound file(s)? 

[burnsj002]

Here is a video I captured of the problem. I used Refector 3. The video is not lagging in anyway – this is how the sound is captured exactly on the iPhone 5. At the beginning the video goes black for a split second  and freezes at then end(this is not part of the iPhone 5 , it’s Reflector 3 recording…

But the sound is captured exactly what happens on the iPhone 5 listen to the entire video – the sound stops for almost 30 seconds!

https://www.dropbox.com/s/4m7393avkr7uanc/Loadsound_choppy.mp4?dl=0

[roaminggamer]

Sorry,  I need to see a project to help.  i.e. Code and an example that demonstrates the problem.  The basic parts of this are:

• main.lua - just the code needed to demonstrate the issue.
• config.lua - Basic settings 
• build.settings - Optional unless there is a setting required to for demonstrating the issue when building for a device.

Then I and others can look at the code and give proper feedback.  Anything other than that and I’d just be guessing.

Note: If the problem is only exposed when using composer.* then you’ll need to make a simple sample scene(s) that demonstrate the issue.  However, please keep the example (overall) as slim and simple as possible.  I don’t favor digging through unrelated code to help debug.

PS - By the way, I’m not asking for this to be a pain.  Making sample test benches is a standard method used by all coding pros to debug an issue.  Often times, when you go through the trouble to make a clean and simple testbench, the source of the issue becomes clear and you essentially self-solve.  In any case, this is useful for us (those who help) and later if you need to file a bug.

[anon63346430]

**audio.loadStream() **should be considered as preloading of a sound file not the start of playing it.  As with all large audio (and video) files the buffer has to filled first before it can actually start playing.

What I do is buffer audio streams as my game is loading and then when my scene is ready I will start playing the stream.  This way it is “lag free”.

As rg points out, a 30s delay is most likely code related rather than anything to do with the audio API.

[burnsj002]

Yeah, It’s my code.

Is it okay not to use audio.loadStream()  at all in a game?

I just load all the Sound FX at the beginning of the app. Then I load the background music one at a time as I need it with audio.loadSound().  It works great now:)

[rob]

@burnsj002, you need to separate the concept of “loading” and “playing”.  Loading gets the sound in memory.  Sound files can be large depending on stereo vs. mono, sample rates, and other features. 

Let’s say for example a short sound like a weapon firing sound or a beep takes a second to load with audio.loadSound(), it will likely take a second to open with audio.loadStream() as well. But a 5-minute background track may take 30 seconds to load (I’m making up times just to use as an example, and are not realistic times). You don’t want your app to stop doing anything for 30 seconds if you use audio.loadSound(), but your app will continue without delay if you use audio.loadStream().  In either case, doing:

audio.load???()

audio.play()

back to back may have a noticeable lag because it takes time to open the audio file, and load in enough (in the case of loadStream() or the whole file in the case of loadSound()) to be able to start playback.

Preloading your short sounds before you need them is a best practice. Using audio.loadStream() on your soundtracks is the best practice and a brief delay there shouldn’t be an issue.

Rob

[burnsj002]

I figured out I made two mistakes.

 audioPlayFrequency = 22050

The wav. file I was playing was 48000  (Hz)

I changed the audioPlayFrequency = 44100

I changed the .wav file to  44100 (Hz)

It works perfect now:)

[roaminggamer]

Some devices don’t support 22K, 11K, etc.  That’s a tricky one.

Glad you got it worked out.