Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

decodeToBuffer does not fire callback #9

Open
mon opened this issue Feb 13, 2016 · 5 comments
Open

decodeToBuffer does not fire callback #9

mon opened this issue Feb 13, 2016 · 5 comments

Comments

@mon
Copy link

mon commented Feb 13, 2016

I've been using Aurora and mp3.js for some time now with no issues. Attempting to add ogg vorbis for the poor souls on Safari and Edge. My page uses decodeToBuffer, but this does not seem to work for the ogg.js demuxer.

Here is my test page, using opus. The issue also exists with vorbis. Replacing the test file with an MP3 fires the callback and prints to the console as expected.

In my actual app, decoding is either garbled or triggers an abort exception, but this is difficult to reproduce in a small test case.

@devongovett
Copy link
Member

Your test.opus file is zero length. Causes #7.

@mon
Copy link
Author

mon commented Feb 13, 2016

I've updated the test to use a larger (~1MiB) test file. It is now using ogg vorbis instead of opus.

Making the code change in #7 fixes the 500 sample opus file, but still no callback for the vorbis.

@devongovett
Copy link
Member

I get an abort. Looks like an assertion is being triggered somewhere in the vorbis decoder.

@mon
Copy link
Author

mon commented Feb 14, 2016

I've tracked it down to a segfault in a realloc in ogg_sync_buffer (framing.c:645). It asks for 16 and 23k, then fails on a request for 28k. I'm out of my depth now.

Changing vorbis.js's buffer size to 2048 (instead of 4192) makes the decode succeed, but the audio is shorter than it should be and fairly garbled. I did a bit more fiddling with buffer sizes but most end in an abort(). I don't think I'm on the right track. I will continue to investigate.

@mon
Copy link
Author

mon commented Feb 14, 2016

Changing framing.c:641 to increase in multiples of 8kiB instead of 4kiB produces correct decodes. This feels like a hacky workaround though. This might be an emscripten bug but I'm hesitant to suggest this because of my lack of knowledge.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants