Hello dear list,
I was thinking of buying a IBM Thinkpad (not sure which model yet) and a RME Fireface, to do both live and "dead" electronics. I had some experience with linux before, but now I wanted to go deeper in it (but also have windows on the side for emergencies). Has anyone had any experience with either from these devices?
Thank you,
João Miguel Pais
Lugostr. 14 79100 Freiburg Deutschland +49 (0) 761 7074997
Hi João, I've been using PD and Linux on Thinkpads for a couple of years now with very few problems. I'm using Fedora Core 2 now and it's pretty good but I can't get the trackpoint working properly so I use a mouse. But everything else works great and PD runs happily.
(but also have windows on the side for emergencies)
Windows IS an emergency.
But seriously, I've had double bootable setups before with no problems but now run only linux. I came to the conclusion that if I have to use Windows to do it, then it's just not something that needs doing.
One thing I'm not sure about though is this: All my Thinkpads (third one now) have had Celeron processors. I noticed the other day that someone was advising people to avoid pentium 4's because they didn't run PD well. I have no experience with that but perhaps something to keep in mind.
best, Pall Thayer
On fim, 2004-09-16 at 22:54, jmmmp wrote:
Hello dear list,
I was thinking of buying a IBM Thinkpad (not sure which model yet) and a RME Fireface, to do both live and "dead" electronics. I had some experience with linux before, but now I wanted to go deeper in it (but also have windows on the side for emergencies). Has anyone had any experience with either from these devices?
Thank you,
João Miguel Pais
Lugostr. 14 79100 Freiburg Deutschland +49 (0) 761 7074997
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
One thing I'm not sure about though is this: All my Thinkpads (third one now) have had Celeron processors. I noticed the other day that someone was advising people to avoid pentium 4's because they didn't run PD well. I have no experience with that but perhaps something to keep in mind.
The P4s have for instance the denormalising effect which causes some problems with audioapplications. But its not a good idea to have one in a notebook anyway because these are desktop cpus and draws lot energy. Better to go with Centrino chip(sets) so you can use your laptop on the run too.
Cheers,
Malte
All my Thinkpads (third one now) have had Celeron processors. I noticed the other day that someone was advising people to avoid pentium 4's because they didn't run PD well. I have no experience with that but perhaps something to keep in mind.
pd used to have problems with denormals until version 0.36 ... since 0.37, denormal handling have been implemented ... the devel_0_37 branch is using assembler coded simd instruction that are not that critical concerning denormal numbers ...
on some p4 cpus it's even possible to switch on DAZ which causes the cpu to handle denormals as zeros in simd instructions ... i'm not sure how different operating systems handle this, but i _suppose_ this explains problems i had when switching from suse to gentoo and got stuck in denormal crashes ...
anyway, a machine that is not affected by the denormal problem is not as important as it was about one year ago if you are on pd ...
cheers ... tim
Tim Blechmann wrote:
pd used to have problems with denormals until version 0.36 ... since 0.37, denormal handling have been implemented ... the devel_0_37 branch is using assembler coded simd instruction that are not that critical concerning denormal numbers ...
hmmmmm.... my last year of using PD on a P4 had been *nothing* but denormal problems! I can pretty much guarentee that any complex patch I make will crash on my 1.6 Ghz laptop and run flawlessly on my 1.8Ghz AMD shuttle.
In fact, this problem is not only with PD, but also with many other core Linux sound apps, such as Jamin, and a boatload of LADSPA plugins. It's gotten to the point where my options are either to get a new Athlon-based laptop or to find a kernel-patch which deals with the problme globally instead of waiting around for the application developers [who must be working on Celerons or AMDs!] to fix it.
on some p4 cpus it's even possible to switch on DAZ which causes the cpu to handle denormals as zeros in simd instructions ...
Can you show me some documentation on this? I'd like to check this out before I have to go shopping for a new computer ;-)
i'm not sure how different operating systems handle this, but i _suppose_ this explains problems i had when switching from suse to gentoo and got stuck in denormal crashes ...
I think we chatted about this once... Debian, Red Hat and Gnetoo all give me the same denormal CPU leaps and freezes. SuSE *must* be doing something special to their kernel. So perhaps it's available as a kernel patch somewhere. Either that, or they compile everything with a proprietary Intel compiler. Using an Intel compiler on PD alone didn't really give me any big gains, so it must be done on the level of the kernel.
anyway, a machine that is not affected by the denormal problem is not as important as it was about one year ago if you are on pd ...
*Cough!* Then it won't be so important when I send you the bill for my next, LinuxPD-friendly laptop ;-)
d.
hmmmmm.... my last year of using PD on a P4 had been *nothing* but denormal problems! I can pretty much guarentee that any complex patch I make will crash on my 1.6 Ghz laptop and run flawlessly on my 1.8Ghz AMD shuttle.
which version of pd? have you compiled pd / externals / ladspa-plugins with -mfpmath=sse?
In fact, this problem is not only with PD, but also with many other core Linux sound apps, such as Jamin, and a boatload of LADSPA plugins. It's gotten to the point where my options are either to get a new Athlon-based laptop or to find a kernel-patch which deals with the
i have the same problems with jamin and with a couple of ladspa plugins ... i fixed some of steve harris's plugins that i was using ... they where a big problem i had ...
Can you show me some documentation on this? I'd like to check this out before I have to go shopping for a new computer ;-)
intel provides two very interesting pdfs: intel processor identification and the CPUID instruction and intel architecture software developer's manual
I think we chatted about this once... Debian, Red Hat and Gnetoo all give me the same denormal CPU leaps and freezes. SuSE *must* be doing something special to their kernel. So perhaps it's available as a kernel patch somewhere. Either that, or they compile everything with a proprietary Intel compiler. Using an Intel compiler on PD alone didn't really give me any big gains, so it must be done on the level of the kernel.
i don't think that suse is doing something with their libc/kernel/(???) ... some time ago i read something on the lkml, that 2.4 used to switch DAZ on, but 2.6 doesn't ... i suppose it was related to that ...
if i find some free time, i'll try to add a piece of code to switch DAZ on during the startup of pd ... (probably after graz)
cheers ... tim
Tim Blechmann wrote:
hmmmmm.... my last year of using PD on a P4 had been *nothing* but denormal problems! I can pretty much guarentee that any complex patch I make will crash on my 1.6 Ghz laptop and run flawlessly on my 1.8Ghz AMD shuttle.
which version of pd?
Pd version 0.37.1 devel compiled 17:14:44 Sep 19 2004
have you compiled pd / externals / ladspa-plugins with -mfpmath=sse?
...afraid yes...
OPT_CFLAGS = -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse -O2 -fomit-frame-pointer
[I don't think -mmmx does anything of value here, but I just transferred over my Gentoo CFLAGS for consistancy ;-) ]
I'll have to look into these DAZ and FTZ switches, as were discussed on the LAD list. But it's really a pity that it's so difficult to get good performance out of a P4. This is why I can only *un*recommend them to anybody wanted to do audio.
Off to Ebay I go for a new laptop. When will PD have a 64bit version so I can check out one of these new AMDs? ;-)
d.
Pd version 0.37.1 devel compiled 17:14:44 Sep 19 2004
try to compile again with -DDAZ (i added some code to switch on DAZ/FTZ)
alsa make shure all you externals / ladspa plugins / jack have been recompiled with-mfpmath=sse ...
have you compiled pd / externals / ladspa-plugins with -mfpmath=sse?
...afraid yes...
OPT_CFLAGS = -march=pentium4 -mmmx -msse -msse2 -mfpmath=sse -O2 -fomit-frame-pointer
for pd, only -msse is necessary
cheers ... tim (who hasn't experienced a denormal crash for monthes)
On Sun, 19 Sep 2004 14:50:46 +0200, derek holzer derek@x-i.net wrote: Using an Intel compiler on PD alone didn't
really give me any big gains, so it must be done on the level of the
kernel.
hmm, I would think that it would actually be a libc problem not a kernel
problem.
Since that is where the math is handled I think.
I don't see how the kernel can do anything about denormals, other then
providing a /proc interface for processor switches.
There is also more variance in libc version floating around because there
hasn't been an "official" release of glibc in ages.
redhat is known to use their own patched versions. Gentoo might also be
using cutting/bleeding edge versions.
And there are issues with jack and _some_ recent libc versions.
On a related note: Are you using pd with jack with an nptl libc?
ciao
Gerard
hmm, I would think that it would actually be a libc problem not a kernel problem. Since that is where the math is handled I think. I don't see how the kernel can do anything about denormals, other then providing a /proc interface for processor switches.
well, by switching DAZ on, which is a processor flag ...
also, i don't think that it's a big problem with the libc, since the main source for denormal numbers in dsp algorithms are feedback loops, that don't use the libc ...
cheers ... tim
Hello dear list,
I was thinking of buying a IBM Thinkpad (not sure which model yet) and a RME Fireface, to do both live and "dead" electronics. I had some experience with linux before, but now I wanted to go deeper in it (but also have windows on the side for emergencies). Has anyone had any experience with either from these devices?
I don't have any experience with them, but firewire audio support in linux is practically non-existent. It seems people are working on it, but if you want something that just works and are unwilling or unable to do some fairly heavy coding I wouldn't use it.
It may be very different in a year though. RME is pretty good at giving their specs to driver developers.
Gerard
-
derek holzer -
gerard van dongen -
gml＠xs4all.nl
-
jmmmp -
Malte Steiner -
Pall Thayer -
Tim Blechmann