I think I am going to need a little more context to understand your issue here. Have you tried running the user_created_sound example? That’s probably the best place to start with how to use a pcmreadcallback correctly.
My task is to stream bytes and play them back. Mp3Frame.cs - Pastebin.com with this file I get rawBytes of the audio fragments themselves. and try to play them back by converting them to byte[2] => short
but is there any way with FMOD to just stream raw bytes of an .mp3 file to FMOD itself ?
If it’s not possible, tell me how to play the mp3 File correctly.
Thank you for the extra information, that clarifys things. To play an mp3 file as a stream you can use the System::createStream helper function or pass the FMOD_CREATESTREAM flag to System::createSound, using the path to the mp3 file as the first argument in either case.
I tried to specify the mp3 file by URL, but it does not play, I read the section on this forum with a similar problem, forum support in that section said that there are a lot of tags and need to remove at least some of them. But since the mp3 is located remotely it is not possible. So I am trying to manually retrieve the bytes and play them back.
I have found remote mp3s are loading correctly in a net stream in the latest version of FMOD, what version of FMOD are you using?
Would you mind sharing the url to your mp3 file? You can share it in a private message to me if you are concerned about sharing it on a public forum.
For your first question, you have to pass PCM (decompressed) sound data to the pcmcallbacks , not compressed mp3 data. That is probably the squeak you are hearing.
Use the netstream example to test remote mp3 streams in the example folder if you like. It has some good settings for net streaming.
I have tried your website example, the error is 301 - moved permanently, this can be seen by using the L or Logging version of fmod.
It looks like the website has this response in place to stop people hotlinking to their host.
update: we realize the 301 redirect now is redirecting away from http to https , and our ‘https support’ is not truly correct https support. we typically still aim for the port 80 version of the file and in a lot of cases this works. This host disallows this so we have to look at how to support it properly.
We will look at providing an update in the future with better https support.