Rockbox

The reason is now known. This PCM buffer uses a guard buffer and guarantees 1 KB contiguous space rather than the old kind that merely wrapped the buffer and waited for the whole needed contiguous area. tdspeed demands the same buffer size regardless of the adjusted request size, leading to less and less room available near the end but always the same space demand that the buffer cannot grant. Needless to say, this feedback screeches it to a halt.

For the moment, adjusting PCMBUF_GUARD_SIZE to _at least_ 12KB alleviates the problem, unless upsampling is needed to play the file, which needs yet a larger gaurd buffer. To be a proper fix, tdspeed must be updated estimate output size accurately.

I confirm the problem on Sansa Clip+:
First observed on: r30375-110829
Newest revision without the problem I was using: r30362-110826

I would say that the playback does not stop. It is muted and it seems that the playback pointer moves. When I reset pitch/speed to 100% playback continues further in time.
Also with setting of pitch/speed other than 100%/100% the scrolling text on WPS is jittery so it probably loads the CPU a lot.

I’m not ignoring this, fyi.

The latest daily build without the problem (and probably the latest revision) is: r30365-110827.

I downgraded because not to be able to speed-up podcasts was too limiting for me :)

Is there any chance for a fix for this problem in the near future? This feature is the “Killer Feature” for me and I like to use the newest svn builds.

I don’t know. The whole scheme is flawed unless the guard and crossfade buffers are enlarged when using tdspeed, which makes it still flawed because the DSP should obey destination space truncations, which the guard and crossfade expect. How to pull it off properly and expediently at the same time, I can’t say I’m certain at this point.

The nasty fix in r30621 seems to work for me. Interesting thing is that tdspeed can be set to hang things up even with the old PCM buffer code. The feature never really was fully correct as it was when slowing things down or lowering pitch alone.

The fix corrects the problem on Sansa Clip+ for my normal usage. I tested various values of speed and pitch. Thank you.

The only problem I observed occurs when the pitch is under approximately 70 % then the behaviour is similar as before fixing the problem though after a while it auto-recovers. I do not know if the problem with pitch under 70 % appeared before r30363.
When the pitch is not too low then the problem does not occur immediately (like 70.5 % for FLAC files I was playing with). Interesting is that it seems that in the debug screen “View buffering thread” the problem occurs earlier.

Setting severity “low” as it no longer occurs at small speed changes.

It didn’t occur when downsampling is needed (pitch up/time compress) but at settings where upsampling is needed (pitch drop/time stretch). But yeah, I confirmed that it did happen even before PCM buffer changes under said conditions.

The pitch/speed setting also don’t seem to remain in sync with valid values. If your at the limit on one but adjust the other such that the old limit is out of range, it doesn’t adjust the other value.