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

[Llorean]

You've been told this before. "u" is not a word, you need to type out "you" in our forums. We ask that you use proper English spellings at the very least.

You probably want to start earlier than the first build that supports USB, as it may be from changes somewhat before that. As well, the builds available for download are only once a day. At some point you're going to need to compile builds to get more precise, so you may as well learn how now so that you can pick any build revision you want.

[ThaCrip]

You've been told this before. "u" is not a word, you need to type out "you" in our forums. We ask that you use proper English spellings at the very least.

You probably want to start earlier than the first build that supports USB, as it may be from changes somewhat before that. As well, the builds available for download are only once a day. At some point you're going to need to compile builds to get more precise, so you may as well learn how now so that you can pick any build revision you want.

Yes your right, sorry about that 'u' instead of 'You' as i got into a habit of doing that sorta stuff as it speeds up typing a little. (i edited the post and corrected it )

but anyways....

i guess i could start before USB was implemented but if i recall correctly the 'USB Test Build' (just before it was officially in the 'current builds') worked fine, but to be honest i dont know if i used that enough to know with reasonable certainty if the issue was there or not.... but then again when i did notice that recently (in the last few days or so) i was on a small trip of probably no more than 15minutes 1-way (maybe 30-40minutes round trip) and it acted up once on the way there and once on the way back. and like someone else said i think at least one of those times i had it on pause for roughly a minute or two and when i resumed from pause it started the issue i been explaining.

but if possible... what was the build that USB was first enabled on 'officially' in the current builds section? ... main reason i ask is because i would rather not go prior to that unless i have to due to using the new bootloader. that's why i figured that build is a good place to start to give me a good idea on which direction to go, be it prior to USB support or builds after it.

also, if you dont mind any advice on where i should start as far as compiling my own builds? (as i typed this message i did not search at all yet so i guess i could get started ... i just figure with a little push in the right direction that would help speed things along a little bit )

EDIT: i assume this ( http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling ) is a good place to start?

EDIT#2: i think i got that Cygwin thing installed... any advice on how to build exact versions? (because i assumed you needed me to test r20100/r20101/r20102 and so on until i think i located the build where the sound glitch dont exist)

[AstroBoy]

You've been told this before. "u" is not a word, you need to type out "you" in our forums. We ask that you use proper English spellings at the very least.

You probably want to start earlier than the first build that supports USB, as it may be from changes somewhat before that. As well, the builds available for download are only once a day. At some point you're going to need to compile builds to get more precise, so you may as well learn how now so that you can pick any build revision you want.

Give me a hint.  What version do you want me to start with?  Go back 1 month?  or 2 months?  Maybe 1 week?

Please, anyone with the problem, please post your version!!  We don't need to be testing the same version or a version after the bug.

[Chronon]

Binary search:
1) Pick an initial build that's long enough ago to not have this bug.
2) Verify that it doesn't exhibit the bug
3) Make a build that's halfway between that build and the current build.
4a) If it contains the bug then make a build halfway between that build and the initial one.
4b) If it doesn't contain the bug then make a build halfway between that build and the current one.
5) Repeat the process until you find the build where the bug begins.

To give you an idea of how much time this may take, for a set of 1024 revisions this will give the result in 10 steps.

Unfortunately, my e280 is currently AWOL so I cannot help test for the time being.

[ThaCrip]

thanks Chronon for the advice but the question i have is...

what's the first build that supports USB AND how do i build exact build versions with that Cygwin? , because as far as i can tell in the stuff i read it dont really mention this. i would seriously like to help but as of now i cant really help since i dont really know how to build specific versions etc.

http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling (i used that to get the basic thing setup)

[ryran]

For the record, there are tons of posts on the forum on what is likely the exact same thing you all are talking about: glitchy ear-shattering craziness. I've had it happen occasionally on my ipods ever since I started using rockbox back when it was first ported.

I can't say with certainty that it's been happening more lately, but I've definitely seen it a few times in the last week (at least twice after resuming from a pause).

PS: Also, from my perspective the controls-being-locked-after-reaching-end-of-playlist feature has been there for about the last year. Annoying. But I haven't had time to complain.

[ThaCrip]

@ Ryran ... i dont know the details but is the IPOD different hardware vs the Sansa e200 series? ... because like i say i never had this issue at all on Rockbox up until fairly recently... i know v3.1 release version never did it to me (and prior to that) and it's to hard to tell when the static issue thing came into play because i was using Rockbox v3.1 up until recently (the last week or two) when i learned of USB support and new bootloaders for my player, so then i updated and then ran into the glitch.

[Llorean]

@ryran - Is there a bug report filed on this locking controls thing?

[cool_walking_]

I just heard that glitchy ear-shattering craziness yesterday, for the first time ever.  While I connected the USB plug, there was a song playing.  Upon disconnecting the iPod, playback was paused at the place I left it, so I resumed and got an earful of some highly experimental noise music.  I paused and resumed, hoping that would fix it, but it didn't.  I then fast-forwarded a few seconds, and normal playback resumed.  I wasn't paying attention, and my memory is pretty bad, so it might not have happened exactly like that.

Maybe this is FS#9949.

[saratoga]

thanks Chronon for the advice but the question i have is...

what's the first build that supports USB AND how do i build exact build versions with that Cygwin? , because as far as i can tell in the stuff i read it dont really mention this.

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

[cool_walking_]

The first build in which USB was *enabled by default for particular PortalPlayer targets* was r20105.

[dreamlayers]

With unmodified r20205, I am able to get noise, screeching and stalls of playback by repeatedly pausing and resuming playback.   However, this is extremely rare.

Another important release to consider is "r20052: Use DMA for audio playback on PP502x".

[AstroBoy]

Binary search:
1) Pick an initial build that's long enough ago to not have this bug.
2) Verify that it doesn't exhibit the bug
3) Make a build that's halfway between that build and the current build.
4a) If it contains the bug then make a build halfway between that build and the initial one.
4b) If it doesn't contain the bug then make a build halfway between that build and the current one.
5) Repeat the process until you find the build where the bug begins.

To give you an idea of how much time this may take, for a set of 1024 revisions this will give the result in 10 steps.

Unfortunately, my e280 is currently AWOL so I cannot help test for the time being.

I think 1024 would take up to 11 steps and 1023 would take up to 10.    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 found the archives here: http://www.rockbox.org/dl.cgi?bin=sansae200
I will test the oldest archive I could find, rockbox-sansae200-20090201.

The only known bad versions are: r20107-090225, r20205

Maybe we should consider the release that added support for the 2 cores?  I don't know what version that is.

[ThaCrip]

astroboy said, "Maybe we should consider the release that added support for the 2 cores?  I don't know what version that is."

i dont think that's the problem because im pretty sure 'both cores' where supported in v3.1 release version and i never had a issue BUT i was primarily using .ogg files on that and not .mp3 files so maybe it's mp3 related specifically.

but i must mention this as it might have some relevance...

in general since i got my Sansa running Rockbox is that i was pretty much using .ogg audio files... but when i got that sound skipping stuff as other's have said it was in .mp3 format (most of the files has the vbr of around 192kbps (the ones that vary from 128kbps to 320kbps ... Lame encoded) ... so to my knowledge i never seen that 'sound issues' when playing .ogg files. (ogg files bit rates are around 45-60kbps if that matters at all)

and like i said before... i cant start testing different builds until i find out how to compile specific versions which i cant find out how that's done so far.... if anyone knows it would be nice if you could give me a push in the right direction

[dreamlayers]

Okay, how about this:  add a debug menu entry which pauses playback, sleeps, unpauses playback, sleeps, etc.  Then listen to that or better yet record the audio and look at its spectrum later.  If you play a continuous tone, software or a PLL chip could easily auto-detect failures, but it may not be necessary to go that far.

I have a 30GB 5G iPod, so I guess this is a PP502x issue.

Edit:  Yeah, this seems like a good idea.  I got two failures in one song already.  Time to use old versions.  Is there some bandwidth-efficient way to get the source to old versions?