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 Jeffrey Goode - 2011-08-29
Last edited by Michael Sevakis - 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  Michael Sevakis
2013-03-01 14:23
Reason for closing:  Fixed
Additional comments about closing:  

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

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

Václav Brožík commented on 2011-08-30 16:24

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.

Michael Sevakis commented on 2011-09-08 03:07

I’m not ignoring this, fyi.

Václav Brožík commented on 2011-09-21 16:41

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 :)

Wolfgang Dilg commented on 2011-09-21 21:16

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.

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

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

Václav Brožík commented on 2011-10-04 08:12

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.

Admin
Björn Stenberg commented on 2011-10-27 07:08

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

Michael Sevakis 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