Hide Forgot
I can't get any beeps under KDE. I'm trying 'echo -ne \\7' in a konsole (I also tried an xterm). I tried fiddling with as many sound configurations as I could find. I couldn't get either a normal beep (which is what I'm after) or a fancy wav.
Works here... Make sure the soundcard isn't in use by any applications that aren't using arts. One of the features of arts is that it can shut down while it isn't used to allow legacy applications to use sound, so if you run esd or something else using non-arts sound, KDE sounds will shut up until the application has exited. (Yes, KDE uses arts to produce \\7 beeps).
I think probably arts had crashed; I saw some messages like that in .xsession-errors. I'm afraid I don't have that now. It works for me too now. I'll see it I can get it to happen again.
Luckily, I've found the core file from artsd. Here's the backtrace. Shall I send you the core? (gdb) bt #0 0x4028dab1 in __kill () from /lib/libc.so.6 #1 0x401dcfd6 in raise (sig=6) at signals.c:65 #2 0x4028ee94 in abort () at ../sysdeps/generic/abort.c:88 #3 0x40221f0b in __default_terminate () at ../../gcc/libgcc2.c:3034 #4 0x40221f2a in __terminate () at ../../gcc/libgcc2.c:3034 #5 0x40222c7a in throw_helper (eh=0x40500478, pc=0x400833cd, my_udata=0xbfffce78, offset_p=0xbfffce74) at ../../gcc/libgcc2.c:3168 #6 0x40222f2f in __rethrow (index=0x4023d628) at ../../gcc/libgcc2.c:3168 #7 0x402250af in __builtin_vec_new (sz=1404355840) from /usr/lib/libstdc++-libc6.2-2.so.3 #8 0x400833ce in Arts::CachedWav::CachedWav () at eval.c:41 #9 0x40082a8c in Arts::CachedWav::load () at eval.c:41 #10 0x40094804 in Arts::Synth_PLAY_WAV_impl::filename () at eval.c:41 #11 0x0804d40e in Arts::Object_base::_isEqual () at eval.c:41 #12 0x0804ee34 in Arts::Object_base::_isEqual () at eval.c:41 #13 0x40028e6a in _dispatch_Arts_SimpleSoundServer_00 () at eval.c:41 #14 0x40178db5 in Arts::Object_skel::_dispatch () at eval.c:41 #15 0x4016d90f in Arts::Dispatcher::handle () at eval.c:41 #16 0x4014f9bf in Arts::Connection::receive () at eval.c:41 #17 0x40180966 in Arts::SocketConnection::notifyIO () at eval.c:41 #18 0x40172d73 in Arts::StdIOManager::processOneEvent () at eval.c:41 #19 0x40172f6c in Arts::StdIOManager::run () at eval.c:41 #20 0x40171655 in Arts::Dispatcher::run () at eval.c:41 ---Type <return> to continue, or q <return> to quit--- #21 0x0805222f in Arts::Object_base::_isEqual () at eval.c:41 #22 0x4027cbac in __libc_start_main ( main=0x8051d40 <Arts::Object_base::_isEqual(Arts::Object_base *) const+19708>, argc=2, ubp_av=0xbffffccc, init=0x804c78c <_init>, fini=0x8053b7c <_fini>, rtld_fini=0x4000d5e4 <_dl_fini>, stack_end=0xbffffcc4) at ../sysdeps/generic/libc-start.c:129
This defect is considered MUST-FIX for Florence Gold release
Just had this again, on a different machine.
Created attachment 8644 [details] output of 'gdb artsd core'
There have been a couple of major changes in arts in CVS recently... Please try the packages from http://www.linux-easy.com/daily/
I get lots of failed dependencies (libkdefakes.so.0), so I can't test them.
Try today's build from 7.1 (currently building). (I still can't reproduce this).
This might be a separate problem, but on this machine with no sound card, artsd won't start and so the PC speaker doesn't even work.
artsd also desn't work on a VAIO laptop with ymfpci sound driver in the kernel. Seems like artsd abort()s if a write() of sound data to the kernel is getting a short write. This does happen with the 2.4-0.1.12 kernel and its ymfpci driver. Why is this extra check in the artsd startup code?
Please check if this still happens with the current version, I could never reproduce this on my hardware.
The current KDE documentation has a comment saying that some Yamaha chipsets will work only at a sampling rate of 48000 Hz. Does the problem disappear if you go to KControl->Sound->Sound Server->Sound I/O, check the "Use custom sampling rate" button and enter 48000?
Closing due to lack of feedback