Ah, correction sorry, looks like the onprogress callback in emscripten_async_wget2_data() *doesn't* have a pointer to the data that's downloaded so far, you only get the number of bytes downloaded, but not the bytes themselves. You only get the data when the entire download is finished in the onload callback :(
So I guess you're out of luck and the only way to stream partial data is via HTTP range requests (which as far as I know are not supported by the emscripten_wget* functions). On Friday, 24 July 2020 at 12:22:45 UTC+2 Floh wrote: > > Main problem is that I just wanted to add some minimal code changes to > support emscripten. > > Yep, that would be preferrable. But I think curl's streaming callback > isn't easy to map to the emscripten_wget* functions. > > But maybe the emscripten_wget2_data() function can be used: This has an > onprogress callback, which seems to be called before the entire file is > downloaded, and this has a pointer to a buffer and a "number of bytes > loaded" argument (see: > https://emscripten.org/docs/api_reference/emscripten.h.html#c.emscripten_async_wget2_data > ) > > However note that both methods (curl with CURLOPT_WRITEFUNCTION and > emscripten_wget2_data()) don't have any guarantees how much data has > actually been loaded before the callbacks are called (that's why I'm using > HTTP range-requests basically), I think this means that a lot of audio data > will be queued up in RAM (basically the entire file size) because there's > no way to pause the download to allow the audio playback to catch up. Don't > you see RAM usage explode in your example for "infinite streams"? > > So basically, you could try replacing the call to curl_easy_perform() with > a call to emscripten_async_wget2_data(), and maybe the onprogress callback > is performing similar to the curl WRITEFUNCTION callback. One difference > will definitely be the emscripten_async_wget2_data() will not block but > instead return immediately, you need to use the provided callbacks to check > whether the download has finished, and also should use one of the > emscripten_request_animation_frame_* functions to periodically check what > on the status of the download (which basically requires to split your code > into an initialization-part, and a per-frame part). > > Hope this helps! > -Floh. > > On Friday, 24 July 2020 at 11:42:16 UTC+2 Flix wrote: > >> Hi Floh and thanks for your help! >> >> I'm happy that I can use sokol_fetch.h >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ffloooh%2Fsokol%2Fblob%2Fmaster%2Fsokol_fetch.h&sa=D&sntz=1&usg=AFQjCNF7x51j6uB7o_LTB1ZK5YPCXdD9ng> >> >> (BTW: it contains a big amount of documentation too). >> >> Main problem is that I just wanted to add some minimal code changes to >> support emscripten. >> >> The program I'm trying to port is all in this gist here: >> https://gist.github.com/Flix01/157e8dafd9bef766092264ce6c1abbdb (a >> single .c file in about 450 loc, and I think it's already too long). >> >> [I'm also using OpenAL instead of sokol_audio.h, so following >> plmpeg-sapp.c >> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Ffloooh%2Fsokol-samples%2Fblob%2Fmaster%2Fsapp%2Fplmpeg-sapp.c&sa=D&sntz=1&usg=AFQjCNF-K4HqnkvlTqpmgme1BtL6NUfFzQ> >> >> is a bit more difficult for me]. >> >> Anyway at least now I've got the proof that it can be done. Thank you >> again. >> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/2f0c71c2-9dfe-4cdf-b277-295d63e5e134n%40googlegroups.com.
