Support and General Use > Audio Playback, Database and Playlists
Glitchy audio after resume playback (split from: New USB mode questions)
Chronon:
--- Quote from: AstroBoy on March 05, 2009, 12:21:01 AM ---I think 1024 would take up to 11 steps and 1023 would take up to 10. :)
--- End quote ---
Not to be pedantic, but I think you got it backward. The number of iterations is asymptotic to Log2N - 1. The number of iterations for N=1024=210 would be: # = Log2(210)-1 = 9. ;)
--- Quote ---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.
--- End quote ---
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:
--- Quote from: ThaCrip on March 05, 2009, 02:45:13 AM ---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?
--- End quote ---
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:
--- Quote from: Chronon on March 05, 2009, 03:06:18 AM ---
--- Quote from: AstroBoy on March 05, 2009, 12:21:01 AM ---I think 1024 would take up to 11 steps and 1023 would take up to 10.
--- End quote ---
Not to be pedantic, but I think you got it backward. The number of iterations is asymptotic to Log2N - 1. The number of iterations for N=1024=210 would be: # = Log2(210)-1 = 9. ;)
--- End quote ---
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! !!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version