# Channel::setPosition using FMOD\_TIMEUNIT\_RAWBYTES **URL:** \ **Category:** FMOD Engine\ **Tags:** cpp\ **Created:** [November 27, 2022, 5:44pm UTC](https://qa.fmod.com/t/channel-setposition-using-fmod-timeunit-rawbytes/19588 "2022-11-27T17:44:39Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![SeditQui](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@SeditQui](https://qa.fmod.com/u/SeditQui)\ **Post date:** [November 27, 2022, 5:44pm UTC](https://qa.fmod.com/t/channel-setposition-using-fmod-timeunit-rawbytes/19588/1 "2022-11-27T17:44:39Z")
Hi, I am using fmod core and have an issue with Channel::setPosition for a game project: - I have background music playing in a stream (system-\>createStream) - I want to be able to accurately use Channel::setPosition without delay. Limitations: - The file format is mp3 and is stored remotely so cannot be changed. - I cannot load the mp3 into memory instead of streaming because I need to be able to switch between different files quickly. Loading multiple mp3s into memory does not seem like a good solution. (Channel::setPosition is instant when I have the song loaded into memory.) Problem: - Calling Channel::setPosition can make the game lag for a few frames. - FMOD\_NONBLOCKING removes the lag but causes the song to be off sync. From what I can tell there is no way to pre-calculate the delay of setPosition before calling it. - Calling Channel::setPosition using FMOD\_TIMEUNIT\_RAWBYTES seems to not cause any lag. Attempt: - I know all millisecond target values beforehand, so I tried calling Channel::setPosition with FMOD\_TIMEUNIT\_MS for each value and then saving the Channel::getPosition FMOD\_TIMEUNIT\_RAWBYTES value. - Then during gameplay I call Channel::setPosition using FMOD\_TIMEUNIT\_RAWBYTES. - The playback does not seem to be synced correctly though, and every time I call Channel::setPosition using FMOD\_TIMEUNIT\_RAWBYTES there is a strange glitch sound almost like scratching a record at the start of playback. Any ideas on how to set this up? Thanks! ---
**Author:** ![mathew](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/mathew/32/431_2.png) [@mathew](https://qa.fmod.com/u/mathew)\ **Post date:** [November 29, 2022, 1:20am UTC](https://qa.fmod.com/t/channel-setposition-using-fmod-timeunit-rawbytes/19588/2 "2022-11-29T01:20:45Z")
MP3 (and many other formats) require internal priming during a seek, this means decoding multiple frames before the target position to ensure the decoder has enough internal state to play your desired position without artifacts (the glitch you hear). When you use `FMOD_TIMEUNIT_RAWBYTES` you are forcing the codec to that exact position and skipping any priming, which causes the audible glitch. When seeking a stream there is a non-zero amount of time required to flush the file position, basically instant for in-memory, slower for on-disk, and very slow for a net stream. Added to that time is the priming and initial decode getting the stream ready for playback. If you use `FMOD_NONBLOCKING`, these operations occur asynchronously on a different thread, otherwise, they occur synchronously in the `setPosition` call. There is no way to know ahead of time how long this processing will take. Sometimes you need to seek a stream, but you know so in advance, for the implementation of FMOD Studio’s timeline we have this case with looping. So we prepare a second stream pre-flushed to the correct position and play them back to back. For the cases where you don’t know ahead of time, you might need to delay actioning the seek until the target is ready, again using a second stream and playing the first till it’s ready. For predictable loops, you can `setLoopPoints` ahead of time and the stream system will take care of it for you without delay. ---
**Author:** ![SeditQui](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@SeditQui](https://qa.fmod.com/u/SeditQui)\ **Post date:** [November 29, 2022, 2:45am UTC](https://qa.fmod.com/t/channel-setposition-using-fmod-timeunit-rawbytes/19588/3 "2022-11-29T02:45:36Z")
Hey Mathew, Ah, that makes sense. Thanks, will play around with some different solutions and see what works. ---
**Author:** ![SeditQui](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@SeditQui](https://qa.fmod.com/u/SeditQui)\ **Post date:** [December 20, 2022, 3:51pm UTC](https://qa.fmod.com/t/channel-setposition-using-fmod-timeunit-rawbytes/19588/4 "2022-12-20T15:51:10Z")
Hi, Quick follow up question. I used the solution suggested with preparing a second stream and then switching streams. This works very well with zero delay. What I’m wondering is if there is any performance cost in having a prepared stream idle in the background? Currently I’m preparing the second stream, and then switching when triggered. The second stream can sit in the prepared state for a long time not being used. I’m thinking of adding the ability to crossfade between two streams that are sync sensitive. In that case I could have up to 2 streams active, and 2 preparation pre-flush streams (4 total). I understand the active streams require CPU, but what is the cost of the idle preparation streams once they have been pre-flushed but are not in use? Thanks! ---
**Author:** ![SeditQui](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@SeditQui](https://qa.fmod.com/u/SeditQui)\ **Post date:** [December 24, 2022, 2:33am UTC](https://qa.fmod.com/t/channel-setposition-using-fmod-timeunit-rawbytes/19588/5 "2022-12-24T02:33:32Z")
Any thoughts on this? Not looking for anything exact, just if its a bad idea in general to have the prepared streams idle in the background. ---
**Author:** ![jeff\_fmod](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/jeff_fmod/32/1766_2.png) [@jeff\_fmod](https://qa.fmod.com/u/jeff_fmod)\ **Post date:** [December 28, 2022, 10:47pm UTC](https://qa.fmod.com/t/channel-setposition-using-fmod-timeunit-rawbytes/19588/6 "2022-12-28T22:47:25Z")
Apologies for the delayed response- there is no ongoing CPU overhead for a stream that has been loaded and is not playing. It will just be taking up memory, and only when the time comes for it to play will it use CPU resources. You can confirm this by initializing FMOD with the [FMOD\_INIT\_PROFILE\_ENABLE](https://fmod.com/docs/2.02/api/core-api-system.html#fmod_init_profile_enable) flag, attaching the [Core API Profiler](https://fmod.com/docs/2.02/api/white-papers-virtual-voices.html#core-api-profiler) and ticking the _CPU Usage_ checkbox. Here is a screenshot of the Core API Profiler attached to the **gapless\_playback** example. You can see that the prebuffered sounds only use CPU when they are actually playing: ![image](https://canada1.discourse-cdn.com/flex036/uploads/fmod/original/2X/a/a5ffc857ed5c8b93d1061a8c912c62eaa22e51a8.png) Hopefully this answers your question, please let me know if anything is unclear! ---
**Author:** ![SeditQui](https://avatars.discourse-cdn.com/v4/letter/s/9fc29f/32.png) [@SeditQui](https://qa.fmod.com/u/SeditQui)\ **Post date:** [December 29, 2022, 3:38pm UTC](https://qa.fmod.com/t/channel-setposition-using-fmod-timeunit-rawbytes/19588/7 "2022-12-29T15:38:39Z")
Hi Jeff, Great, thanks for getting back to me! 🙂