Bug 12819 - Pop heard when sample rate changes
: Pop heard when sample rate changes
Status: NEW
Product: SB Radio
Classification: Unclassified
Component: Audio
: Include FW version in comment
: PC Windows XP
: -- normal (vote)
: ---
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-12 09:52 UTC by Mickey Gee
Modified: 2011-11-06 23:24 UTC (History)
0 users

See Also:
Category: ---


Attachments
MP3 track with initial pop (825.75 KB, audio/mpeg)
2009-07-14 17:16 UTC, Mickey Gee
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mickey Gee 2009-07-12 09:52:50 UTC
With firmware r6526, a pop or crack is sometimes heard when I start playing an MP3 track. I think it happens more often if the track right before it is FLAC. I don't have any other track formats, so I can't try it with others.

Doesn't seem to happen if previous track is MP3.
Comment 1 Richard Titmuss 2009-07-14 12:11:03 UTC
I'm guessing this is really about sample rate changing in a playlist, not format type.
Comment 2 Mickey Gee 2009-07-14 17:16:39 UTC
Created attachment 5461 [details]
MP3 track with initial pop

Try this track. Maybe created at 48KHz sample rate?
Comment 3 Richard Titmuss 2009-07-20 07:52:04 UTC
Fixed in baby-mp r6677. I am not happy with the fix, it's more a work around and may suggest some underlying problem. Caleb could you take a look at this, you'll need to remove the imx-unmute-after-ssi-enable-hack.patch from the kernel.
Comment 4 Caleb Crome 2009-07-21 15:53:32 UTC
I think this is a 7.4 bug, since the current solution works well enough for CAT and CX.
Comment 5 Richard Titmuss 2009-07-27 01:09:47 UTC
Reset priority before triage.
Comment 6 Ben Klaas 2009-08-26 07:54:01 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 7 James Richardson 2009-10-15 09:27:35 UTC
Re-Targeting bugs that did not make it into 7.4.0 release
Comment 8 Chris Owens 2009-10-21 09:48:15 UTC
Moving these bugs to P4 to make room for moving P1.5 bugs to P2
Comment 9 Pat Ransil 2009-10-23 05:10:03 UTC
Administrative move of 7.5 bugs. All P2, P3, P4 being downgraded one level. Will then split P1s.
Comment 10 Chris Owens 2010-03-08 11:26:55 UTC
Moving lower-priority bugs to next target
Comment 11 Alan Young 2011-11-06 23:24:37 UTC
Unassigned bugs cannot have a priority.