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
sound
. 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.
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.
right, seems like using custom filesystem for generic codec won’t work for this
(I found out that mp3/mpeg files do work in general though, with large enough initial buffer FMOD can seek near beginning when starting up and it seems to be decoding continuosly without problems afterwards)
Given FMOD can play (most) ogg/vorbis streams when passed an HTTP URL directly into createSound (e.g. either vorbis netradio earlier, or the long vorbis file I included in the project), is there a recommended way of feeding it compressed vorbis data - and replacing its own network retrieval method - by using anything from existing public API ?
do you mean vorbis, as in the raw bitstream? you cannot feed a raw vorbis bitstream to fmod , it needs the things ogg also brings, like the seek table stuff and the codebooks.
do you mean vorbis, as in the raw bitstream? you cannot feed a raw vorbis bitstream to fmod , it needs the things ogg also brings, like the seek table stuff and the codebooks.
no, I mean complete valid compressed codec data (so in this case including ogg container and everything else)
I’ll rephrase the question:
Given FMOD can play (most) ogg/vorbis streams when passed an HTTP URL directly into createSound (e.g. either ogg/vorbis netradio mentioned earlier, or the long ogg/vorbis file I included in the project), is there a recommended way of feeding FMOD compressed ogg/vorbis codec data - or any supported codec data really, when playing from network - and replacing its own network retrieval method - by using anything from existing public API ?
[the ‘any supported codec data’ in the above should have been rather ‘any reasonable format data’
since things like modules, or midi files are out of the question at all probably]
if the initial buffer size is big enough to prebuffer headers that a format might seek inside (as you discovered I think) then it wont have a problem, i cant list the intricacies of every format and how they seek, some seek within the file, and some dont.
All we offer is some help like the FMOD_IGNORETAGS which skips some stuff that includes seeking back and forth.
all right, thanks
it’s hard to come up with a method which would allow all supported formats to play without any user intervention (some explicit user settings), but I guess we’ll have to find some compromise
thank you for support!