Rockbox

Tasklist

FS#12250 - Playback freezes when using big speed or pitch change

Attached to Project: Rockbox
Opened by Jeffrey Goode (Blue_Dude) - Monday, 29 August 2011, 02:51 GMT
Last edited by Michael Sevakis (MikeS) - Friday, 01 March 2013, 14:23 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System SW-codec
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Can't play back audio at any setting other than 100%/100% pitch/speed. Playback freezes almost immediately after changing pitch or speed, or when using a bookmark with pitch or speed information. Problem occurs in r30372, but probably appeared earlier.
This task depends upon

Closed by  Michael Sevakis (MikeS)
Friday, 01 March 2013, 14:23 GMT
Reason for closing:  Fixed
Additional comments about closing:  Oy, me think fixed long time ago with DSP changes.
Comment by Michael Sevakis (MikeS) - Monday, 29 August 2011, 05:25 GMT
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.
Comment by Václav Brožík (pabouk) - Tuesday, 30 August 2011, 16:24 GMT
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.
Comment by Michael Sevakis (MikeS) - Thursday, 08 September 2011, 03:07 GMT
I'm not ignoring this, fyi.
Comment by Václav Brožík (pabouk) - Wednesday, 21 September 2011, 16:41 GMT
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 :)
Comment by Wolfgang Dilg (rasferret) - Wednesday, 21 September 2011, 21:16 GMT
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.
Comment by Michael Sevakis (MikeS) - Thursday, 22 September 2011, 09:28 GMT
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.
Comment by Michael Sevakis (MikeS) - Friday, 30 September 2011, 06:48 GMT
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.
Comment by Václav Brožík (pabouk) - Tuesday, 04 October 2011, 08:12 GMT
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.
Comment by Björn Stenberg (zagor) - Thursday, 27 October 2011, 07:08 GMT
Setting severity "low" as it no longer occurs at small speed changes.
Comment by Michael Sevakis (MikeS) - Thursday, 27 October 2011, 14:44 GMT
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.

Loading...