As I see it implementing synchronization between two streaming system by just using File_SetDiskBusy is far from optimal for several reasons. First of all we don’t want to add FMOD code in our lowlevel codebase, that is the one doing the actual file access. This means that the syncronization has to be done at a higher level. One way to do this is to let each system stream for a certain amount of time. This is quite bad though since it doesn’t really say if we really need to feed the sounds streambuffers. A better way would be to start streaming sound when the streambuffer really needs more data. I know that Bink has such a feature where you can ask the buffers how close to finished they are. This was very usefull when I sync:ed Bink and another sound middleware but I can’t find this functionallity in FMOD. What are your recommendations here apart from saying that we should add FMOD code in our lowlevel codebase.
- Frohagen asked 10 years ago
Reading the docs, one doesn’t really get the impression that File_GetDiskBusy is very useful since it’s not reliable. getOpenState on the other hand seems like the function I’m looking for BUT since I’m using the eventsystem I don’t really know how to make use of it. Even if I would have had access to it, getting the global streambuffer state, that is if FMOD as a whole needs diskaccess for filling up its buffers, would mean traversing all active FMOD::Sound:s which doesn’t really seem like a nice solution. Any chance that something could be exposed either globally or thru EVENT_SYSTEMINFO for figuring this out?
So what do you say? Any chance of seeing a "requesting disc access" function in FMOD so we can make better syncing between data-streamer and FMOD-streamer. Also, it would be nice with a better way of figuring out if an event contains streaming material, that is if triggering the event will trigger streaming. Since we don’t want to interrupt our data streamer in the middle of a read causing seek-fights we would like to be able to check if a sound contains streaming content and if so wait until it’s ok to start streaming.
I dont understand what you mean by "requesting disc access". It reads immediately when it needs it, it doesnt ‘request’ data then wait around for ages then read later.
The stream engine reads data in chunks based on the size of your stream buffersize. If your stream buffersize is 1000ms, then it should read a chunk on average every 1 second.
I don’t know how everyone else handle their syncronization between streaming systems but the way we do it is to let one system do some reading and when it is finished switch over to the next one and so on. It doesn’t really make much sense to pause the, in our case, resource streamer if there is no sound to stream or if the streambuffer aren’t close to starving. This is the simple reason why we would like to have some kind of features that enables us to figure out when to allow the sound streamer to access disc instead of using static times. This can be done in several ways. Either by having a global function that returns the global state for streaming or by having it per event just like it is implemented per FMOD::Sound (getOpenState) or by having some functionallity for checking if an event will trigger streaming which would allow us to calculate the timeframe based on the streambuffers. Maybee some of these things are possible right now but I haven’t figured out how.
Please login first to submit.