I’m not sure if this is my implementation or if I’m trying to do something illegal.
I’m having intermittent trouble with multiple streams to different parts of the same mp3. It’s a standard MP3 track, say from Amazon. Is this possible? Is there any limit to the number of concurrent streams to different parts of the same file?
Thanks for the help, apologies for the delay in responding.
Given your information I’m moving forward with the assumption that the issue is in my implementation somewhere.
(It’s a complicated bit of code that includes a third party time-stretching lib. Using create_sample it all worked fine, I’m moving to just-in-time seeking and streaming, hence the need for multiple streams to preemptively seek and buffer for immediate position jumping. Not really possible to extract a working example, but given your assertions that what I’m doing is possible, highly likely that the problem is me. Thanks again.)
Is there anyway to get confirmation of the position of a stream in this case? (I’m not using channels so getPosition is out). This would be very useful.
You could use pcmsetposcallback and pcmreadcallback from FMOD_CREATESOUNDEXINFO to get some info about where the file is seeking to what has been read.
There is no arbitrary limit to the number of streams you can open for a particular file. Streaming IO bandwidth and CPU decoding cost will be your only bounds.
You will need unique FMOD::Sound handles for each place you are doing seeks and reads if there is a chance the operations will overlap. Assuming you’ve done that, the case of opening the same file multiple times playing at different locations is fairly common usage.
If you could provide a working example that reproduce the glitch I could investigate further.