Loading a WAV with metadata causes lime_sound_from_file to lockup on native

[scriptorum]

I've only tested this with the comments field metadata set, and also only on mac and neko targets. Flash does not have an issue with these files.

var flSound = Assets.getSound("assets/something_with_metadata.wav");
trace("Done"); // Never reached

I'm presuming this is an issue with lime_sound_from_file, which is why I'm reporting it here. For an example wave file with metadata, here's the bugger that was causing me to pull my hair out during the most recent Ludum Dare jam.

I accidentally left Audacity in a mode where it added the comment "From Ed's LP Collection" every time I exported a file. Sadly, Ed is no longer with us, but he enjoyed having access to his music in the time he had left, and probably would have been amused by this bug.

[madrazo]

I am not sure if you are using the BEXT chunk in your WAV (the same issue I had). In my case, it was an SDL issue. I sent this fix a time ago to nme-dev and also directly to SDL: haxenme/nme-dev#2 , https://bugzilla.libsdl.org/show_bug.cgi?id=1673
The issue was accepted in SDL but I think there has no been a release version since then.

[scriptorum]

That is an interesting premise! I examined the failing wave file, looking for a BEXT but instead I found this:

0000000: 5249 4646 806d 0000 5741 5645 666d 7420  RIFF.m..WAVEfmt 
0000010: 1000 0000 0100 0200 44ac 0000 10b1 0200  ........D.......
0000020: 0400 1000 4c49 5354 2400 0000 494e 464f  ....LIST$...INFO
0000030: 4943 4d54 1800 0000 4672 6f6d 2045 6427  ICMT....From Ed'
0000040: 7320 4c50 2043 6f6c 6c65 6374 696f 6e00  s LP Collection.
0000050: 6461 7461 306d 0000 0700 0100 0700 0200  data0m..........

Comments are being stored in a RIFF INFO chunk. This is confirmed by reading up on Audacity meta-data.

It's possible SDL could be responsible, but since INFO is wrapped in a LIST chunk, it appears to me that SDL_Wave.c is already skipping INFO chunks. Hrm!

[jgranick]

We should not be using SDL_mixer, OpenFL has been using OpenAL for audio for quite some time. If you don't mind, it would be helpful if you could check if the Assets.getSound call works with a plain OpenFL sample, compiled using -Dnext, the code should be able to search for the fmt tag, but there could be an issue. It comes from here:

https://github.com/openfl/lime/blob/master/project/src/audio/format/WAV.cpp#L96

If there's an issue in here, then I can try and backport the fix to Lime legacy

[scriptorum]

With -debug -Dnext the result is the same, the code freezes on Assets.getSound with no console output. Because the LIST chunk appears between fmt and data, I suspect the issue is with the seeking of the latter.

When I look at the fmt section, the fmt chunk is progressively scanned using SEEK_CUR:

if (wave_format.subChunkID[0] != 'f' || wave_format.subChunkID[1] != 'm' || wave_format.subChunkID[2] != 't' || wave_format.subChunkID[3] != ' ') {
    lime::fseek (file, wave_data.subChunkSize, SEEK_CUR);
} else {
    foundFormat = true;                 
}

But the data section scrubs what appears to be the same position repeatedly using SEEK_SET, since currentHead does not change:

if (wave_data.subChunkID[0] != 'd' || wave_data.subChunkID[1] != 'a' || wave_data.subChunkID[2] != 't' || wave_data.subChunkID[3] != 'a') {                 
    lime::fseek (file, currentHead + sizeof (WAVE_Data) + wave_format.subChunkSize, SEEK_SET);
} else {
     foundData = true;
}

That would be my guess of the culprit. If data immediately follows fmt the code resolves, otherwise ∞.

[jgranick]

Got it :)

f0bebdc