Is it possible to prevent FMOD scanning the whole OGG/VORBIS file while opening it?

I would like to - is a project approval needed to be able to upload files ?
otherwise I can’t see a way of uploading stuff in my profile, and the project I tried to register is pending for approval still

Done - thank you for enabling the profile !

Thanks very much for the example project.

By using the FMOD.MODE.IGNORETAGS flag you can make FMOD not seek to the end, but unfortunately it appears that the oggvorbis codec wants to seek to the end internally. From what we can see, there does not appear to be a way around this at the moment.

Thank you at least for confirmation / explanation

One more question about this:

FMOD itself can play Vorbis netstreams, e.g. this works (complete working snippet, with default parameters):


    FMOD.System system;
    FMOD.Sound sound;
    FMOD.Channel channel;

    var result = FMOD.Factory.System_Create(out system);

    result = system.init(100, flags, IntPtr.Zero);

    var extInfo = new FMOD.CREATESOUNDEXINFO();
    extInfo.cbsize = Marshal.SizeOf(typeof(FMOD.CREATESOUNDEXINFO));

    result = system.createSound("", mode, ref extInfo, out sound);

    FMOD.ChannelGroup master;
    result = system.getMasterChannelGroup(out master);

    result = system.playSound(sound, master, false, out channel);

(error checking omitted for brevity as well as sound release…)

However, as soon as I plug in a custom filesystem it can’t - with behavior which initiated original question.

While testing this with non blocking sound creation (which is prob. the only way of capturing original error state really) I noticed that posted code/url goes through ‘CONNECTING’, ‘BUFFERING’, ‘READY’ phases of getOpenState, whereas with custom filesystem it’s stuck in ‘LOADING’ phase -
which lead me to question if there is something different that FMOD does internally for streamed sounds which I can’t properly emulate with filesystem ?
It’s possible that my custom filesystem implementation is wrong, but note that it can play other formats successfully ( e.g. reaches ‘READY’ state without problems )
. I set filesize to uint.MaxValue for streams with unknown length and FMOD tries to probe around this location, but I suspect that it doesn’t set it internally, or works around this in some way.

Is it possible to play Vorbis netstreams with custom filesystem ?
If there’s nothing preventing this I’ll upload my implementation later if needed.

Thank you very much for reading!

I don’t believe there is anything ‘hidden’ that you need to do that, if you want to upload your implementation we can take a look for you.

Thank you very much for the support !
I’ve uploaded test project, both methods - playing Ogg/Vorbis netstream url directly via FMOD, and via separate download handler + custom file system - are included
Tags reading implementation referenced in the other thread is included too -
Hopefully everything needed can be seen in the console : I hope that it’ll help and you can make sense of it

As you have already found, if the source is an ogg/vorbis file your file system can handle it just fine. However if the source is a net stream, in this case an icy stream, FMOD does have a lot of internal code that is used to communicate with the stream. And since you are overriding the file system FMOD is assuming you are doing this too.

Hi, thank you for taking a look !

I think FMOD is doing something else internally even for finite sized ogg/vorbis files retrieved from network, not just icy streams though -
ogg/vorbis icy stream from the example fails to load/start at all, an ogg/vorbis files from network location (*) start playing but stop after few (blockalign) frames immediately -

(*) by network location I’m always assuming plain HTTP protocol

Is it possible to tell how should be ogg/vorbis format served to FMOD via custom filesystem to match its internal implementation of handling this format when streamed over network ?
/ In other words - is is possible to emulate what FMOD is doing internally ? /

The lack of secure transport support is really limiting - people can’t use FMOD networking on private VPS instances for example which are not accessible via plain HTTP nowadays
. of course, the most transparent/user friendly solution would be for FMOD to support secure transport, but that brings whole set of problems (that’s why I’m using UnityWebRequest which solved most of them)

If that isn’t possible right now though - can we at least follow some guidelines on how to provide compressed data over network to FMOD via custom filesystem so it can play all formats it supports ?
(or, at least most of them; thankfully MPEG seems to be more or less working with some more tweaks which can be automated)

try setting your length of your file to (unsigned int)-1 or 0xFFFFFFFF in FMOD_CREATESOUNDEXINFO to tell fmod that it is an endless stream, and it will stop trying to seek to the end of the file.

Thank you, but that unfortunately didn’t help at all :
/ netradio from above is stuck in LOADING getOpen state, and ogg/vorbis file on a local network via HTTP can’t be played – with either BAD_FORMAT error/s, or not going past LOADING state as well /
FWIW I set filesize in opening handler too (which is correctly carried over from extinfo though it seems)

forget trying to open a plain ogg file. it has chunks and data packets at the start and end and seeks all over the place. An /icecast/ stream on the other hand is set up for this, and doesnt seek. MP3 with IGNORETAGS can be opened over a network as a plain file, as it will not try to seek as part of the mp3 code. ogg has no such checking.

Your question was about ‘seek to end’. If the length is correctly set to -1, this callback will not happen.

yea the title is a bit misleading at this point (I naively thought if that can be eliminated FMOD would be happy - apparently it’s not so)

I can workaround vorbis files for now by having huge blockalign (essentially downloading them first - that’d work to some extent ), but note that the webradio [] doesn’t work even with filesize set to -1 and custom filesystem

and note that FMOD itself - when giving it resource url directly in createSound and not using filesystem -plays correctly in both cases

So what is there to implement in a custom filesystem in order to have identical behaviour ?
(this is probably related also to tags retrieval in different thread, but it’s not that critical since I think it depends on this working first)

for clarification: the callback at uint.MaxValue does happen initially even with filesize == -1 for that icy stream

btw @brett this all is done from c# wrapper from Unity - if you’re sure that setting filesize to -1 should help is it possible there’s a bug in the c#/c/c++ interop with this (esp. since all wrapper calls have respective parameters typed as uint) ?

FWIW I uploaded another test project ( - there are two netradios in it, one mpeg, one ogg/vorbis mentioned previously, and you can see the read callbacks happening near uint.MaxValue in the Console when creating the sound in both cases (mpeg survives)

thanks for having a look, if possible!

Hi, I would concentrate on the -1 thing, it is the first hurdle to make sure it is not thinking it can seek which is the biggest problem with netstreams.
Its possible it is not passing -1 from C# to C++ properly, try 0xffffffff or 4294967295 instead.

brett, thank you: but the size is set in both FMOD.FILE_OPEN_CALLBACK and in FMOD.CREATESOUNDEXINFO
(filesize and extInfo.length are both set to ‘-1’ or to what c# allows, i.e. uint.MaxValue /4294967295/ )

Have you had a chance to look at the project I uploaded ? - there is simple
isolated scene in minimal project (just necessary parts of the integration and one testing scene) with both netstream formats, in both cases
you can see callbacks log in the Console near this length when starting the
. if there are more places I should set the lenght/size please let me know, I would be happy to test

sorry to tag you @brett , just wanted to confirm that near-end initial callbacks are indeed not expected behaviour
the sample i uploaded has them and i’m not sure what to configure further to avoid them if it should be possible at all

yes the callbacks to seek to end dont happen in C/C++ that i have tested , I have not tested in C#. Signalling -1 / infinite length means there is no trigger to seek to the end of the file because it doesnt know where the end is.

Hello @brett , I’ve been testing with asyncio sample and (2h long) ogg/vorbis file and have few questions -

: when I set *filesize of local media in open callback to -1 instead of real file size and use e.g.

memset(&extinfo, 0, sizeof(FMOD_CREATESOUNDEXINFO));

extinfo.suggestedsoundtype = FMOD_SOUND_TYPE_OGGVORBIS;
extinfo.length = -1;
extinfo.cbsize = sizeof(FMOD_CREATESOUNDEXINFO);

for createSound, FMOD fails with FMOD error 19 - Unsupported file or audio format.
and debug log:

[LOG] SystemI::createSoundInternal : exinfo->cbsize = 144
[LOG] SystemI::createSoundInternal : exinfo->length = 4294967295
[LOG] SystemI::createSoundInternal : exinfo->suggestedsoundtype = 10
[ERR] CodecOggVorbis::openInternal : failed to open as ogg, format error.
[ERR] CodecMOD::openInternal : ‘M.K.’ etc ID check failed [s?i?]
[ERR] CodecS3M::openInternal : ‘SCRM’ ID check failed [???]
[ERR] CodecXM::openInternal : 'Extended Module: ’ ID check failed [OggS]
[ERR] CodecIT::openInternal : ‘IMPM’ etc ID check failed [OggS]
[ERR] CodecMIDI::openInternal : ‘HThd’ ID check failed [OggS]
[ERR] CodecMPEG::openInternal : failed to open as mpeg

: with *filesize set to ftell(fp) and the same size for extinfo.length, the local file plays OK (I removed the priority scheduling from the sample since it caused constant starvations)

If I play the very same file from a HTTP location (no extinfo), the startup and playback is seamless and immediate too
/ I would suppose the server returns proper ContentLenght (haven’t verified this) /

It’s not possible the whole ~200MB file is downloaded immediately when FMOD is opening it, so I’d assume it isn’t trying to scan it either since the playback is immediate

Is it possible to achieve identical behaviour with custom filesystem if the whole media is not available for reads (yet) ?
And/or is it possible to actually have not defined/unknown length of the media when using custom file system at all ?

I’ve uploaded VS solution based on 2.00.06 sample - ‘unknown_length_vorbis_stream_llapi’ to my profile (a simple HTTP server would have to be used to test network playback)

Thank you for reading, hope custom filesystem can be used like this

some formats are just not compatibile with the infinite length idea, because they cant open without doing some seeking first. This is incompatible with net streaming. The -1 length / infinite length idea is just to remove the ‘seek to end’ to work out the length of the file that is typical for file management.
There is only a select number of formats that will let you open without seeking. FSB (of any codec including vorbis) and mp3 (ignoring tags) are the best ones that I can think of.