Bugzilla – Bug 1663
sample rate changes too soon
Last modified: 2009-09-08 09:19:08 UTC
Stream two files, one recorded at a sample rate 48K then follow it with a file at 44.1K. Approximately one second before then end of the 48K file (buffer size?), the pitch changes downward as it anticipates the sample rate of the next file, which is at a lower sample rate. Problem occurs with FLAC files streamed as FLAC to a SB2. Did not test other encoding / decoding options or players.
Chuck: do you have crossfading turned on?
No, crossfading isn't on. The player (SB2) is the only player on the server and the player has Crossfade set to "None" with a duration of "0". I should add, to be complete, that the pitch will also go up if the current file is 44.1K and the next file is 48K. The duration that the pitch changes varies with the file, from a 1 second to a 3 second duration. Or at least it seems that way without measuring it, so that's also why I thought it was a "buffer" related thing (where the "buffer" would be the last block in the file or expand to a different amount depending on compression ratio). Also, I see this when set to Shuffle/Songs mode. Didn't try any other settings.
Somehow the "remaining time" play info was running on the display today and I noticed that whenever the sample rate and pitch changed, the progress bar simultaneously changed its estimate of how long the file is and where it is in the file (it should always be near or at the end). I thought the "remaining time" display is sent by the server, in which case the server could be causing the problem instead/also. Just an additional clue...
I'm definitely interested in getting this fixed soon, but I don't think it will make it in for 6.1.
An additional observation: I have been "listening" to this bug for a while now, and I can say that I was mistaken, it never occurs when going 48K to 44.1 only when going 44.1 to 48K. It is uni-directional. The pitch will change upward at the end of a 44.1K sample FLAC file when the next file to be played is sampled at 48K. I have never heard the pitch go downward (it also does a quick mute in between the pitch and sample rate change). Sorry for the confusion...
Vidur: what do you think is going on here?
Some more observations: I heard it happen again today with an MP3 file (sampled at 44.1K) which was followed by a 48K rate FLAC file and the pitch went up. Seems like format doesn't matter, just sample rate. I happend to have the "show buffer fullness" config option turned on today and the player went from 100% progressively down to 20%..12%..0% and exactly when it went to 0% the pitch change occured. The buffer fullness then started counting up again (like it always does at a song ending), the song ended (with the wrong pitch) and it went back up to 100% with the new song. I don't recall any other time that "buffer fullness" goes to 0%. In other words, it seems closely related to whatever measures or drives "buffer fullness".
Note to self: Add this line: current_sample_rate = pcm_sample_rates[(params[1] - '0')]; to decode_flac_start... and then set the sample rate inthe start command
This is going to have to wait until the 6.2.1 release.
Alas, no firmware update for 6.2.1, will have to do for 6.5
I think this problem was related to bug 3303, fixed in Firmware 54. I have just been listening a play list with mixed 44.1k and 48k FLAC tracks and did not hear a pitch change when the buffer fullness reached 0%. Richard
Yes, as reporter of the bug, and I haven't performed formal testing, but I believe the firmware update fixed it...
This bug appears to have been fixed in the latest release! If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look. Make sure to include the version number of the software you are seeing the error with.