Upgrading ALSA and it's associated packages breaks rhythmbox. I've tried reemerging rhythmbox but that still doesn't fix it. Reproducible: Always Steps to Reproduce: 1. Check that the following packages are at these versions: media-libs/alsa-lib-1.0.5-r3 media-libs/alsa-oss-1.0.5 media-sound/alsa-utils-1.0.5 2. Install rhythmbox-0.8.5 3. Upgrade the aformentioned packages to these versions: media-libs/alsa-lib-1.0.6 media-sound/alsa-utils-1.0.6 media-libs/alsa-oss-1.0.6 4. Run rhythmbox and try to play an audio file or playlist Actual Results: rhythmbox crashes, on console, error is "Segmentation fault" Expected Results: it should have played the file/playlist successfully Portage 2.0.50-r11 (default-x86-2004.0, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6. 8-gentoo-r1) ================================================================= System uname: 2.6.8-gentoo-r1 i686 AMD Athlon(tm) XP Gentoo Base System version 1.4.16 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe -fprefetch-loop-arrays - ftracer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2 /share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/ config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/shar e/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf /xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -fomit-frame-pointer -pipe -fprefetch-loop-arrays -ftracer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox sfperms userpriv usersandbox" GENTOO_MIRRORS="" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X acl acpi alsa apm avi berkdb bitmap-fonts bonobo bzlib calendar caps cddb cdr chroot clanJavaScript clanVoice crypt ctype cups curl curlwrappers dba dbm dbx dga divx4linux droproot dv dvd dvdr encode esd exif fam flac flatfile foomat icdb fs ftp gd gdbm gif gimp gimpprint gmp gnome gnomedb gnutls gphoto2 gpm gstr eamer gtk gtk2 gtkhtml guile iconv ieee1394 imagemagick imap imlib inifile ipv6 jabber java jbig jce jp2 jpeg ladcca lcms libg++ libwww lzw mad maildir mbox md5 sum mhash mikmod mime mmx mmx2 mng mozilla moznocompose moznoirc moznomail mozp3 p mozsvg mpeg mpi music native ncurses network nls no_wxgtk1 nocd nomac odbc ogg vorbis opengl oss pam pcntl pcre pdf pdflib perl png posix ppds python quicktime radeon readline recode rtc sasl scanner sdl session sftplogging skey slang slp smime sockets speex spell sse sse2 ssl svg svga sysvipc tcltk tcpd tetex theora tidy tiff truetype unicode usb v4l2 video_cards_radeon wmf wxwin x86 xml2 xmlrpc xpm xprint xsl xv xvid xvmc zlib"
Created attachment 40407 [details] output from rhythmbox in debug mode
reemerging gstreamer, gst-plugins-alsa, and gst-plugins-oss doesn't fix the problem either.
alsa API/ABI breakage. sound herd, can't 1.0.6 stay be ~arch until this gets fixed ? It's impossible to keep up with those surfs (hell its supposed to be a stable series).
foser: I've put alsa-lib-1.0.6 back into ~arch until we can figure this out... but I am not entirely certain it is a problem with the public ALSA API changing... does rhythmbox mess with hidden internals that it shouldn't be?
it works with gstreamer 0.85 and gst-plugins-alsa 0.83
can the reporter or anyone that can reproduce post the exact output ? @ Jeremy : well, it's gstreamer then, not rhythmbox. I'm not sure it's alsa breakage at this point, but it's not unlikely seeing it's history.
I have had a similar crash with monkey-bubble 0.3.2, which I was able to strace back to gstreamer's initialization. Is it actually possible for open source developers to ever maintain a stable API? Better yet, could they design the API before coding the software?
Actually designing a well thought out API that meets all the needs of the community is very difficult to do before you actually start doing the coding once you get beyond a simple interface.
workin on it, recompiling alsa-* and going to run gst-launch-ext-0.8 /home/USERNAME/Music/SONG.flac w/ AUDIOSINK = "alsasink" in ~.gst Wish me luck!
emerged synced, did below, and no error! reemerged gstreamer, gst-plugins-alsa, and rhythmbox, and it all still works! I'm stumped, but happy :-)
I looked at the ALSA CVS repository, and the only change that I could see that might screw with things outside of the library involves the emu10k hwdep stuff. Basically, it looks like they added a bunch of stuff for the Audigy 2, and the CVS commit message mentions that it will break binary compatibility. Why they didn't mention that in the release announcement/notes is beyond me.
do you have that (#11) for sound hardware Chris ?
Here's the link to the CVS log for the appropriate file in ALSA's CVS repository: http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/include/sound/emu10k1.h?rev=1.2&view=log
Yes, i use the Creative Labs Sound Blaster Audigy 2 soundcard. Perhaps alsa is/was only broken for that card?
so to confirm, Chris, after upgrading to alsa-lib-1.0.6 and reemerging the gst-plugin-alsa, it worked fine for you?
Actually, I don't know what did it exactly, but I'd guess it was the upgrade to media-libs/gstreamer-0.8.5
if its really the alsi abi breakage (as it seems now only with specific hardware), then only the plugin should be rebuilt. This only clashes with comment #2, but the plugin is the only thing linking to alsa libs directly.
I'm going to close this on the assumption that it was the ABI breakaga as all signs point to that. I'll add einfo to the alsa-lib ebuild and keep it in ~arch for a bit longer to make sure nothing else crops up from this ABI breakage.
Hrmm... I'm stumped on this one. I just re-upgraded to 1.0.6 and all my alsa-lib dependent packages broke, in one way or another. On a whim, I created a .asoundrc file which pointed the default pcm device to hw 0,0 and it worked. In my strace of monkey-bubble, the only material difference was an attempt to open /dev/snd/controlC0 read only, as a means of testing for existence, and then closing and re-opening read-write.
So what should I do after emerging the new alsa-lib? The einfo is a bit confusing.
if you use emu10k1, re-emerge everything that links against alsa-lib
