Ok, I’m working on my sound viewing app again, and I have a few questions:
I’m getting a latency problem with FMOD and playing a sound (streaming). I’m guessing two things are contributing to this: normal overhead for a sound to be played and fmod dynamically loading the data at the play point when I press play. Is there any way to get it to preload all the data at a certain point so when it’s played it can respond faster. Since that probably won’t solve it entirely (if it’s even a problem), is there a way to exactly sync two things together. I thought I read about placing markers and getting notification when the sound processing gets to it, but that it wouldn’t be exact because it’s just not the actual sound playing just the system sending the sound data to the audio device or something? (please correct me if I’m wrong)
Also, in addition I’d like to set up sound scrubbing in a cross platform manner using fmod (certain a non-standard application for fmod). Is there any known way of doing that, or way to do it by setting up a callback or something? My best guess at the moment, would be to feed data to a custom looping buffer forwards or backward depending on the scrub direction (I’m guessing fmod doesn’t support playing something backwards…) and then modify the frequency like mad on the fly. The “easy way” of having the sound fully loaded in both directions and then modifying the frequency on those would probably work, but it would take up a huge amount of memory! I’d appreciate any pointers.
I’d much rather use FMOD than switch to a platform specific API like ALSA (I’m on linux…), mostly because fmod is so nice :).
- adruab asked 12 years ago
Ok, so I was wrong, you can set a stream to play in reverse (negative frequency). That eliminates the double overhead for the brain dead method.
What do you guys think about the streaming thing? Would it be able to be modified on the fly fast enough to accomplish something like real time scrubbing?
Anything helps :).
Ah, sorry for the confusion. I am playing only playing one stream but I am trying to syncronize that with graphical info. I am starting animation at the point in time where I tell the stream to start (using time differences in real time clock).
I should probably instead use FSOUND_GetTime() while the stream is playing to figure out where it is (I’m not sure why I’m finally realising this now :P).
Ok, if the stream can’t load backwards (I don’t blame it), I will have to load my own data to scrub completely backwards (or load the entire sound at once).
Hmmm, is there any way to access the decompression routines fmod uses for different sounds and manually load chunks earlier in the file (specifically mp3 and ogg)? Or would I have to use separate libraries?
Wow, 9x is pretty crazy. I thought there might have been something in the mp3 standard like that. In that case I would definitely have to use a different compressed format… or probably just WAV, in which case, it’s probably easier to just load the entire file at once (load time hit isn’t too big a deal since it’s not a real time app).
Thanks, I’ll try scrubbing on a completely loaded file first, and get back to you.
You mentioned calling FSOUND_SetPaused from a DSP unit to make sure two streams were synchronized a bit ago. Because I’m getting information from an event driven scrolling system (scrollbar and the like), I will need to access the frequency, position, and paused state from inside a DSP unit (based on the desired destination time of the scrollbar). Given what you said I would guess that’s possible. If so, at what priority would I want to do it? (I’d guess just after the clear dsp… 5 or something)
Also, does fmod always use 25 ms sample range? I should probably just use the GetBufferLength and GetOutputRate call in the dsp, right?
This is kinda goofy, but it looks like it might just work :).
Thanks again, I appreciate the help.
[quote="brett":33kr4fyv]Note that mp3 and ogg cant play backwards because they are a forward predicting file format. (ie in mp3 the current frame needs 9 mpeg frames decoded before it to get the correct result).
You would have to seek backwards and decode 9x as much data, then discard it 8 of those frames, just to get the current frame of audio without it sounding corrupted. This means your app will use 9x the cpu of an mp3 player that played forwards.[/quote:33kr4fyv]
Obviously it wouldn’t need to be as bad as 9x, since you fill a stream buffer at a time, which may consist of data from more than 1 frame.
If you have a buffer with a size of 9 mp3 frames, it would only require twice as much cpu power to play the mp3 backwards.
- Adion answered 12 years ago
That’s true… I’ll keep that in mind if I run into a memory boundary. At the moment it works ok to just load the entire thing at one time….
Edit: See next post… Ignore this…
However, I’m having some issues synchronizing it. Is there an FMOD function that can more accurately tell what the current cursor of the audio is? At the moment it seems like GetCurrentPosition just gives the current frame cursor (1 second at the moment). I knew that it would be a bit off due to latency of sending the data to the sound card, but I guess I was expecting subframe data.
Is this just a restriction of ALSA? In DSound (if I remember correctly), you could get the current position of the cursor (which was much more accurate than a frame, but still had the latency issues I mentioned).
I’m just gonna go ahead and guess for now that FMOD is exactly one frame ahead whenever the audio updates, but this is a dirty hack and I would much prefer to use a more accurate solution. If there is something better, please let me know.
Thanks a lot! I appreciate the help.
Ok, while the whole 1 second thing was a retarded error, there is still a decent amount of delay (looks like almost one DSP frame…). From when a sound is mixed to when it is played, which makes sense.
Does fmod support tracking the hardware play cursor? I haven’t found anything that can actually retrieve that information. As far as I can guess, that’s really the only way for me to completely fix my problem.
Thanks a bunch!
Please login first to submit.