The realplayer 10 binary from the real.com site hangs as soon as it tries to play anything when it's run under aRts using artsdsp. Killing artsd lets it continue running normally. Since realplayer10 works fine when it can access /dev/dsp directly (i.e. not running aRts), this seems to be an artsdsp bug. Reproducible: Always Steps to Reproduce: 1. Run the artsd sound server 2. Start realplayer 10 using "artsdsp realplay" 3. Try to play a realplayer stream Actual Results: Realplayer hangs until artsd is killed, after which it plays normally. Expected Results: Sound should play normally. This happens for artsdsp under both KDE 3.2 and 3.3. However, the realplayer version in portage works using artsdsp. # emerge info Portage 2.0.50-r11 (2004.2, gcc-3.3.4, glibc-2.3.3.20040420-r1, 2.6.7-gentoo-r14) ================================================================= System uname: 2.6.7-gentoo-r14 i686 Pentium II (Deschutes) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=i686 -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/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="-march=i686 -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache fixpackages sandbox sfperms" GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.du.se/pub/os/gentoo http://gentoo.inode.at/ http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X alsa apm arts avi berkdb bzlib cdr crypt cups divx4linux doc dvd emacs encode fbcon foomaticdb gdbm gif gpm hardened icq imagemagick imap imlib jpeg kde libg++ libwww linguas_en mad maildir mbox mikmod mmx motif mozilla mpeg mule ncurses nls offensive oggvorbis opengl oss pam pdflib perl pic png python qt quicktime readline sasl scanner sdl spell ssl svga tcpd tetex tiff truetype x86 xml2 xmms xv yahoo zlib"
does artsdsp -m realwhatever work? For me to play quake3, I have to enable the memory mapping emulation.
Same behaviour for artsdsp with and without the -m option.
Can you please try the ebuild in Bug 67620. It compiles from source, maybe you have more luck with that.
The realplay script checks LD_PRELOAD then empty it. It purposefully stop artsdsp and esd from working. hack the script to take away the LD_PRELOAD related stuff will solve the problem
The script hack in comment #4 works perfectly. (Why does the realplay startup script do this anyway?) It should probably be taken into account when a realplayer10 ebuild is eventually created.
Toby: That it works for you now, doesn't mean that the issue is resolved. Also please do not open bugs on applications, that are not in the official Portage tree. We're not your private bug fix agency. If you take user submitted ebuilds from bugs.g.o, then add a comment to that enhancement request. If you take an ebuild form elsewhere, don't bother us with it.
Christian, it looks like you may want to take care of this.
Re: Comment #6 I know you're not my private bug-fix agency, thank you very much. And I know that no realplay10 ebuild exists and therefore bugs in realplay10 aren't gentoo's problem. I submitted the bug because I thought it was an artsdsp problem, which IS in portage, and said as much in the bug report. (I was under the impression gentoo welcomed bug reports, as long as they've been checked for duplicates and include all relevant information...) Now that it's clear it's a bug/issue with realplay10 (not in portage) and NOT with artsdsp (in portage), the bug is resolved as far as gentoo is concerned. To save on duplicate bugs, I merely noted that this should probably be taken into account if and when a realplay10 ebuild is created.
>I know you're not my private bug-fix agency, thank you very much. Don't get too upset, just because I ate a hot chilli. ;) Sorry for that. Let's have a glass of milk. Cheers!
carlo, I'm having a look at it ASAP I'm back home ;) (tomorrow at last) cheers, Christian Parpart.
sorry genstef, I'm having no arts on my system since quite a while. I've to take this away though. I'm keeping the other realplayer related bug to me, because I'll have more time for media stuff soon.
There are situations in which using artsdsp leads to a lot of headaches. If real wants *not* to be used loaders/wrappers with realplayer, I think it's better doing so. Also, it seems to filter only arts/esd wrappers, and not alsa (aoss).
*** Bug 102808 has been marked as a duplicate of this bug. ***
