Support and General Use > Audio Playback, Database and Playlists
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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version