on my Debian Etch, previous versions of LinuxSampler worked fine. Since my last
upgrade to the latest deb-packages, v0.5.1, I get the following error messages
on my M-Audio 2496 card (ICE1712 chipset):
LinuxSampler initialization completed. :-)
LSCPServer: Client connection established on socket:4.
Warning: your soundcard doesn't support chosen hardware parameters; trying to co
mpensate support lack with plughw...>>> FATAL ERROR: Illegal instruction (SIGILL
) occured! <<<
Showing stack trace...
BTW, trying the latest CVS-versions on Ubuntu Studio or Fedora 8 lead to a total
system crashes causing lots of errors in the file system (fsck enforced after
rebooting). In Debian, however, LinuxSampler is killed cleanly after this event
without freezing the system.
What's going wrong now? I was so happy using previous versions, namely 0.4.0-1.
The echoed output of the .lscp file is as follows:
CREATE AUDIO_OUTPUT_DEVICE ALSA
CREATE MIDI_INPUT_DEVICE ALSA
SET MIDI_INPUT_PORT_PARAMETER 0 0 ALSA_SEQ_BINDINGS='16:0'
LOAD ENGINE gig 0
SET CHANNEL AUDIO_OUTPUT_DEVICE 0 0
SET CHANNEL VOLUME 0 1.00
SET CHANNEL MIDI_INPUT_DEVICE 0 0
LOAD INSTRUMENT '/home/chris/boesendorfer290.gig' 0 0
*** CRASH AT THIS POINT ***
Using 'envy24control' I have tried to set the hardware parameters already to
44100 etc. Please help me, I want to hear my Boesy again! Thank you in advance,
I see two possibilities here:
a) bug in LS (ALSA driver)
b) problems with ALSA (plughw)
try to use jack and see if the problem disappears.
You can try to track down the problem by recompiling LS in debug mode and run it
under gdb. When it crashes post the stack trace.
The ALSA driver is a bit outdated as it only works in 16bit mode.
(but should work on 24bit cards too, although samples are not outputted in 24bit)
First off: which Debian packages do you use? The ones from our servers or from
a certain distribution? This is important to know, since an "illegal
instruction" in almost all cases is caused by compiling source code for an
incompatible CPU. For example when it is compiled for a recent processor with
SSE3 instruction set and you are using an older processor that doesn't support
such new instructions.
Which leads me to the next question: what is the exact processor type you are
The CPU of this box is a very old Athlon-K7, running at 1200MHz, I use Debian Etch 4.0r2. The
behaviour is the same when using Debian's precompiled kernel or my own modified pre-emptive
1000Hz "real time"-configured kernel. All LinuxSampler packages in use are those downloaded from
your homepage, all lib*-packages from the distributions in context with LS have been replaced by
LS v0.4.0 from your site still works excellent, although the warning "...using plughw..." appears. As far
as I can remember, a significant error message immediately before the crash of v0.5.1 talks something
about libthread/disks or the like.
VLC and Totem work great together with ALSA drivers of M-Audio 2496 (ice1712) under Debian, but
there are clicking noise problems with Fedora 8 and "PulseAudio" (forget it) which I have not installed
under Etch, of course.
Next weekend I want to try the gdb-enabled testing with CVS v0.5.1.
I just checked our Debian packages. The reason for your problem is that the
new Debian binaries contain SSE instructions, which your old processor does
I'm just surprised that our Debian binaries contain SSE instructions, since we
compiled it (according to the Debian standards) for i486 by default.
Anyway, as Benno already suggested, you can solve this issue for now by
recompiling LS for your machine. Have a look at the README files which contain
detailed instructions how to compile Debian pacakges. Due to Debian's great
packaging scripts this is usually straighforward.
In your case you might need to override the CXXFLAGS for your machine though,
so it won't compile the packages again with SSE instructions.
I'll add a Debian HOWTO soon to the LS website, since for max. performance one
should recompile libgig and LS for the specific machine anyway.
Here is the promised Debian HOWTO:
Marking this one as blocker, as it should be handled for the upcoming release.
This bug should finally be fixed with our latest Debian binary packages of
linuxsampler 1.0.0 and Co. They are available from our downloads site as usual.
I just checked all binaries of all new packages (including gigedit, qsampler,
etc.) and they all have 0 SSE instructions, except the linuxsampler binary and
liblinuxsampler, which both show 2 SSE instructions, but I think this is the
hand written asm code for feature detection. So it should not be a problem on
Closing this report now.