I noticed that my CPU usage goes through the roof (ie. maxes out, around 10x what a 7 channel track takes) when decoding 8 channel Opus tracks, but only when it is outputting samples as floats. The integer call runs at expected levels. It appears to be due to the library itself rather than something dumb in my own code. I can't really tell if it happens in libopusfile or libopus.
Sounds like a problem with denormals.
Sounds like a problem with denormals.
Denormals would not only cause problems with the float output because it's the same codepath until the very end. It would have to be problems in the application code, not in libopus.
Sounds like a problem with denormals.
Denormals would not only cause problems with the float output because it's the same codepath until the very end. It would have to be problems in the application code, not in libopus.
Seems unlikely to be in the application code. Just slapping this in an infinite loop causes the issue:
ret=opus_read_float(info->opus_file, values, values_to_read, &cur_link);
Obviously there is also a read callback but that is simply an fread call that knows nothing about whether the decoder will be dealing with floats or how many channels there might be.
I'd like to try with more files, but 7.1 Opus files are pretty thin on the ground.
Profile it?
What is opus_read_float? I cannot find this function anywhere.
Sorry, its op_read_float. op_read (returns int) doesn't have the same issues.
http://www.opus-codec.org/docs/opusfile_api-0.5.pdf (http://www.opus-codec.org/docs/opusfile_api-0.5.pdf)
I had some time to dig into this today. jmvalin is right, it is an application issue and not a library issue. The loop timer collapses to zero when the total bitrate goes past 32 * 8 (* 48000). On a longer track I think it would settle down once the internal buffer was full, but on short test tracks it just thrashes the decoder as hard as it can go.