Rockbox

Please at least include a full description of the bug in your bug reports. Don't require that someone click through to another site just to find out what it is you're even reporting - there's no guarantee in the future that the site will be there, or up, or that the threads won't move.

Fair enough, hadn't though of that.

______________________________________________________________________________

Postcount 4 (nue);
Thanks for the responses. But I'm afraid I'll have to derail my original post even further. Better to do that than start a new thread eh?

Anyway, last question; is it possible to utilize hold? I see the option to toggle back light during hold but how do you get into "hold" status in the first place?

EDIT: I lied. Playback appears to be incredibly wonky? Seems like it actually slows down? Was doing A to B comparisons with computer and noticed that it actually slows down. Used a stopwatch to verify the speeds and so it appears that the clip is slowly but surely slowing down. Strange that the clock is still consistent though on the clip. Files tested were 320kb CBR, V2 VBR, and a FLAC file.

Okay so trying out said FLAC file in OF, it seems that it's slightly sped up. =(

______________________________________________________________________________

Postcount 14 (me, sunami88)
RB: r26480-100602 - OF:01.02.15A

My tests were anything but scientific, but I did get a slight difference. Seemed to be about a full second difference to every minute of play. I started off with a 30 second sample and figured that about a half second could've just been my finger on the play/pause button. So I went up to a minute and yep, seemed to be a full second.

I can't hear it with my ears, but if I sit down with a stopwatch and my Clip+ there does seem to be a variation in play speed between the OF and RB...

EDIT
I should mention too, this is using a FLAC file off the internal memory.

______________________________________________________________________________

So does playback "slow down" or is it just simply always slow? What are you describing here?

Please, take the time to explain the expected behavior and the actual behavior - are you simply comparing the OF to Rockbox (if so, how do you know the OF isn't playing the wrong speed?) or are you comparing Rockbox to something "known good"?

These are bug reports, so please be thorough - build, player, exact details of what's happening, etc. You even copied and pasted something about use of a hold switch? Is that related somehow, or just something you didn't bother to remove? I don't know if I should assume it's not important and just something you didn't choose to erase, or something that is important because you chose to include it, that I don't understand at all.

It is always slow. And I am comparing the OF to Rockbox, and I can't be sure which is at fault (figured it could use some investigating, as like I said supposedly the OF is playing 1:1).

Like I said, I got a stopwatch and after 30 seconds hit pause. Booted into the OF and did it again, and there was a half second discrepancy between when they stopped (in the song, not on the timer, the player always showed 0:30). I then went up to a full 60 seconds and the discrepancy increased another interval of about a half a second (so a full second now)

Player is included in the bug title, as well as the quotes (although it is not available in the drop down menu when submitting bugs). As is the Build Version in the description and the quotes.

I left the part before the edit in just so it would be complete, but will leave unrelated information out in the future.

I said "It is always slow". What I should've said was simply "The timing is always off", as I cannot be sure if either is playing faster or slower than the other, all I know is somewhere between RB and the OF, playback speed seems to be wrong

This only bears investigation if it's Rockbox at fault and not a problem with the OF. Could you confirm, perhaps via a longer file, that Rockbox plays at a different rate?

Or test by starting two long files simultaneously, one in Rockbox and one on a PC, then seeing if they're still in sync after some time?

That is also a week old build version, please always test with something recent. I just assumed that you were talking about a current build version and not a week out of date one since you posted the bug today - if that's really the version you tested on, you should confirm with a recent one. And again, against something other than the OF, even if it's as simple as seeing if a 4 hour long file ends in four hours. If it's slightly slow/fast, there should be a noticeable difference after several hours.

Paul Louden (Llorean): See in my description, this is using the version I updated to today. I will update right now and try again to be safe.

Also, between VLC on my laptop (made sure its at 1.00x speed), and my Clip+, RB does appear to be slower. The difference becomes quite pronounced even over a 2 minute test (one headphone in, plugged into my Clip+, and the speakers playing from my laptop).

As I said, your description only mentions "RB: r26480-100602" which is a week old.

The last sentence;
"I've tried this on the most recent daily, still happens."

Granted, that was from this morning, I'm updating to r26710 right now and I'll give it a try.

Yep- Still happening on r26710. The difference is quite immediate (after about 10 seconds the beats are noticeably different, ~60 seconds in it is about a full second off).

"The most recent daily" is still fairly nonspecific, which is why I asked for a version number. That's also why the dropdown for "daily" says "which?"

We also get people who think "The most recent daily" could refer to a build a week old (don't ask, some people really do have difficulty with the word 'daily') so it's important to get a version number in there.

Just for information, you couldn't have accidentally adjusted the playback speed setting? Could you try bumping it up or down, it might even allow you to figure out approximately how much our playback is off.

Rockbox is showing me 100% speed.

Bumping it to 101.2% gets incredibly close. I'll have to do some testing over a longer period of time but that seems to have it over a 60-second period

I should say again for clarities sake, this is using a FLAC off the internal memory. I'll try some testing with .mp3's as well...

The 320kbps CBR MP3 I just tried suffered from this "1.2% discrepancy" as well, though, 1.2% is just a guesstimate at this point.

Changed the title from "Clip(+): Playback discrepancy between OF and RB " to "Clip(+): Playback speed discrepancy between OF and RB "), adding the word "speed" to clarify

First, I think this problem only affects the sansa AMSv2 players, which are clipv2, clip+ and fuze v2, so not the clip (v1) for example.

As far as I know, for the AMSv2 players we don't know yet how to configure all of the clock signals, but we do know the setting to put the main PLL at 240 MHz and this is the one we currently use.
The clock signal for the audio output (MCLK) is derived from this PLL clock as follows: MCLK = (PLLclock / 128) / divider, where <divider> is some integer number to tune the playback speed.
To get at the 44100 Hz we use in rockbox, the divider should ideally be 42.52, but we can only set an integer number, so we round it to 43. This gives 1.136% error (too slow).

So, basically we cannot currently do much about this.
I don't know if/how the OF works around this. It could be that they resample everything to 48000 Hz (should be just 0.16% too fast), or maybe they use another PLL set up to some frequency that minimizes the playback rate error.

Damn, you're right. I can confirm the pitch bug on my FuzeV2 (r26689-100608, it's a day old)... Which is interesting seeing as how up until right now I hadn't noticed it at all (that nue has good ears).

Once again, going to 101.2% seems to have it, at least over ~60 seconds.

Until the voltages are set, couldn't the devs just add a config file option for Pitch (to set it at boot), or simply make the default pitch on the AMSv2 players +1.136%?

Would be an ugly solution from a coding standpoint, but it would work effectively (as far as I know, anyways).

And thanks for the insight bertrik, I'm surprised I got so close messing around in the pitch screen, haha.

The pitch screen reduces quality in other ways, so it's really not a solution. Remember, these targets aren't consider "finished" ports yet - things like this are to be expected, and the solution is to actually come up with a fix, not patch in workarounds.

Didn't mean to be obscene, was just a suggestion until the voltages can be found/fixed. I guess until then I'll just keep setting the Pitch when the music starts.

I'm also quite aware of what the "Unstable" at the top of "Unstable Ports" stands for, thank you. No suggestions from the peanut gallery, I get it.

I second the "user setting workararound", it would be enough adding a setting on .cfg files, as I was suggesting in a "features request" forum post. I already tried listening to music with 1,1% pitch correction and I noticed no degradation on sound quality.

Okay, again:

A config option for pitch should be considered independently of this. If it's a good idea, it's a good idea whether or not it helps this bug, and should be discussed in the context of players that do not have a bug that needs repairing.

Meanwhile, discussion of this bug should be in the context of getting this bug fixed, not looking at workarounds.