Problem with looping http hosted files

I have been testing the fmod playback of ogg (and other format) files.

Ogg files play back and loop fine when they are hosted on the device (iOS), but when I try to open them from http link they just don’t loop. They play, but they only play once.

The only difference in setup is that I am passing FMOD_CREATESTREAM when setting the mode. Here’s the file:

It has the Accept-Ranges header, as mentioned in another post.

I loaded that exact file in the play_stream iOS example project, and the same thing happens. It plays once, then is silent.

Any help would be greatly appreciated.

You might find some info in here

Thanks @brett that’s very helpful, but unfortunately it still doesn’t play the second time. The first play plays fine, then it just goes silent.

I took the example code in the play_stream_ios example and just changed a few lines.


    memset(&exinfo, 0, sizeof(FMOD_CREATESOUNDEXINFO));
    exinfo.cbsize = sizeof(FMOD_CREATESOUNDEXINFO);
    exinfo.suggestedsoundtype = FMOD_SOUND_TYPE_VORBIS;
    result = system->createStream(

Is there something really obvious I’m missing?

Hi Josh,
Did you just try to call playSound on it again? That would be the equivalent of seeking. You should try releasing the soudn then creating it each time for a netstream so it can reconnect to the address at the start.

I did this and it worked ok. You dont need to suggest to createsound the format, it can guess it from the extension. That feature is just to avoid autodetect scanning multiple codecs if it cant work it out (its a good idea though in general if you want to avoid netstreams scanning / attempting to seek through a bunch of different formats and erroring out).

Here’s my code

result = gSystem->createStream("", FMOD_IGNORETAGS, 0, &gSound[0]);

result = gSystem->playSound(gSound[0], 0, false, &gChannel[0]);


result = gSound[0]->release();

result = gSystem->createStream("", FMOD_IGNORETAGS, 0, &gSound[0]);

result = gSystem->playSound(gSound[0], 0, false, &gChannel[0]);

Hi Brett, thanks for this. It’s not HLS, it’s just a file hosted on https (perhaps I’m confused about the nomenclature here!). As it is, I’m seriously confused as to why seeking doesn’t work - you can seek most files whenever there’s an Accept-Ranges header available, which there is in this case.

that one above definitely has one, and the embedded media player in the page actually seeks it fine.

This post also raises a similar question NetStream Loop?

For the looping, I just add the FMOD_LOOP_NORMAL flag. If you do this in the play_stream example, the player actually shows the timecode for the file continually looping, but the sound just stops.

I’d like to know if it’s
a) impossible to loop http(s) hosted files using the standard fmod methods or
b) just a bug, or missing header, or another issue

As a side note, ExoPlayer, AVAudioPlayer, and VLCKit all support seeking and looping over http(s) with most filetypes.

Hi @brett . Sorry to bump the thread, but did you have any thoughts on this problem?

Apologies for the delay, i’ve looked into it now.
There is an issue in the network file handling that I have discovered. I have fixed it for the next minor release update.

Incredible! Thanks @brett. :crossed_fingers: this fixes the problem.


How do we go about working with .m3u8 files for HLS for FMOD?

you would have to download and parse those types of file yourself at this time.

edit: HLS is a special API for low latency streaming, fmod does not support this either

Is HLS support on the development roadmap?

It is possible it works now as we run audio streaming of AAC through AudioQueue (iOS only) but I have not checked it on my side, just Windows testing here right now. I can see m3u8 uses #EXT-X-VERSION tag vs m3u which we support via #EXTINF tag, so that file format version I can confirm is not supported, but it probably wouldnt take much work to support the different ID fields it uses to get the strings out.

Right now HLS and M3U8 official support is not on our roadmap. Standard http streaming is supported via our API.