After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 436192 - Some tracks have cracking
Some tracks have cracking
Status: RESOLVED NOTGNOME
Product: rhythmbox
Classification: Other
Component: playback
HEAD
Other All
: Normal major
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 447678 451570 459866 482207 486195 486668 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-05-05 20:17 UTC by Rory McCann
Modified: 2007-10-15 10:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A short (10sec) sample of a song that crackles (161.99 KB, application/octet-stream)
2007-05-05 20:19 UTC, Rory McCann
  Details
Tentative workaround: add a volume element in the output pipeline (1.71 KB, patch)
2007-10-11 12:42 UTC, Loïc Minier
none Details | Review
16-bits wide sample (converted Ubuntu logout sound) (310.10 KB, audio/x-wav)
2007-10-11 19:06 UTC, Loïc Minier
  Details
32-bits wide sample (converted Ubuntu logout sound) (620.16 KB, audio/x-wav)
2007-10-11 19:09 UTC, Loïc Minier
  Details

Description Rory McCann 2007-05-05 20:17:24 UTC
Please describe the problem:
When rhythmbox is playing some songs there is a noticable cracking sound at parts. It's always the same parts and it sounds like using faulty earphones. The song plays normally when played with mplayer or with gst-launch playbin url=file:///path/to/file

Steps to reproduce:
Play the song

Actual results:
The song plays but crackles

Expected results:
Like every other media player, it should play without crackles

Does this happen every time?
Yes, always in the same position in the same song

Other information:
It happens with OGG and MP3 files.
Comment 1 Rory McCann 2007-05-05 20:19:19 UTC
Created attachment 87621 [details]
A short (10sec) sample of a song that crackles

When playing this clip in rhythmbox, there is some crackling. When playing it in Gstreamer totem, mplayer or with gst-tools playbin, there is no crackling.

The original was a MP3 and the same problem happened, this was transcoded to OGG and the same crackles are heard in the same place.
Comment 2 Jonathan Matthew 2007-05-05 23:43:11 UTC
Are you using the crossfading player backend?  If so, does the crackling occur when the crossfading backend is disabled?
Comment 3 Rory McCann 2007-05-06 10:39:20 UTC
I had never used crossfade. But when I turn it on, the crackling doesn't happen. So it only crackles when the crossfade is disabled.
Comment 4 Jonathan Matthew 2007-05-06 11:03:33 UTC
Very strange.  Which rhythmbox plugins do you have enabled?
Comment 5 Christophe Fergeau 2007-05-06 11:36:37 UTC
Someone on IRC complained about the same issue:

<DarkMageZ> hmm, interesting bug here. on a particular song with svn 5089 with replaygain disabled. with the normal backend. i get crackling, but if i use the new experimental backend, no crackling.
<moch> bug 436192
<DarkMageZ> sounds like my situation
<DarkMageZ> i have daap & jamendo & last.fm & visualization enabled

<teuf> DarkMageZ: do you get that with gst-launch?
<DarkMageZ> nope
<DarkMageZ> neither with totem (using the same gstreamer binaries)
<teuf> k

<teuf> DarkMageZ: does that happen if you disable all those plugins?
<DarkMageZ> yes it continues to happen with them disabled

<teuf> DarkMageZ: any idea if you got a gstreamer upgrade recently? 
<DarkMageZ> i should be uptodate feisty
<DarkMageZ> i rebuilt my rhythmbox just afew minutes ago.
<DarkMageZ> yup, i'm currently running feisty's gstreamer packages. none of my dirty hacks.
<teuf> ok

<teuf> any idea if that happens with the rb shipped with feisty ?
<DarkMageZ> i'll downgrade. sec
<DarkMageZ> the only altered packages installed that i can think of which could possibly affect rhythmbox is my altered gtk packages which fix the column resize bug.
<DarkMageZ> feisty's rhythmbox doesn't appear to suffer from the bug
Comment 6 Jonathan Matthew 2007-05-06 13:11:54 UTC
We've narrowed this down to the audioconvert element that rhythmbox trunk adds to the pipeline to allow audio filter elements to be inserted.

With no filters or tees added, the sink bin we pass to playbin looks like this:  audioconvert ! tee ! queue ! gconfaudiosink
replacing the audioconvert with identity fixes the crackling.  It also seems like it only occurs when the playbin volume is set to 1.0 (or maybe just close to it).

This might well be the same issue as bug 420079.
Comment 7 Richard Edmands 2007-05-12 01:24:50 UTC
after testing the patch from upstream. i'm thinking it's not that bug.
Comment 8 Sebastian Dröge (slomo) 2007-05-14 16:15:23 UTC
I don't think this will be fixed by my patch to audioconvert.

Your sink bin for playbin doesn't make much sense btw, playbin already does something like "src ! decodebin ! audioconvert ! audioresample ! audioconvert ! sink" so your audioconvert element in there is useless (and shouldn't cause any problems).

No idea what exactly is causing this crackling, I never experienced it myself.
Comment 9 Benjamin Lebsanft 2007-05-27 06:58:11 UTC
I can confirm this bug, happens to me on vorbis and musepack files, mp3 and flac are fine.
Comment 10 Jeff Waugh 2007-06-14 10:11:05 UTC
Confirm: Doesn't happen with mplayer or basic gst-launch playbin. Does happen with Rhythmbox 0.11, doesn't happen with crossfading enabled. All file types. Same issue on my laptop (analogue) and desktop (spdif).
Comment 11 Christophe Fergeau 2007-06-14 21:05:43 UTC
*** Bug 447678 has been marked as a duplicate of this bug. ***
Comment 12 Tom Kirby 2007-06-24 18:25:04 UTC
I got this problem when I had the volume in RB set very high. Not sure if it still affects me.
Comment 13 Ralf.Nieuwenhuijsen 2007-07-19 14:15:24 UTC
I can confirm this bug too. Thankfully, it goes away when i use the crossfading plugin. It doesn't happen with totem and mplayer.

It is most noticeable on amplified guitar music and heavy beats. (so, i'm guessing the lower tones).  

If above sample is not enough to set this to confirmed, then I can also create a sample. Are there people that do not experience this bug with the above sample and crossfading disabled?
Comment 14 Jonathan Matthew 2007-07-24 11:27:59 UTC
*** Bug 459866 has been marked as a duplicate of this bug. ***
Comment 15 Jonathan Matthew 2007-07-24 11:31:17 UTC
*** Bug 451570 has been marked as a duplicate of this bug. ***
Comment 16 Cosimo Cecchi 2007-07-24 11:38:22 UTC
I can also confirm this both on Ubuntu Gutsy and Gentoo (different machines and soundcard also), using RB 0.11. Also, i can reproduce this even with crossfading enabled.
Comment 17 Sebastien Bacher 2007-07-27 09:00:55 UTC
Ubuntu bug about that on https://bugs.launchpad.net/rhythmbox/+bug/127593

"Binary package hint: rhythmbox

I'm on 7.10 tribe 3; when rhythmbox is used to play Ogg Vorbis files, you hear cracking sounds during playback; this does not happen on other gstreamer based applications like Movie Player.
...
I've just tried to play the same files after checking "Use crossfading backend" in Preferences, and the noise has disappeared.
...
Same here: oggs are crackly when "Use cross fading backend" is not enabled.
..."
Comment 18 David Mansfield 2007-09-19 20:32:47 UTC
me too:

for me, on fedora 7, gstreamer-0.10.13-0.1.fc7, i get crackling with:

gst-launch filesrc location=foo.mp3 ! mad ! alsasink 

but no crackling with

gst-launch playbin uri=file:///foo.mp3

same mixer settings, everything else etc.

Oddly, despite the audio 'clipping' apparent in the output, the actual output volume to the speaker/ear is identical.  this seems to indicate the clipping is happening due to some arithmetic overflow in the software, and not in the actual alsa/hardware.


Comment 19 Adam Williamson 2007-09-28 20:34:26 UTC
Has just been reported in Mandriva Linux 2008 (pre-release), we're on Rhythmbox 0.11.2.

Mandriva bug report:

http://qa.mandriva.com/show_bug.cgi?id=33908
Comment 20 Christophe Fergeau 2007-10-01 14:49:27 UTC
*** Bug 482207 has been marked as a duplicate of this bug. ***
Comment 21 Loïc Minier 2007-10-11 12:42:47 UTC
Created attachment 97052 [details] [review]
Tentative workaround: add a volume element in the output pipeline

Hi,

I proposed the following short term workaround in the Launchpad bug as some people confirmed that the crackling would disappear with "volume volume=1.0" in the test pipelines: this seems to help caps negociation to select 16 bits signed which pleases alsa.

Bye,
Comment 22 Christophe Fergeau 2007-10-11 12:47:58 UTC
Here is the relevant comment in launchpad https://bugs.edge.launchpad.net/ubuntu/+source/rhythmbox/+bug/116990/comments/43
Filtered caps would have been a nicer workaround imo ;)
Comment 23 Loïc Minier 2007-10-11 13:01:28 UTC
(In reply to comment #22)
> Here is the relevant comment in launchpad
> https://bugs.edge.launchpad.net/ubuntu/+source/rhythmbox/+bug/116990/comments/43
> Filtered caps would have been a nicer workaround imo ;)

That's what I thought initially as well, but at least the volume element can be expected to work with multiple caps, while if we force the caps then negociation might fail altogether.

So using volume to "help" but not "force" negociation seemed a less intrusive workaround.  But perhaps there's a way to hint negociation without forcing the caps, it this what you meant?
Comment 24 Jonathan Matthew 2007-10-11 14:33:49 UTC
As near as I can tell, the distortion is introduced if alsa has to do 32->16 bit conversion.  Adding this:

  audio/x-raw-int,width=32,depth=32

immediately before the sink still results in distortion; in this case, alsa is doing the 32->16 bit conversion.  Adding this fixes it:

  audio/x-raw-int,width=32,depth=32 ! audioconvert !  audio/x-raw-int,width=16,depth=16

as in this case, GStreamer does the conversion.  Everything up to that point should be the same in both those cases, so I think this means we can safely blame alsa.

Anyway, looking at the other audio sink elements, nothing else supports 32bit int audio, so it should be OK to add a capsfilter with 'audio/x-raw-float;audio/x-raw-int,width=16,depth=16' (or however you say that) caps before the sink.  People who have >16 bit sound devices would be somewhat out of luck.

This is more or less the same as adding a volume element, except it'll still work with gst-plugins-base >0.10.14, where volume supports 8, 24, and 32 bit int data.
Comment 25 David Mansfield 2007-10-11 14:54:31 UTC
is it possible that the problem is that the signed/unsigned handling is broken for 32 bit or that sign extension is a problem?  i've seen that before when using 32bit.  in this case, it COULD still be gstreamer problem.
Comment 26 Loïc Minier 2007-10-11 15:53:07 UTC
While I also think this is likely an alsa problem (for example 32-bits output works fine here), I can not say I'm 100% about it; and as Jonathan put it: some people might have 32-bits only sound devices, and at least for them a capsfilter would break playback, while a volume element will in the worst case do nothing to help.

Anyway, we're discussing workarounds (and it might be interesting to make rhythmbox more solid against borken hardware), but does anyone know of an ALSA app which could help submitters test their sound driver in 32-bits and 16-bits mode?  Would be better than GStreamer pipelines where we never now whether it's really ALSA or GStreamer.

I had a look at aplay, but it seems to only allow setting of wav file parameters, not of the output sound devices.
Comment 27 Sebastian Dröge (slomo) 2007-10-11 18:02:32 UTC
Well, then create 32 bit (etc) wav files for the submitters :)
gst-launch-0.10 audiotestsrc num-buffers=300 ! audioconvert ! "audio/x-raw-int,width=32,depth=32" ! wavenc ! filesink location=test-32.wav

and the same for 16 bits and whatever...
Comment 28 Loïc Minier 2007-10-11 18:56:40 UTC
(In reply to comment #27)
> Well, then create 32 bit (etc) wav files for the submitters :)
> gst-launch-0.10 audiotestsrc num-buffers=300 ! audioconvert !
> "audio/x-raw-int,width=32,depth=32" ! wavenc ! filesink location=test-32.wav
> 
> and the same for 16 bits and whatever...

Heh, yeah, that should do!  I was looking for a way to let people choose their test file as some people said it depends on what you listen to, but it's way simpler to hand them sound files indeed!
Comment 29 Loïc Minier 2007-10-11 19:06:34 UTC
Created attachment 97079 [details]
16-bits wide sample (converted Ubuntu logout sound)
Comment 30 Loïc Minier 2007-10-11 19:09:38 UTC
Created attachment 97080 [details]
32-bits wide sample (converted Ubuntu logout sound)

Could people experiencing the bug please test:
aplay test-16.wav
aplay test-32.wav
and confirm whether one of the command outputs crackling while the other doesn't?

If that's the case, what's your alsa driver? (lsmod | grep snd)

NB: I checked with ltrace, and aplay successfully sets 16 and 32-bits sample sizes as returned by snd_pcm_format_physical_width().
Comment 31 Jonathan Matthew 2007-10-11 23:04:10 UTC
The 32bit file doesn't get distorted because its amplitude is too low.

I've extracted a portion of a track that gets distorted and converted it to 16bit and 32bit pcm .wav.  When played through aplay, the 32bit sample is distorted.  

Comparing the waveforms in audacity shows no visible difference.  When played in audacity (through alsa), the 32bit sample is distorted.  When converted to 16bit in audacity, the sample is no longer distorted.
Comment 32 Loïc Minier 2007-10-12 07:10:26 UTC
(In reply to comment #31)
> I've extracted a portion of a track that gets distorted and converted it to
> 16bit and 32bit pcm .wav.  When played through aplay, the 32bit sample is
> distorted.  
> 
> Comparing the waveforms in audacity shows no visible difference.  When played
> in audacity (through alsa), the 32bit sample is distorted.  When converted to
> 16bit in audacity, the sample is no longer distorted.

Great; what's your sound hardware?  What's your ALSA module?  I'd like to forward this to the ALSA folks; I hope this can be fixed soon or 32-bits output can be disabled on this hardware (if it supports 16-bits output).
Comment 33 Jonathan Matthew 2007-10-12 10:43:24 UTC
Downgrading to libasound2-1.0.13-2 (debian) fixes the distortion here.
Comment 34 Jonathan Matthew 2007-10-12 11:48:39 UTC
More specific: alsa-lib 1.0.14 with src/pcm/plugin_ops.h from alsa-lib 1.0.13 works OK.

They switched from simple bit shifts for converting between sample widths to this macro:

#define shift_down(val, bits) (((val) + (1 << ((bits) - 1))) >> (bits))

if 'val' is 32 bits wide and is stored in a 32 bit variable, the addition can cause overflow.
Comment 35 Loïc Minier 2007-10-12 21:12:55 UTC
Great!  Thanks a lot!  We'll probably fix this in ALSA before release.

Did anyone already file a bug at ALSA or should I?
Comment 36 Jonathan Matthew 2007-10-12 23:34:31 UTC
This ALSA bug looks like it's probably the same issue: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3360

I've added some notes there and a pointer to the commit that introduced the problem.
Comment 37 Jonathan Matthew 2007-10-13 00:08:38 UTC
*** Bug 486195 has been marked as a duplicate of this bug. ***
Comment 38 Johannes Berg 2007-10-14 20:11:47 UTC
*** Bug 486668 has been marked as a duplicate of this bug. ***
Comment 39 Jonathan Matthew 2007-10-15 10:55:03 UTC
I guess we don't need this bug open any more.