When returning FMOD_ERR_FORMAT from a custom codec open callback to let FMOD know a codec is not capable of opening the file format specified, FMOD used to try other codecs before failing completely. It now fails right away no matter what priority is passed to registerCodec.
Hm I just added a custom raw codec and returned FMOD_ERR_FORMAT in the open callback, it was an mp3 and the mp3 then succeeded to open.
Did you happen to accidentally use FMOD_CREATESOUNDEXINFO::suggestedsoundtype at the same time?
Are you registering the codec with priority 0 or higher? It behaves as I describe when I use 0.
I do not set the suggested type.
The problem is not with the priority but rather that the data returned by codec->fileread is not correct and thus the codec crashes.
Try opening an mp3 or m4a file with a codec registered with priority 0. It crashes nicely.
Opening ogg file seems to bypass any custom codec even when registered with a priority 0.
You’re right, priority is irrelevant.
My test simply opens an mp3, returns FMOD_ERR_FORMAT from the open callback, then it continues to successfully open as an mp3 using the built in mp3 codec.
I’m not sure what ogg or mp3 really have to do with the behaviour, it makes no difference to the system. I changed it to ogg and the file opens as ogg correctly.
It sounds to me like you’re not returning FMOD_ERR_FORMAT in the right place. You’re doing it in the open callback and not the read callback right? You shouldnt be getting any read callbacks if you failed the codec open on the open call.