Hang when loading certain .wav files on Mac build

[jgranick]

#214 Issue by jskuse,

I just upgraded to OpenFL 1.4 and found our game started hanging on a black screen at startup. No error, just "application not responding" (this being a Mac build).

I tracked this down to var sound = library.getSound (symbolName); in Assets.getSound, but unfortunately I couldn't trace it beyond that because I couldn't find the implementation of the getSound method that was being used in native builds.

A bit of experimentation indicates that the latest version of OpenFL doesn't seem to like loading the wav files we are using (which were fine in previous versions). These had apparently been prepared in Audacity, but weirdly after running them through Sox (yet not changing anything about the format) OpenFL was happy again.

Here are two versions of an example wav file.
https://dl.dropboxusercontent.com/u/7766300/13-05-07-openfl-wavs-hang.zip

Sox seems to think they're the same format:

Input File     : 'theme.wav'
Channels       : 1
Sample Rate    : 22050
Precision      : 16-bit
Duration       : 00:00:08.00 = 176400 samples ~ 600 CDDA sectors
File Size      : 353k
Bit Rate       : 353k
Sample Encoding: 16-bit Signed Integer PCM

Input File     : 'theme2.wav'
Channels       : 1
Sample Rate    : 22050
Precision      : 16-bit
Duration       : 00:00:08.00 = 176400 samples ~ 600 CDDA sectors
File Size      : 353k
Bit Rate       : 353k
Sample Encoding: 16-bit Signed Integer PCM

But, using the following example, the file "theme.wav" hangs, but with "theme2.wav" all is well:

package;

class Main extends flash.display.Sprite {
    public function new () {
        super ();               
        var sound:flash.media.Sound = openfl.Assets.getSound ("assets/theme.wav");
    }
}

[jgranick]

Comment by jgranick:

This may have been resolved in the latest release, would you mind trying again? Thank you!

[jgranick]

Comment by jgranick:

This may have been resolved in the latest release, would you mind trying again? Thank you!

[jgranick]

Comment by SeanHogan:

This is happening with me for .wav files in the same usage as above. I just ran haxelib upgrade today. It happens for any wav file it looks like. ogg files seem to be okay

Length: 0:02.888
Sample rate: 44100
Channels: 2
Bits/sample: 16 (int)
Total samples: 127,376
Blockalign: 4
Datablock start: 736
BWF chunk:
Originator: REAPER
Date: 2013-05-02
Time: 23-51-23
Start offset: 0:00.000

[jgranick]

Comment by madrazo:

If the wav format is "BWF", I had added a pull request for this. But anyway, it looks like the guys of SDL are adding the fix as well. haxenme/nme-dev#2

[jgranick]

Comment by SeanHogan:

Oh I see, thanks! Should I just get latest nmedev and recompile with that patch?

[jgranick]

Comment by madrazo:

The request has not been added, but you can add them manually. As I remember, you only need to delete the lime/ndll/Windows files and then run "lime rebuild windows" using the modified nmedev

[jgranick]

Comment by SeanHogan:

I 'haxelib install nme-dev' then copied those two files over to the patch directory and updated the Build.xml, removed lime/ndll/Windows , then ran lime rebuild windows. I still get hanging in the same spot. I think I'm just going to go with ogg files for now, should be okay. Thanks!

[jgranick]

Comment by SeanHogan:

I figured out a problem, when exporting with REAPER, I had the option "Allow large files to use Wave64" set. This made the "datablock" start byte go from 44 to 104, which made things choke - maybe that's an issue too?

FWIW, before I updated openfl/etc to the latest, it was working just fine.

Anyways things are okay now.

[jgranick]

Comment by madrazo:

Sorry, i just remembered how to recompile nme-dev: "haxe nme-dev/build/compile.hxml"