0
0

Hi,

In the Interactive Music section of Designer, I’ve implemented the Shared Timeline feature so that I can jump between two different versions of the same song. It’s working well, but there’s a noticeable lag when switching between songs or even just starting up a song that contains a shared timeline. I’m pretty sure this is caused by the shared timeline feature because when I delete the shared timeline, the playback of the same song becomes virtually instantaneous. Is there any way to improve this latency (I have events in the game that require a quick change in the music)? I should mention that I’m working on the PS3.

Thanks,
Sean

  • You must to post comments
0
0

Unfortunately this lag cannot be completely eliminated due to the way the music system loads streams. It may be possible to fix it for samples, however. Are you using streams ("Stream from disk" wavebank type) or samples ("Load into memory" or "Decompress into memory" wavebank type) for your music?

Additionally, we may be able to let you tweak the music system’s cache time. This is the time that the music system allows for disk accesses to complete. A shorter cache time would increase the chance of glitching due to disk access taking too long, but would also decrease the lag.

  • You must to post comments
0
0

Hi –

I’m developing a musical instrument for the iphone and want to let the user trigger a concurrent theme in the Interactive Music System by pressing a key while a sequential theme is playing. With or without a shared timeline, there is about a second of latency. (It was two seconds before I added a thread with priority 1.0 for the music system updates – 20/second). The samples are all MIDI, set to decompress into memory, and there is a single bank.

From the debug logging, it seems there is a lot going on every time a segment is played (not just the first time):

FMOD: CoreSampleContainerInstance::cache : creating a sample
FMOD: SystemI::createSoundInternal : filename = /Users/notabenn/Library/Application Support/iPhone Simulator/User/Applications/B3772846-E56E-4412-A226-5E10A88C4F10/Prototype.app/bw_bank01.fsb : mode 00000102
FMOD: SystemI::createSoundInternal : exinfo->cbsize = 108
FMOD: SystemI::createSoundInternal : exinfo->inclusionlist = 0xb0594d60
FMOD: SystemI::createSoundInternal : exinfo->inclusionlistnum = 1
FMOD: SystemI::createSoundInternal : exinfo->suggestedsoundtype = 8
FMOD: SystemI::createSoundInternal : 16 codecs found. Scan all until one succeeds
FMOD: CodecFSB::openInternal : attempting to open as FSB..
FMOD: CodecFSB::openInternal : found FSB4
FMOD: CodecFSB::openInternal : FSB contains 7 sounds
FMOD: CodecFSB::openInternal : done.
FMOD: SystemI::createSoundInternal : Format has 7 subsounds.
FMOD: SystemI::createSoundInternal : Create as FMOD_CREATESAMPLE
FMOD: SystemI::createSoundInternal : Multi-sample sound (7 subsounds), create a sample container.
FMOD: SystemI::createSoundInternal : creating subsound 6/7
FMOD: SystemI::createSample : mode 00000102 length 79654 samples, lengthbytes 637280
FMOD: SystemI::createSample : subsamples = 1, channels = 2
FMOD: SystemI::createSample : subsample 0. output = 0x1040db0
FMOD: SystemI::createSample : mSoftware = 0x1040db0
FMOD: OutputSoftware::createSample : lengthpcm 79654, lengthbytes 637280, channels 2, format 5, mode 0000014a
FMOD: OutputSoftware::createSample : done
FMOD: SystemI::createSample : done
FMOD: CodecFSB::setPositionInternal : subsound 6 position 0 postype 2
FMOD: CodecFSB::setPositionInternal : done
FMOD: SystemI::createSoundInternal : No name found in file, use filename.
FMOD: SystemI::createSoundInternal : done. OpenState now = FMOD_OPENSTATE_READY.

FMOD: SoundI::release : bw_bank01.fsb (0x106d040)
FMOD: SoundI::release : release codec. (0x106d040)
FMOD: Codec::release :
FMOD: CodecFSB::closeInternal :
FMOD: CodecFSB::closeInternal : done
FMOD: Plugin::release : (0x106cec0)
FMOD: Plugin::release : done
FMOD: Codec::release : done
FMOD: SoundI::release : free this. (0x106d040)
FMOD: SoundI::release : done (0x106d040)
FMOD: CoreSampleContainerInstance::update : checking sample state
FMOD: CoreSampleContainerInstance::update : got a sound instance
FMOD: CoreSampleContainerInstance::update : got a subsound
FMOD: SegmentInstance::start : Segment started: this = 0x1069b90, time = 607714, start_time = 601588, end_time = 641312, length = 39724

What would you recommend to decrease latency? Would it help to split the samples among different banks? Is there some way to avoid doing all this work every time the segment is played? Would audio be faster than MIDI? Does the update rate make any difference? Thanks very much!

Paul

  • You must to post comments
0
0

Thanks, Ben. I am using this for streams, but we may try to work around this by starting the music a bit before the visual events are triggered, or we’ll give it a try with samples (if we can afford the RAM). I’ll be in touch if we decide that we want to tweak the music systems’ cache time.

Thanks again,
Sean

  • You must to post comments
0
0

Calling MusicSystem::loadSoundData when initializing reduces the subsequent latency (and number of debug log lines) when calling MusicPrompt::begin, at the cost of lengthening the initialization time, which is fine for my application.

I originally had not called that method because the sample code for MusicSystem had no call to it. Is there some reason for that?

Also, don’t know if this is related or not, while it all works in the simulator, it crashes on the device (EXC_BAD_ACCESS) with this backtrace after calling MusicSystem::update :

[b:296ddyut]#0 0x0000ed00 in FMOD::AsyncThread::getAsyncThread[/b:296ddyut]

1 0x0000ee64 in FMOD::AsyncThread::addCallback

2 0x000cbd2c in FMOD::SoundBank::staticInit

3 0x000cc50c in FMOD::SoundBank::createSamples

4 0x00098a2c in FMOD::CoreSampleContainerInstance::cacheSound

5 0x00096f9c in FMOD::SegmentInstance::cache

6 0x000ba7ac in FMOD::SegmentBuffer::Entry::cache

7 0x000ba830 in FMOD::SegmentBuffer::cacheSegment

8 0x000bb6cc in FMOD::SegmentBuffer::cacheNextSegment

9 0x000bb7b4 in FMOD::SegmentBuffer::update

10 0x000bb9bc in FMOD::SegmentPlayer::update

11 0x000b8500 in FMOD::MusicEngine::update

12 0x000b902c in FMOD::MusicSystemI::update

13 0x000b5554 in FMOD::EventSystemI::update

Thanks,

Paul

[quote="notabenn":296ddyut]Hi –

I’m developing a musical instrument for the iphone and want to let the user trigger a concurrent theme in the Interactive Music System by pressing a key while a sequential theme is playing. With or without a shared timeline, there is about a second of latency. (It was two seconds before I added a thread with priority 1.0 for the music system updates – 20/second). The samples are all MIDI, set to decompress into memory, and there is a single bank.

From the debug logging, it seems there is a lot going on every time a segment is played (not just the first time):

FMOD: CoreSampleContainerInstance::cache : creating a sample
FMOD: SystemI::createSoundInternal : filename = /Users/notabenn/Library/Application Support/iPhone Simulator/User/Applications/B3772846-E56E-4412-A226-5E10A88C4F10/Prototype.app/bw_bank01.fsb : mode 00000102
FMOD: SystemI::createSoundInternal : exinfo->cbsize = 108
FMOD: SystemI::createSoundInternal : exinfo->inclusionlist = 0xb0594d60
FMOD: SystemI::createSoundInternal : exinfo->inclusionlistnum = 1
FMOD: SystemI::createSoundInternal : exinfo->suggestedsoundtype = 8
FMOD: SystemI::createSoundInternal : 16 codecs found. Scan all until one succeeds
FMOD: CodecFSB::openInternal : attempting to open as FSB..
FMOD: CodecFSB::openInternal : found FSB4
FMOD: CodecFSB::openInternal : FSB contains 7 sounds
FMOD: CodecFSB::openInternal : done.
FMOD: SystemI::createSoundInternal : Format has 7 subsounds.
FMOD: SystemI::createSoundInternal : Create as FMOD_CREATESAMPLE
FMOD: SystemI::createSoundInternal : Multi-sample sound (7 subsounds), create a sample container.
FMOD: SystemI::createSoundInternal : creating subsound 6/7
FMOD: SystemI::createSample : mode 00000102 length 79654 samples, lengthbytes 637280
FMOD: SystemI::createSample : subsamples = 1, channels = 2
FMOD: SystemI::createSample : subsample 0. output = 0x1040db0
FMOD: SystemI::createSample : mSoftware = 0x1040db0
FMOD: OutputSoftware::createSample : lengthpcm 79654, lengthbytes 637280, channels 2, format 5, mode 0000014a
FMOD: OutputSoftware::createSample : done
FMOD: SystemI::createSample : done
FMOD: CodecFSB::setPositionInternal : subsound 6 position 0 postype 2
FMOD: CodecFSB::setPositionInternal : done
FMOD: SystemI::createSoundInternal : No name found in file, use filename.
FMOD: SystemI::createSoundInternal : done. OpenState now = FMOD_OPENSTATE_READY.

FMOD: SoundI::release : bw_bank01.fsb (0x106d040)
FMOD: SoundI::release : release codec. (0x106d040)
FMOD: Codec::release :
FMOD: CodecFSB::closeInternal :
FMOD: CodecFSB::closeInternal : done
FMOD: Plugin::release : (0x106cec0)
FMOD: Plugin::release : done
FMOD: Codec::release : done
FMOD: SoundI::release : free this. (0x106d040)
FMOD: SoundI::release : done (0x106d040)
FMOD: CoreSampleContainerInstance::update : checking sample state
FMOD: CoreSampleContainerInstance::update : got a sound instance
FMOD: CoreSampleContainerInstance::update : got a subsound
FMOD: SegmentInstance::start : Segment started: this = 0x1069b90, time = 607714, start_time = 601588, end_time = 641312, length = 39724

What would you recommend to decrease latency? Would it help to split the samples among different banks? Is there some way to avoid doing all this work every time the segment is played? Would audio be faster than MIDI? Does the update rate make any difference? Thanks very much!

Paul[/quote:296ddyut]

  • You must to post comments
0
0

[quote="notabenn":z6cok9rm]Calling MusicSystem::loadSoundData when initializing reduces the subsequent latency (and number of debug log lines) when calling MusicPrompt::begin, at the cost of lengthening the initialization time, which is fine for my application.[/quote:z6cok9rm]
That’s good, as this is the recommended way of reducing the latency.

[quote="notabenn":z6cok9rm]I originally had not called that method because the sample code for MusicSystem had no call to it. Is there some reason for that?[/quote:z6cok9rm]
The music system sample code illustrates basic usage of the music system, so it had no need to call loadSoundData.

[quote="notabenn":z6cok9rm]Also, don’t know if this is related or not, while it all works in the simulator, it crashes on the device (EXC_BAD_ACCESS) with this backtrace after calling MusicSystem::update[/quote:z6cok9rm]
This is probably because you are calling EventSystem::update from a different thread. FMOD is not thread-safe, so you should not call FMOD from more than one thread without wrapping all calls in critical sections or similar.

  • You must to post comments
0
0

[quote="notabenn":1dev2irb]Also, don’t know if this is related or not, while it all works in the simulator, it crashes on the device (EXC_BAD_ACCESS) with this backtrace after calling MusicSystem::update[/quote:1dev2irb]
This is probably because you are calling EventSystem::update from a different thread. FMOD is not thread-safe, so you should not call FMOD from more than one thread without wrapping all calls in critical sections or similar.[/quote]

Ben,

No, actually I am creating an NSTimer in the [u:1dev2irb]main thread[/u:1dev2irb], and the NSTimer calls a simple Obj-C method that in turn calls EventSystem::update. Is there any other reason why this would cause an EXC_BAD_ACCESS error on the device but not in the simulator?

Thanks,

Paul

  • You must to post comments
0
0

[quote="notabenn":3q6bwmcm]No, actually I am creating an NSTimer in the [u:3q6bwmcm]main thread[/u:3q6bwmcm], and the NSTimer calls a simple Obj-C method that in turn calls EventSystem::update.[/quote:3q6bwmcm]
Ok, I assumed you were calling FMOD from a different thread because of this statement:

[quote="notabenn":3q6bwmcm]… I added a thread with priority 1.0 for the music system updates – 20/second[/quote:3q6bwmcm]
Has this changed, or did I misunderstand you?

[quote="notabenn":3q6bwmcm]Is there any other reason why this would cause an EXC_BAD_ACCESS error on the device but not in the simulator?[/quote:3q6bwmcm]
This could be a timing issue (the timing will be different on the device). It could also be FMOD running out of memory, but this is less likely; the OS should notify your app if memory is running low, and FMOD should return an error rather than crashing if it runs out of memory.

  • You must to post comments
0
0

[quote="ben":3rubn02s][quote="notabenn":3rubn02s]No, actually I am creating an NSTimer in the [u:3rubn02s]main thread[/u:3rubn02s], and the NSTimer calls a simple Obj-C method that in turn calls EventSystem::update.[/quote:3rubn02s]
Ok, I assumed you were calling FMOD from a different thread because of this statement:

[quote="notabenn":3rubn02s]… I added a thread with priority 1.0 for the music system updates – 20/second[/quote:3rubn02s]
Has this changed, or did I misunderstand you?[/quote:3rubn02s]

Oh sorry – I had re-read the documentation and some other post of yours, and so I realized a separate thread should not be used to do updates. Just forgot to mention that change.

[quote="ben":3rubn02s][quote="notabenn":3rubn02s]Is there any other reason why this would cause an EXC_BAD_ACCESS error on the device but not in the simulator?[/quote:3rubn02s]
This could be a timing issue (the timing will be different on the device). It could also be FMOD running out of memory, but this is less likely; the OS should notify your app if memory is running low, and FMOD should return an error rather than crashing if it runs out of memory.[/quote:3rubn02s]

Could you please explain more about timing issues and how the timing is different on the device? The app is not receving a low memory warning and there is no FMOD error. Thanks very much!

  • You must to post comments
Showing 8 results
Your Answer

Please first to submit.