Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System SW-codec
  • Severity Medium
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Nimdae - 2007-06-04
Last edited by linusnielsen - 2007-07-05

FS#7257 - Playback resumes while paused when pressing back

This is a fresh build on an iPod 5G. I downloaded the latest source and manually built it on kermit.pimpinwithmuppets.com build server.

What happens is if I pause the playback, then hit the back button to go back to the beginning of the song, it does go back to the beginning of the song, but resumes playback. On my custom WPS, it still shows “paused”, but the counters do count and it does play the music. If I hit pause/play, it will change the status of playback only, but does not affect actual playback. Hitting pause/play once again will pause playback.

This is not a new bug to me. When I last encountered it, I downloaded the latest source and built it on my build server, and it appeared to be fix. Unfortunately, I don’t have build releases and dates to back this up.

Closed by  linusnielsen
2007-07-05 11:18
Reason for closing:  Fixed
nls commented on 2007-06-04 16:24

Confirmed on H320 with svn r13533

This seems to be intermittant. Results with conditions:

Bug occured while only thing plugged into it was headphones.

Bug occured while nothing plugged in (plug in headphones or speakers later to hear playback).

Bug did not occur while plugged into car charger adapter (everything worked properly).

So far the pattern is the bug happens when nothing is plugged into the accessory/power port.

I am also seeing the same problem with both my iPod 5.5G and my iPod Nano with the current SVN build from 5 Jun 10:11.

Unfortunately there is no longer a pattern to this problem as it occured while plugged into my car adapter today. It’s like it maybe stores the state, maybe doesn’t. Russian roulette if you will.

It happens here reliably on my H340 (no car mode in use). It also happens in the sim, but I think that’s due to a separate problem.

It also happens here every time on both my iPod nano and 5.5G iPod video.
I have not tested on my h140 as I have lent it to a friend,
but I can get it back to test on as well if it would help.

The problem also happens if I fast forward when pause as well as rewind on both DAPS.

Confirmed on Cowon IAudio X5 with rockbox-iaudiox5-20070624

MikeS commented on 2007-06-26 02:34

I think it’s just a problem on SWCODEC in general and happens on all my players. I’m not sure why it happens but I did check and it doesn’t seem to be a bug in the playback engine but likely in the pcm buffer perhaps due to some refilling triggering pcm playback. I plan on taking a closer look later.

After a lot of testing this morning looking for the commit that caused ‘“Pause on Headphone unplug” option no longer works on IPods.’ (http://www.rockbox.org/tracker/task/7261) I think I have also found the commit that seems to causes this bug.

“19 May 19:30 Marcoen Hirschberg always reset the pcm_paused flag when stopping playback. fixes FS #7187”

As all builds tested before this commit do not show the rewind problem and all builds afterwards do.

obo commented on 2007-07-04 18:53

I don’t know if this is the right approach, but the attached fixes the problem for me (plus  FS#7261 ) and as far as I can tell doesn’t break the fix for  FS#7187 

Did you mean “pcm_paused = audio_status();” in playback.c? I’ve not tried the patch yet, just looked at it.

I’d think that it shouldn’t be necessary to actually test andr modify the pause status like this; can it not be regarded as independent of the stop/play status? There would need to be a different fix for  FS#7107 , of course, so as not to assume that the two are tied in.

MikeS commented on 2007-07-04 19:40

I’m right in the middle of redoing the pcm layer a bit for all targets to be atomic with locks against the audio interrupt and to give the pcm buffer its own play/paused state. This patch definitely isn’t the right approach for a permanent fix since the problem really lies deeply in the playback.c behavior (yes, I take back the above comment in part) and the way it tracks its state in combination with some kludges in pcm. The pcm layer cannot concern itself with the audio status since it’s something that can be used independently of core playback.

I can confirm that the patch seems to fix both bugs on my iPod nano and video 5.5G.

That playback code really should read “pcm_paused = false;”. audio_status() doesn’t return a bool for starters.

obo commented on 2007-07-05 09:41

Sorry, yes, it should. The change to pcm_playback.c was a remnant of me playing around, it should have been the same change as the other files. But as Michael said, it’s not the right way of fixing it anyway.

Project Manager

However, we could fix it with this patch until Michael does it the right way.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing