Rockbox

Can you try to find the exact revision? There was 2 changes between that possibly change playback behavior.

Also, please be more specific about the bug.
a) What files do you use
b) how long is the playlist
c) What do you exactly do when this bug appears?
d) Do you have a recipe to reproduce?

All files are vbr mp3 ~160kbps (everything has been ripped with the same compressor and settings).
The playlist is 1558 files long. When this happens I pause, and then resume and it's fixed. I'm afraid I can't give a recipe to reproduce this because it seems random and happened with different files. I'll try to gather more info the next time it happens (I'll look in the debug screen. If there is any information specially relevant please tell me).

The last rockbox version I used was compiled by me, so I'll look what revision It was when I get home.

Can you tell me what the "View buffering thread" screen shows when such the bug appears? You might even be able to screen shot it (by activating screen dump, then plug the USB cable in in the "View buffering thread" screen)

The next time it happens I'll do so.

Did it happen once more? If not, I'm inclined to believe that it was a random thing, which could be caused by bad tags in some rare condition.

I'll give it a week, if you don't experience this anymore, to close this.

I haven't used my ipod since the report (I didn't have time). Today I'll try to get the noise again and report at the end of the day. The day I filled the bug I got the noise again but screwed up when I tried to capture the buffering screen.

I am seeing the same thing with current svn builds with both my e200v1 and my ipod video 80GB.

If you disable fade on pause resume and start pausing the resuming with an mp3 you should see the problem quite quickly. All my mps3 are lame encoded vbr files.

I have not had a chance to grab a screen shot but buffering dose appear to stop from looking at the buffering screen and when playback resumes after pausing and resuming playback again playback jumps back by about a second the same word on my audio book played before pause is repeated.

It's weird. I still fail to experience this, and I use my player (e200) quite frequently, with different codecs and stuff.

>> "If you disable fade on pause resume and start pausing the resuming with an mp3 you should see the problem quite quickly"
Sorry, I didn't understand that sentence. The initial report claims it happens on track change.

If you go into settings - Playback Settings - Fade on Stop/Pause and select No.

Then select a directory full of vbr encoded mp3 you should be able to reproduce the problem by pressing play a few times to pause and resume playback.
I have also seen the problem on track change and first resume of playback after shut down on power saving but it dose not happen that often for me that way.

The problems first started for me after updating to get this fix http://svn.rockbox.org/viewvc.cgi?view=rev;revision=20081 as I was seeing crashes on the default wps if I tried to playback any albums with album art which needed to be rescaled. So I just used to use a theme without album art to work round this problem before, but I have now gone back to using the default theme again.

As such maybe you also need playing back an album with a cover.bmp file in the directory that needs to be rescaled to trigger the bug.

It appears to me that you're experience another issue.

In fact, I could reproduce your problem. BUT it's so hard to reproduce for me (in like 500 presses, it happend 3 times). It does never occur in every day use for me.

It would seem that the problem happens most often just a few seconds before or after a track transition if I pause and attempt to resume playback at that time.

I have now attached a screen shot of the buffering screen while the problem is occurring.

Doesn't look like a screenshot of the buffering though.

OK I sounded like the same issue to me as the playback progress counter also says stopped and I get noise played back instead of the selected track.

During a 40 minute car drive yesterday home from work the problem happened 3 times. I guess its all down to how you use rockbox and how often you pause and resume playback as I use the pause feature allot I guess I just trigger the bug more frequently.

doh wrong screen shot I will try again.

Looks normal to me. I'm unsure what triggers your bug. Is this only on the directory that data aborted pre-r20081 ?

I might have a clue about the initial bug though.

And here's 2 more screen shots as I just triggered the bug again while pausing playback to speak to someone.

one of the wps screen and a second one of the buffering screen.

No most directories with cover.bmp files that need to be scaled down to make them the right size for the wps and the problem happened with both my sansa e200 and my ipod video so it was not a hardware issue.

Again the issue tended to ether trigger on start up or when you changed tracks ether with the end of the track or manually selecting a new track from the file view as I dont use the database much I dont know if that is also effected.

From another task( FS#9979 ):

>From time to time during playback or when you pause playback and start it again WM8731 is fed with random data what you can hear as "digital noise". The "noise" stays until >you pause for the second time or rewind.
>
>I think the bug was introduced by r20052 (DMA for playback for PP502x targets) as I noticed it a few times since then. It was also confirmed by my friend, who uses H10 too.
>
>I currently use r20110.

It seems it was introduced earlier, before r20093.

I'm also having this problem. I've been mostly listening to audiobooks lately, most of mine are CBR encoded so I'm not sure that VBR matters (I could be wrong though). I also have no album art at all.

I've only noticed this since the last time I built rockbox: my build is derived from r20088. I too am at least somewhat inclined to suspect the DMA playback change :)

I think this is the same issue discussed in http://forums.rockbox.org/index.php?topic=20849 . It is related to the DMA playback change in r20052. The problem is in play_stop_pcm(). Too much can be subtracted from dma_play_data.size. Normally this is just a very slight error in the resume point, but it can cause dma_play_data.size to wrap around and become very big. I am attaching a patch which rewrites the PP502x DMA branch of that function. The patch works well for me, both in r20052 and r20211.

I am also attaching a separate patch which tries to trigger this bug. It is only meant to help testing, and is not meant for committing. After you start playback, from the main menu you can go to System -> Debug (Keep Out!) -> Pause unpause loop. That will keep pausing and unpausing playback, which makes it easier to see the problem. Hold the bottom button (ie. stop) to get out of that. When the bug was present I typically heard noise within a few minutes. After the next pause and resume I would typically have music again.

I hope you are not checking if an unsigned data type is <= 0, are you? (I think you are, size_t is unsigned).

Thomas:
Hehe, don't make fun of my silliness. :-p

Boris:
The patch aliases two conditions 1) Transfer finished 2) Transfer never got going. In the first case the pointer won't be incremented but it should be.
There is no concern about the interrupt in device level since pcm.c takes care of that synchronization itself.

There's some cruft in  FS#9910  in play_stop_pcm that wasn't updated properly for segmented transfers. Also, I"m wondering if the bits are not actually set atomically by the engine.

Oops, I failed to notice:
/* Tranfer was finished - DMA0_STATUS will have been reloaded
* automatically with size in DMA0_CMD. */
I need to examine and think about this some more.

It looks like I went rather daft on this one. Besides the cruft the transfer size limiting check in pcm_play_start was also wrong. The only things that ought to mess it up now is some super secret hardware surprise.

Throw in some misc. consistency changes for address and size rounding. Don't limit overall buffer size (quite pointless really when doing segments).

Thanks Mike! Patch seems solid.
Sorry about my earlier bad patch.