Glitchy audio after resume playback (split from: New USB mode questions)

[perrikwp]

As Saratoga noted earlier this can be found in wiki:

How to check out the source code

   svn co svn://svn.rockbox.org/rockbox/trunk rockbox

If you would like to use older sources use the -r parameter replacing YYYY-MM-DD with the appropriate date:

   svn checkout svn://svn.rockbox.org/rockbox/trunk -r {YYYY-MM-DD} rockbox

To check out a specific revision, use

   svn checkout svn://svn.rockbox.org/rockbox/trunk -r 12345 rockbox

A "rockbox" directory will be created in your current directory, and all the directories and source files go there.

and also:

To go back to a specific revision, use:

   svn update -r 12345

from http://www.rockbox.org/twiki/bin/view/Main/UsingSVN#How_to_check_out_the_source_code

[ThaCrip]

thanks for the reply perrikwp!

i think this will help me as it looks like you pinpointed mainly what i needed to know... but i wont know how it turns out til i try it and i think i setup the cygwin program properly.

but i guess ill get started now and possibly report back any issues i might have and hopefully i dont have issues this way i can start narrowing it down.

[dreamlayers]

Yeah, I've read that wiki page.  I was looking for a bandwidth-efficient way, so I don't have to check out the entire source code.

Now I see that is the bandwidth efficient way!  If SVN sees a rockbox subdirectory, it upgrades or downgrades it as needed.

Edit:  I'm hearing problems with r20052.   Now I'm going to try r20051.

[ThaCrip]

im sorta stuck cause even though those commands work like what was said above i don't exactly know how to make a compiled build that i can extract to test on my player.

any advice?

[dreamlayers]

See http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling

r20051 seems solid (and earlier I reported problems with r20052) so it seems the problem is due to using DMA for audio playback.  Next, I want to try r20052 at 80 Mhz.

I think that using DMA for audio playback is a good thing.  I hope we can get it working properly.

[ThaCrip]

@ dreamlayers ... thanks for the link and reply but im at the 'compiling the source code' > 'configuring build' section (which i assumed i needed to goto since i ran the commands in the above post from what's his name) and nothing really seems to happen.

but if dream layers is right... than i assume me trying to help is pointless now? lol

[dreamlayers]

@ThaCrip: What environment are you using to compile?  See http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling#What_You_Will_Need  Yeah, you don't really need to do this now.

80 Mhz doesn't help r20052.  I still hear problems.

[ThaCrip]

@ dreamlayers...

im using Cygwin but since you seemed to have narrow it down (if you did that was quick ) then i probably dont need to worry but i do think it's a good idea if you can somehow upload that build to some website (say yousendit.com ) and link me to those two builds to see if i can confirm anything you have said

[dreamlayers]

@ThaCrip:  If you run configure, you should get a menu of different player types.  If you don't get that, something is wrong with your Cygwin install.  When you're done with that you can run make.  When that finishes you can run make zip to get rockbox.zip, which you can install.

Here are 30GB 5th generation iPod builds:

r20051 build, should work

r20052 build, should fail eventually

Here's a patch that was added to those builds.  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, which makes it easier to see the problem.  Hold the bottom button (ie. stop) to get out of that.

[ThaCrip]

thanks for the builds BUT will these work on a Sansa e200 series also?

if not, any chance you could make those builds for a Sansa e200 series?

[Chronon]

I think 1024 would take up to 11 steps and 1023 would take up to 10.  

Not to be pedantic, but I think you got it backward.  The number of iterations is asymptotic to Log₂N - 1.  The  number of iterations for N=1024=2¹⁰ would be: # = Log₂(2¹⁰)-1 = 9.   

10 tests could take me 60 days since I had 1 failure in 6 days.  But it happeded again today, so 3.5 days per failure on average.  I don't understand why almost no one is posting known bad versions.

I understand.  Bugs like this can be troublesome to track down for this reason.  I will try to borrow my daughter's e250 if possible.

[dreamlayers]

thanks for the builds BUT will these work on a Sansa e200 series also?

if not, any chance you could make those builds for a Sansa e200 series?

Here are e200 builds:
http://drop.io/dreamlayers/asset/rockbox-e200-r20051-pauseunpause-zip
http://drop.io/dreamlayers/asset/rockbox-e200-r20052-pauseunpause-zip

[ThaCrip]

i am testing r20052 on my e250 with the pause/play loop and 'so far' it's not acting up, is there any general time frame it's expected to screw up in if it does act up?

also, if i recall when i was just using a recent version of Rockbox when i first noticed the sound glitch i seemed to have it paused for a good 30+seconds (maybe even 1minute or more) before resuming from what i can recall before it acted up... because i dont think it happened to me on a quick pause/resume from what i remember.... so assuming im right would that mean the 'pause/resume loop' option might not mean much since it might take a longer pause to get it to trigger the sound glitches?

p.s. and as im typing this the pause/resume loop has been going for a constant 5-7+minutes and so far it's not acting up at all for me.

EDIT: it's been going for a good 20+ minutes so far and it's not acting up on build r20052... so i think im going to stop this 'pause/resume loop' and see if i can manually trigger it with longer pauses etc, plus i think i remembered which song i was playing when i got one of those sound glitches, so i think ill test that out and then come back here.... also it was a MP3 when the sound glitch turned up as like i said before i primarily been using Rockbox on .ogg files if that matters and 'so far' i never got the sound glitch when playing .ogg files.

EDIT #2: i just got build r20052 to do that 'sound glitch' on the MP3 i got it to do it on before (seems like i had to leave the song paused for a good 1+minutes before resuming playback to get it to act up) ... now ill go test build r20051 and see if i can get that to act up... because if that dont act up that would mean it's changes between r20051 and r20052 that caused it to do the sound glitch, right?

EDIT 3: after more testing on r50052 and r50051 ... im starting to have reasonable confidence that the issue is between these two builds because here is what i did...

in the last hour or so i first started with r50052 and manually started pausing the mp3 file and trying to get it to 'sound glitch' and i did it within a reasonable time frame to as i got it to do it within around 5minutes which would usually require me pausing the song for a good 1+minutes before resuming from pause to get it to trigger, sometimes 2minutes or a little more...... then i switched to r50051 and could not get this one to act up within that same time frame or so.... then just to further make sure r50052 was not a fluke i went back to that build (r50052) and proceeded to recreate the 'sound glitch' and within roughly the same time frame (maybe a little longer) , using the pausing for 1-2minutes (or so) range and resuming from pause it plays fine for a brief second and then the sound glitch kicks in.... sometimes it would take a few attempts to get it to work though.

so basically it does seem to appear 'as of now' i can confirm dreamlayers comments about the 'sound glitch' being between r50051 and r50052 somewhere.

im going to keep playing with this stuff for around another half hour or so switching between r50051 and r50052 to make sure i can get reasonable consistency between the builds but 'as of now' it does appear dreamlayers is right.

EDIT #4 : well after attempting to do the 'sound glitch' for a third time in r50052 i cant seem to get it to do it and i was trying for roughly a good 20minutes or so when before i got it to act up within 10minutes tops 2 times.... but i guess at this point since i KNOW r50052 has the 'sound glitch' im probably just going to stick with using build r50051 for a while and see if it dont act up... if it dont, i would assume it must have something to do with the using of 'DMA for audio playback on PP502x' stuff since that appears to be the only change between r50051 and r50052..... just some thoughts

[dreamlayers]

Wow, ThaCrip, that's a lot of testing.  Thanks!

Regarding use of the pause unpause loop I added:  What I heard is bursts of perfect music, one burst of noise, and then more bursts of perfect music.  It seems that if one pauses again soon after a problematic unpause (like what that loop does), it's always possible to recover and get music again.  I did not find it too hard to notice these bursts of noise, but they're certainly not as obvious as lasting noise.

Edit: Here's a patch from r20051 to r20052:
http://drop.io/dreamlayers/asset/rockbox-20051-20052-patch

Edit2:  So far I've only figured out how to break things more.  If I comment out DMA interrupting code in play_stop_pcm(), pausing and unpausing never recovers; it just pauses and unpauses noise.  Stopping and resuming still fixes the problem then.

Edit3:  When noise is played, dma_play_data.size goes negative.

Edit4:  Since dma_play_data.size is of type size_t, that's not seen as negative.  Just making it a long seems to prevent the noise, but I suppose the root cause is that when pausing, .size and .addr may be changed twice, both by fiq_playback() and play_stop_pcm().

[AstroBoy]

I think 1024 would take up to 11 steps and 1023 would take up to 10.

Not to be pedantic, but I think you got it backward.  The number of iterations is asymptotic to Log₂N - 1.  The  number of iterations for N=1024=2¹⁰ would be: # = Log₂(2¹⁰)-1 = 9.   

We probably should start another thread!  
Your math is beyond me.  
With 1 sample, it takes 1 test to find a match.
2 to 3 samples take 2 tests at most.
4-7 take 3.
8-15 take 4.
16-31 take 5.
32-63 take 6.
64-127 take 7.
128-255 take 8.
256-511 take 9.
512-1023 take 10.

Now if the samples are contiguous, you would save 1 test I think.  If 3 was too low and 5 was too high you would know the answer was 4 without testing it.  But if 3 was good and 5 was bad, you would need to test 4 to see if it was good or bad.

wow, I exceeded the smiley limit! !!