wavpack, very minimal wps

[Llorean]

There's definitely something going wrong then. Wavpack should fill the buffer just like any codec. And because it's not filling it, it doesn't refill 'till it's empty, completely negating the anti-skip buffer setting.

I suggest you file a proper bug report describing how the Compressed buffer doesn't refill properly with wavpack.

[gaillard]

how? i don't see in the bug tracker anywhere to add one, do you have a link to filespray?

[Llorean]

In the bug tracker, there is an add new task button in the top left.

[bryant]

I think maybe I can clear this up, at least somewhat.

WavPack files, unlike FLAC files, can vary considerably in their decoding complexity. Only the fastest mode (-f) is close to the decoding complexity of FLAC. The higher modes use progressively more CPU cycles, and the lossy mode requires some additional also. Because the decoding of the "high" mode required such a high boost ratio on my Nano, I recently created a new "high" mode that achieves almost the same compression with lower decoding complexity, and I renamed the previous high mode "very high" and specifically recommend it not be used for portable use. This is discussed here (and there's an alpha version available):

http://www.hydrogenaudio.org/forums/index.php?showtopic=47389

I just measured the boost ratio required to play WavPack lossless on my Nano:

  12%: fast mode
  24%: default mode
  44%: new high mode
  66%: very high mode (old high mode)

I also measured that adding crossfeed adds about another 10%, getting your "high" files to about 76%. However, that should still work okay (and I just tested it here and it works fine even using the peakmeter).

There are two other things I can think of. First of all, I assume your files are 16/44.1, right? If they had to be resampled from 48 Khz or were 24-bit that would take a lot more CPU.

Another more general issue is whether there is any difference between the Nano and the Color as to their CPU usage? Could the Color be using more cycles for display update?

Anyway, I suspect that the decoding complexity of your files combined with the crossfeed and perhaps some difference in the version for the Color is causing the required boost to go over 100%, which produces exactly the symptom you are seeing.

David

[Llorean]

Well the thing is he described the compressed buffer never filling. Usually when the decoder can't keep up, the compressed buffer fills just fine, but the PCM buffer frequently empties because the audio can't be decoded fast enough to keep that one from underrunning. His description says that the compressed buffer is underrunning (and then the PCM one does, but that's just because there's no data to feed it.) That shouldn't be a symptom of too much CPU usage, right?

[bryant]

I haven't actually followed this in the code, but based on watching the audio thread status I'm pretty sure that there is a mechanism to prevent attempts to fill the compressed buffer when the PCM buffer is below a certain level (about half) unless the compressed buffer is almost empty. So, one of the symptoms of not having enough CPU that I've seen is that the compressed buffer never fills.

My assumption was that filling the compressed buffer also uses a lot of CPU (which is why it boosts then also) and you wouldn't want to risk running out of PCM data during an extended fill operation.

BTW, I have recently created a test suite for WavPack which includes lossless clips at each of the 4 speed modes. Unfortunately, they're only 30 seconds each which is a little short for measuring boost, but I've had good luck putting one file in a folder by itself and having it repeat (the code continues to reload even though the whole file would fit in the buffer). The suite is here:

http://www.rarewares.org/wavpack/test_suite.zip

[gaillard]

Thanks for helping bryant.

with cross feed off it seems to stay at around 90 percent, which is still not right correct?  I mean he is showing 66...  this is a very minimal wps, is there anything else that can be taking processor power?

[lowlight]

I wonder if this could be an issue with the new scheduler not giving enough priority to buffering.

Can you try an older build? Download one from here on or before 2006-09-16:
http://www.rockbox.org/dl.cgi?bin=ipodcolor

[gaillard]

the 9-16 one locks up when ever i play a file, and doesn't start to play.

im going to try and one before the date one sec

k the 9-11 works but has the same problems, flac does play at a lower boost though. but wavpack with crossfeed off even stays at 100 percent boost and doesn't fill up the buffer initially or ever.

i don't understand shouldn't it still fill up the buffer, because when it does go back up after hitting zero it does it quickly...

[gaillard]

wavpack without the -h option by the way runs at 75 boost just fine... but who doesn't use -h?!

[Llorean]

You can't make a processor faster just by expressing your displeasure.

[lowlight]

The issue is that buffering requires the cpu & decoding requires the cpu. They should yield for each other, but if the decoding is too intensive, the buffering may never complete which appears to be the case here. You might be out of luck with these files.

[gaillard]

ok well thanks anyways guys, Hopefully things will be better later on... perhaps i'll find sometime after another year of school or so and help with some code..

Goodluck!!

[bryant]

wavpack without the -h option by the way runs at 75 boost just fine... but who doesn't use -h?!

Many people who move to WavPack from FLAC use -fx because that gives about the same decoding speed and compression ratio as FLAC (at least according to the comparison on the FLAC site).

People who move from Monkey's Audio probably use -h (or even -hx) to get close to APE in compression. I think the two inside modes (the default and the new high mode) are the best compromises.  

What remains a question is why the 4th gen Color would use so much more CPU than the Nano for decoding WavPack. I don't have any other model besides the Nano to find out, but I know the Color has a different version of the PortalPlayer chip, so maybe it has a less efficient cache or something like that. The other possibility is the graphics (or something else) is taking more CPU cycles on the Color. It would be interesting to see of other codecs are affected by this.

Perhaps someday we'll be able to split the codec and the other audio processing into separate threads (and cores). That will solve it...  

[lowlight]

I would guess that hard disk vs flash disk and 220x176 vs 176x132 lcds would be the main differences affecting performance.

If it really is the competition between codec and ata cpu usage that is preventing buffering from happening, then I wonder if the new scheduler could be tuned to allow buffering to occur uninterrupted. Obviously playback would stop, but you may get real-time playback thereafter until the buffer needs to be refilled.