Currently when using createStream to get a file via HTTP, the length of the stream ( GetLength() )becomes available only after the buffer is full and the mode is FMOD_OPENSTATE_READY. This creates a problem when trying to implement a “download progress” callback when using a large buffer I’m pretty sure that FMOD is using the content-length HTTP field which is in the header. Is there a problem to make this information available sooner let’s say while the state is FMOD_OPENSTATE_LOADING?
- lifemachine asked 12 years ago
But in order to set the buffer correctly to begin with (so that the playback will not stop) you need to know the files size or duration. Specially because the buffer size is critical in FMOD because you cannot change it and once you started playing if determines the download rate as well.
The HTTP headers are in the beginning of the stream so I guess it all depends on what you define “ready” to be. Maybe the right thing to do is to add another state HEADERS_READY, don’t know.
- lifemachine answered 12 years ago
OK, I guess I should have first explained my problems.
I’m trying to create a player and recorder based on FMOD, my main problems are with the download/streaming functionality.
I want the soundtrack to be downloaded as soon as possible from the server, and additionally to start playing it as soon as possible.
If I set the buffer size to be small I can start playing very soon however once I start playing the download and playback rates are locked to one another. So let’s say I started streaming and playing a song that is 4 minutes long and the user listened to 2 minutes and pressed ‘stop’, and he wants to start mixing it (for which I need the whole file). So now I have to stop the playback/download and start a new download thus wasting expensive bandwidth (otherwise I have to wait for 2 more minuets till the download/playback is over). Additionally FMOD EX doesn’t support random-access audio streams using HTTP “Range” header, so I can’t just stop the stream and start another download from the point where the playback stopped.
The result now is that I define a buffer that is half the size of the file. So after it is full I can start playing and still get the whole bandwidth.
My problems can be solved in few ways, one is to decouple the playback from the download so playSound has a parameter saying if the download should become pure streaming or just progressive streaming, alternatively Channel->stop() will not stop the download (maybe Sound->release() should do that).
Also an implementation or random access download will be nice so when you give a URL have an optional offset into the file.
I hope this is clear enough and makes sense.
I would appreciate your thoughts about these issues.
The connection is very loose I agree.
Anyway, the player is mainly for on-demand, and Shoutcast/ice are not going to be supported.
We will be only streaming MP3 over HTTP right now. Do you think that under these requirements my assumptions are big?
BTW you never replyed to my separate topic concerning “attachFileSystem with more than one system”
Please login first to submit.