Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Blue_Dude - 2011-08-29
Last edited by MikeS - 2013-03-01

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

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.

Closed by  MikeS
2013-03-01 14:23
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Oy, me think fixed long time ago with DSP changes.

MikeS commented on 2011-08-29 05:25

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.

MikeS commented on 2011-09-08 03:07

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.

MikeS commented on 2011-09-22 09:28

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.

MikeS commented on 2011-09-30 06:48

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.

Project Manager
zagor commented on 2011-10-27 07:08

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

MikeS commented on 2011-10-27 14:44

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing