> Namely, noatun (juk) does not play any sound although it seems to do
> everything normally. [...]
> At the same time kaboodle works just fine
Sorry but this is just impossible because all three apps use artsd for sound playback (juk can also make use of gstreamer if it's configured to do so).

This only means that there's a problem with aRTs, because this is exactly what happens (I would not report any problem that did not really occur, you know :-)).  Moreover, I have reported this with the Fodora Core 1 bugzilla and it seems that some people confirm it.

I think that the problem is somehow related to the volume control in both noatun and juk that seems to be independent of the mixer volume control and which kaboodle does not seem to have.  Moreover, if you configure XMMS to play through aRTs, the sound is audible, but the XMMS volume control is apparently coupled to (one of) the mixer volume contol slider(s) (well, on my system this does not work for KDE3.2, probably because the aRTs driver in SuSE 9.0 XMMS is incompatible with the aRTs 1.5).

Then try checking "use hardware mixing" (or something like that, it's translated here) in noatun and see if that helps.

I did.  The option is called "use fast hardware control" or similarly.  The bottom line is that if you start noatun with the option turned on, it works (ie. sound is audible), but if you start noatun with the option turned off, it doesn't (ie. sound is not audible), even if you switch the option later on.

I think it confirms my previous speculation quite a bit.  It looks like an initialization issue to me.

Users @ Gentoo on AMD64 are having this same problem (including myself).   Affected applications (that I can see):  JuK, Noatun, Kscd.

I am also a Gentoo/amd64 user.  JuK, Noatun and Kscd don't work for me either...

Please try setting an env var named NO_SSE and then start Noatun to see if the SSE code is at fault.

I did the following:

rafael@chimera:~> export NO_SSE=yes
rafael@chimera:~> echo $NO_SSE
yes
rafael@chimera:~> noatun

If that's what you meant, then no, it does not have any effect on the behavior described previously.

$NO_SSE doesn't fix anything for me either.

Well, here's another unlucky AMD64 user confirming the bug.
I checked a little further, and the problem may have to do
with ARTS' volume control. With hardware mixing enabled,
Amarok works fine, but only if it doesn't try to crossfade -
then the output will stop. And the volume control doesn't 
work at all with hardware mixing enabled (for me, at least).

Please somebody on an AMD64 system run
objdump -S /path/to/libnoatunarts.so
and mail the result in bzipped format to charles@kde.org

What could also be of interest: try using hardware volume control and try loading an arts effect (noatun effects dialog). For instance how does extrastereo sound like (if it "sounds" at all)?

Regarding comment #11, done.

Unfortunately, your libnoatunarts.so hasn't any symbols so I don't know
where the function that may or may not be broken is.

Fortunately, someone is lending me an amd64 so I'll give it a shot myself
in a couple of days.

-Charles

On Wed, 18 Feb 2004, Dylan Carlson wrote:

> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
>
> http://bugs.kde.org/show_bug.cgi?id=74972
>
>
>
>
> ------- Additional Comments From absinthe gentoo org  2004-02-18 19:02 -------
> Regarding comment #11, done.
> _______________________________________________
> kde-multimedia mailing list
> kde-multimedia@kde.org
> https://mail.kde.org/mailman/listinfo/kde-multimedia
>

Regarding comment #12 I've tested this and it seems that almost all of the effects work except for one: if Arts:Synth_STEREO_FIR_EQUALIZER is activated the sound instantly goes off.  The same happens if you enable the equalizer.

*** Bug 77462 has been marked as a duplicate of this bug. ***

what version of gcc do you use?

the output of `gcc -v` will do

-Charles

gcc -v produces the following output here:

$ gcc -v
Reading specs from /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/specs
Configured with: /var/tmp/portage/gcc-3.3.3/work/gcc-3.3.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.3/info --enable-shared --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,f77,objc --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --disable-multilib
Thread model: posix
gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)

(The problem appears on my install, too.)

	Guido

start up artscontrol and enable the FFT Scope.

When the music doesn't play, does the FFT Scope still show something interesting?

(Answer to #19)

No, nothing

	Guido

Guido, what crazy compile options do you compile KDE with? :)

Just filed a message on the gentoo forums, and then found my way here via a Gentoo bugzilla entry.  http://www.nacnud.force9.co.uk/snapshot1.png is what noatun + fft scope looks like when noatun is trying to play a song.  Enabling the fast hardware option gives me sound, and a flashing FFT scope.

http://www.nacnud.force9.co.uk/libnoatunarts.dump.gz is my objdump - don't know if it has symbols or not.  If a developer needs an amd64 to poke at, I can offer ssh to my system if it'll help.  gcc -v is same as Guido.  An ldd of kaboodle and noatun shows that both link libasound.  When kaboodle is playing, the FFT scope is happily active.

Eh, I just noticed that when Juk fires up, I see an entry in the audio manager, but Juk has no bus associated with it.  I can assign the out_soundcard bus, but there is no FFT activity, nor is there any sound.  I can also run both noatun and kaboodle at once, and get overlapping sound.

If kaboodle is the first app to start, and noatun is started afterwards, without hardware volume control, noatun does not produce sound.

Tell me what else to poke at, and I'll poke it.  I'd like to get this sound issue resolved so I can hook my server up to my stereo :)

Oh, according to the ebuild file, the configure line looks something like:
--enable-audio=oss,alsa --with-alsa --with-arts-alsa --enable-motif --enable-slang --with-cdda --disable-strict --disable-warnings.  I'm not familiar with the ebuild process yet, so I can't work out anything else.

Additonal info at the suggestion of jhuebel on #gentoo-amd64
Portage 2.0.50-r1 (default-amd64-2004.0, gcc-3.3.3, glibc-2.3.2-r9, 2.6.3-gentoo-r2)
=================================================================
System uname: 2.6.3-gentoo-r2 x86_64 4
Gentoo Base System version 1.4.3.13
ccache version 2.3 [enabled]
Autoconf: sys-devel/autoconf-2.58-r1
Automake: sys-devel/automake-1.7.8
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-O2"
CHOST="x86_64-pc-linux-gnu"
COMPILER="gcc3"
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 /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="http://www.mirror.ac.uk/sites/www.ibiblio.org/gentoo/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acpi alsa amd64 apm arts avi berkdb crypt cups dvd encode esd ethereal flac foomaticdb gd gdbm gif gnome gpm gstreamer gtk gtk2 imlib jpeg kde libg++ libwww maildir mikmod motif mozilla mpeg mysql ncurses nls oggvorbis opengl pam pdflib perl png python qt quicktime readline samba sdl slang spell ssl tcpd truetype xml2 xmms xv zlib"

Reading specs from /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/specs
Configured with: /var/tmp/portage/gcc-3.3.3/work/gcc-3.3.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/3.3 --includedir=/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/3.3/info --enable-shared --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-system-zlib --enable-languages=c,c++,f77,objc --enable-threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio --enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime-libs --with-gxx-include-dir=/usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.3/include/g++-v3 --with-local-prefix=/usr/local --enable-shared --enable-nls --without-included-gettext --disable-multilib
Thread model: posix
gcc version 3.3.3 20040217 (Gentoo Linux 3.3.3, propolice-3.3-7)

if I compile kdemultimedia and arts on my test amd64 machine (yes, it's a 64 bit kernel too), it all works.

That's with both -O2 and -g3.

That said, the FFT scope works, but I don't have physical access to it, so I don't know if actual sound comes out.

I'm running out of ideas here...

Charles et al,
I recompiled 3.2.0 (arts, base, libs, multimedia) on Gentoo.  http://www.nacnud.force9.co.uk/gentoo/snapshot2.png is what I see when I have Juk trying to play OGG files.  The total lack of a bus entry for Juk is not a pretty sight.  As stated above, I can add the bus manually, but it doesn't help anything.

Created attachment 5374 [details]
buffer patch for noatun/JuK/Kscd sound issues on amd64

patch provided by coolo at SUSE, already tested and working on Gentoo/amd64

Okay, this patch works for me. Thanks a lot!

When will it be merged into CVS?

CVS commit by coolo: 

gcc on 64bit architectures can't know you see long as 32bit (patch by Michael Matz)
CCMAIL: matz@kde.org
CCMAIL: 74972-done@bugs.kde.org


  M +5 -5      buffer.cc   1.29


--- arts/mcop/buffer.cc  #1.28:1.29
@@ -88,7 +88,6 @@ void Buffer::writeFloat(float f) {
         // FIXME: on some machines this may fail badly (there is explicit
         // float marshalling and demarshalling code in mico/orb/util.cc)
-
-        long *f_as_long = (long *)&f;
-        writeLong(*f_as_long);
+        union { float f; long l; } u = {f};
+        writeLong(u.l);
 }
 
@@ -253,7 +252,8 @@ float Buffer::readFloat()
 {
         // FIXME: see writeFloat()
-        long f_as_long = readLong();
+        union {float f; long l; } u;
+        u.l = readLong();
 
-        if(!_readError) return *(float *)&f_as_long;
+        if(!_readError) return u.f;
         return 0.0;
 }