Thought some of you might be interested in knowing I've used libmpcdec-1.2 to produce a MPC codec for the Roku PhotoBridge.
The Roku PhotoBridge is an 'open platform' and a few weeks ago they (Roku) released a (currently very much beta) version of their firmware that supported a plugin codec model. So, their new version of music playing software is still pretty basic, but anyone who wants can download a version of the MPC codec (from my site) and enjoy their Musepack encoded music.

I only had a make a few tiny changes to the libmpcdec-1.2 source code to make it compile/work.
It makes use of MPC_FIXED_POINT - with this not defined its (very rough figures) about 3x slower than real time, with MPC_FIXED_POINT defined it can decode (again rough figures) at around 6x realtime.

I only had a make a few tiny changes to the libmpcdec-1.2 source code to make it compile/work.

Are you able to say those changes ?

Quote:

Originally Posted by soiaf

It makes use of MPC_FIXED_POINT - with this not defined its (very rough figures) about 3x slower than real time, with MPC_FIXED_POINT defined it can decode (again rough figures) at around 6x realtime.

The lib use floating-point mode by default as it's usually the fastest mode on desktop cpus. Maybe the roku photobridge cpu is using floating point mode emulation, that would explain its slowness compared to fixed-point

Change 2
The PhotoBridge seemed unhappy with the use/declaration of __Cc and __Dc

All that was required was to remove the const keyword from their declaration.

Quote:

Originally Posted by Lefungus

The lib use floating-point mode by default as it's usually the fastest mode on desktop cpus. Maybe the roku photobridge cpu is using floating point mode emulation, that would explain its slowness compared to fixed-point

Yes, it doesn't have a FPU, so it was using emulation. I really only tried the floating-point code to see how much slower it was than fixed-point. Answer (on the PhotoBridge anyway) - a lot slower!