Re: [linux-audio-dev] regarding mobos and CPUs
On Thu, May 06, 2004 at 10:44:13AM -0400, Dave Phillips wrote: > [...] AMD CPUs are fine. This has been addressed elsewhere in the thread. You do need a good motherboard though. > Also, what's a recommended motherboard ? Are there any mobos that > should definitely be avoided ? I would definately avoid the ASUS A7S333, or anything else based on the SiS745 chipset. It has issues with interrupt routing and I could not get it to do anything even resembling realtime. I've had good results with the A7V600-X I replaced it with. The only downsides to this board are 1. the onboard audio sucks ass (but you weren't going to use it anyway, right? :) and 2. MIDI requires a dongle - if you have one from 10 years ago or something, the pinouts should be the same. Hope this helps, Jody
Re: [linux-audio-user] Re: [linux-audio-dev] regarding mobos and CPUs
>The modern AMD chips support SSE, and its not really the AMDs fault, its >just that someone put some dodgy optimation code in the Makefile or auto*. ^^^ paul --p
Re: [linux-audio-dev] regarding mobos and CPUs
On Thu, 2004-05-06 at 07:53, Taybin Rutkin wrote: > Yes, that was just an autotools problem. It could have happened to a P4 if jack > was built on an AMD box. It was more of a cross-compilation issue. Yes, there is no problem with the AMD processors that I know of. This was a packaging problem triggered by the autotools problem. In essence the package itself was saying "I can run on any i386 cpu" so that apt/rpm was happily installing it on a Duron processor (which is compatible with the i386 instruction set). _But_ the contents of the package did not agree with the label and I did not catch that before releasing it :-) The executable itself had instructions that could _not_ execute in the Duron processor (but, for example, they would have worked fine on more recent AMD processors). So the program segfaulted on startup with an "illegal instruction" fault. Anyway, just to clarify things... -- Fernando > -Original Message- > From: Dave Phillips <[EMAIL PROTECTED]> > Sent: May 6, 2004 11:20 AM > To: > The Linux Audio Developers' Mailing List <[EMAIL PROTECTED]>, > LAU Mail <[EMAIL PROTECTED]> > Subject: Re: [linux-audio-dev] regarding mobos and CPUs > > Taybin Rutkin wrote: > > >What is the problem with JACK and AMD cpus? I haven't heard of one. > > > > > > > Not so long ago a release of qjackctl in Planet C failed due to (IIRC) > JACK getting compiled with an SSE call (or calls) that killed it > completely on my Duron. The problem was simply and quickly solved, and > I'm perhaps off-base accusing JACK but that's where the problem came > from. Maybe it was a bad make ? > > Anyway, if it's the opinion of the LAD developers that AMD is OK then > that's what I need to know. As I stated, I've had only that one > difficulty with AMD and Linux audio software, so I think I'm just being > paranoid. > > Best, > > dp >
[linux-audio-dev] Re: [PlanetCCRMA] The Linux FreeVSTi Compatibility List
Kjetil Svalastog Matheussen wrote: > "xterm -e vsti plugin_name" The only working choice out of the three mentionned, being equivalent to invoking "vsti plugin_name" directly on a console. Christian
Re: [linux-audio-dev] regarding mobos and CPUs
Yes, that was just an autotools problem. It could have happened to a P4 if jack was built on an AMD box. It was more of a cross-compilation issue. Taybin -Original Message- From: Dave Phillips <[EMAIL PROTECTED]> Sent: May 6, 2004 11:20 AM To: The Linux Audio Developers' Mailing List <[EMAIL PROTECTED]>, LAU Mail <[EMAIL PROTECTED]> Subject: Re: [linux-audio-dev] regarding mobos and CPUs Taybin Rutkin wrote: >What is the problem with JACK and AMD cpus? I haven't heard of one. > > > Not so long ago a release of qjackctl in Planet C failed due to (IIRC) JACK getting compiled with an SSE call (or calls) that killed it completely on my Duron. The problem was simply and quickly solved, and I'm perhaps off-base accusing JACK but that's where the problem came from. Maybe it was a bad make ? Anyway, if it's the opinion of the LAD developers that AMD is OK then that's what I need to know. As I stated, I've had only that one difficulty with AMD and Linux audio software, so I think I'm just being paranoid. Best, dp
Re: [linux-audio-user] Re: [linux-audio-dev] regarding mobos and CPUs
On Thu, May 06, 2004 at 11:20:38 -0400, Dave Phillips wrote: > Taybin Rutkin wrote: > > >What is the problem with JACK and AMD cpus? I haven't heard of one. > > > > > > > Not so long ago a release of qjackctl in Planet C failed due to (IIRC) > JACK getting compiled with an SSE call (or calls) that killed it > completely on my Duron. The problem was simply and quickly solved, and > I'm perhaps off-base accusing JACK but that's where the problem came > from. Maybe it was a bad make ? The modern AMD chips support SSE, and its not really the AMDs fault, its just that someone put some dodgy optimation code in the Makefile or auto*. - Steve
Re: [linux-audio-dev] regarding mobos and CPUs
Taybin Rutkin wrote: What is the problem with JACK and AMD cpus? I haven't heard of one. Not so long ago a release of qjackctl in Planet C failed due to (IIRC) JACK getting compiled with an SSE call (or calls) that killed it completely on my Duron. The problem was simply and quickly solved, and I'm perhaps off-base accusing JACK but that's where the problem came from. Maybe it was a bad make ? Anyway, if it's the opinion of the LAD developers that AMD is OK then that's what I need to know. As I stated, I've had only that one difficulty with AMD and Linux audio software, so I think I'm just being paranoid. Best, dp
Re: [linux-audio-dev] Re: [linux-audio-user] regarding mobos and CPUs
Same here - Athlon XP on old mobo. Jan On Thu, 2004-05-06 at 09:20, Steve Harris wrote: > On Thu, May 06, 2004 at 10:44:13 -0400, Dave Phillips wrote: > > Greetings: > > > > A client has asked me to get some opinions regarding AMD CPUs and > > recommended motherboards. He's planning to replace an SMP system that > > has apparently never worked quite right. He doesn't want another SMP > > mobo, and a friend is advising him to go with a uniprocessor system > > built around a recent AMD CPU. The recent JACK problem with AMD CPUs was > > a revelation for me: I'd never had any problems with AMD chips, but now > > I'm feeling reluctant to recommend them. Am I just being paranoid, or > > are there particular reasons to go with Intel instead of AMD ? My > > client is considering a P4 instead of the AMD, hence this infoquest... > > What AMD problem? I run jack on an Athlon XP daily without probems. > > The mobo is quite old, so the model is probably not a helpful > recommnedation though. > > - Steve
[linux-audio-dev] Re: [linux-audio-user] regarding mobos and CPUs
On Thu, May 06, 2004 at 10:44:13 -0400, Dave Phillips wrote: > Greetings: > > A client has asked me to get some opinions regarding AMD CPUs and > recommended motherboards. He's planning to replace an SMP system that > has apparently never worked quite right. He doesn't want another SMP > mobo, and a friend is advising him to go with a uniprocessor system > built around a recent AMD CPU. The recent JACK problem with AMD CPUs was > a revelation for me: I'd never had any problems with AMD chips, but now > I'm feeling reluctant to recommend them. Am I just being paranoid, or > are there particular reasons to go with Intel instead of AMD ? My > client is considering a P4 instead of the AMD, hence this infoquest... What AMD problem? I run jack on an Athlon XP daily without probems. The mobo is quite old, so the model is probably not a helpful recommnedation though. - Steve
Re: [linux-audio-dev] regarding mobos and CPUs
What is the problem with JACK and AMD cpus? I haven't heard of one. Personally, I have an nvidia nforce2 motherboard which has worked fairly well for me. Taybin -Original Message- From: Dave Phillips <[EMAIL PROTECTED]> Sent: May 6, 2004 10:44 AM To: LAD Mail <[EMAIL PROTECTED]>, LAU Mail <[EMAIL PROTECTED]> Subject: [linux-audio-dev] regarding mobos and CPUs Greetings: A client has asked me to get some opinions regarding AMD CPUs and recommended motherboards. He's planning to replace an SMP system that has apparently never worked quite right. He doesn't want another SMP mobo, and a friend is advising him to go with a uniprocessor system built around a recent AMD CPU. The recent JACK problem with AMD CPUs was a revelation for me: I'd never had any problems with AMD chips, but now I'm feeling reluctant to recommend them. Am I just being paranoid, or are there particular reasons to go with Intel instead of AMD ? My client is considering a P4 instead of the AMD, hence this infoquest... Also, what's a recommended motherboard ? Are there any mobos that should definitely be avoided ? TIA for any help you guys can proffer, it's much appreciated. Best regards, dp
[linux-audio-dev] regarding mobos and CPUs
Greetings: A client has asked me to get some opinions regarding AMD CPUs and recommended motherboards. He's planning to replace an SMP system that has apparently never worked quite right. He doesn't want another SMP mobo, and a friend is advising him to go with a uniprocessor system built around a recent AMD CPU. The recent JACK problem with AMD CPUs was a revelation for me: I'd never had any problems with AMD chips, but now I'm feeling reluctant to recommend them. Am I just being paranoid, or are there particular reasons to go with Intel instead of AMD ? My client is considering a P4 instead of the AMD, hence this infoquest... Also, what's a recommended motherboard ? Are there any mobos that should definitely be avoided ? TIA for any help you guys can proffer, it's much appreciated. Best regards, dp
[linux-audio-dev] Re: [PlanetCCRMA] The Linux FreeVSTi Compatibility List
On Thu, 6 May 2004, Christian Frisson wrote: > Hi, > > Kjetil Svalastog Matheussen wrote: > > > Very nice work. However, I think you may have misunderstood how the > > vstserver works: > > > > The vstserver does actually work by setting up a bounch of processes and > > threads, and are very very far from being single-threaded. There are no > > limitations on how many vsti's you run simultaniously. > > My apologies... My dev knowledge is too low to be mentionned. Additionally, > French people like me don't always speak English very well ,-) I've definitely > made this thread confusion during my tests, as I tried to launch two plugins > simultaneously, both with vsti, and had VSTserver return errors... Had just > another go today, works perfectly! Mea culpa. > Good to hear. > When it comes to limit the number of opened console windows, how should I define > my paths correctly system-wide? On Fedora Core 1 - seems to be relevant in this > case - appending "export VST_PATH=..." to the file /etc/profile and sourcing it > afterwards does only define the path for console use. When using the launcher > (Alt+F2) to start plugins with "vsti plugin_name", it doesn't seem to recognize > VST_PATH. > Strange. What if you replace "vsti plugin_name" with "export VST_PATH=... vsti plugin_name" or "xterm -e vsti plugin_name" or "bash -c "vsti plugin_name"" ? > > The difference between the vstserver and the new fst-library made by > > Torben Hohn and Paul Davies is that the fst-library runs the vst-plugin > > in the same process, while using the vstserver-system you run the > > vst-plugin inside a new process set up by the vstserver. > > > > What this means is that you get less contex-switches and therefor > > better performance when running many (something like more than 8 according > > to Paul) vst-plugins simultaniously using the fst-library. > > What kind of features are already planned for the next releases of both projects? > I need to get the vstserver to compile with wine again. I haven't succeeded with that yet. (not without linking with pthread at least). --
[linux-audio-dev] Re: [linux-audio-user] Linux Audio weblog
Am Mit, den 05.05.2004 schrieb Jan Weil um 13:15: > now that my new website is online I'd like to let you know that I > recently added a 'Linux Audio' path to my weblog. What I forgot to mention is that (thanks to Blosxom) it is also available as an RSS feed: http://www.jawebada.de/index.cgi/blog/lad/index.rss Enjoy (and have no fear, this is still only the 'Linux Audio' path of my weblog :) Jan
Re: [linux-audio-dev] (web-based) interactive sound art?
On Wednesday 05 May 2004 17.12, Francois Dechelle wrote: > Le mer 05/05/2004 à 15:57, Pall Thayer a écrit : > > It would be nice if SVG became more widespread. I wonder why > > Mozilla doesn't include it in the normal releases. Since the > > source is available, it couldn't be too difficult to make a free > > plugin version, could it? > > Yes, probably, but there are certainly some hidden difficulties, > otherwise I don't understand why it is done inside Mozilla and not > as a plugin. Might have to do with script tags (ECMAScript) and stuff... Looked at the spec the other day, and I'd say it looks like pretty heavy stuff, if you want to implement full support. //David Olofson - Programmer, Composer, Open Source Advocate .- Audiality ---. | Free/Open Source audio engine for games and multimedia. | | MIDI, modular synthesis, real time effects, scripting,... | `---> http://audiality.org -' --- http://olofson.net --- http://www.reologica.se ---
Re: [linux-audio-dev] RME HDSP ALSA driver
> > I'm trying to get my RME HDSP9632 card working under SuSE Linux. I've > > built ALSA 1.04, and it can see my Soundblaster fine, but when I > > modprobe snd-hdsp, it cannot find the RME card. The card shows up in > > lspci with revision 0x97, and I'm wondering if this card/firmware is > > too new to be detected by the latest ALSA drivers. > > Adding checks for the latest firmware in hdsp.c resolved this problem. > > Simon Pietroni. Hi Simon, Thanks for the report and sorry for the delay. Sadly RME still doesn't warn me whenever new card revisions are out. However there is a way to make alsa more tolerant to revision changes, and it will be part of a forthcoming driver update. Thomas
Re: [linux-audio-dev] libfishsound-0.6.1
On Thu, 06 May 2004 00:17:04 +0200 [EMAIL PROTECTED] (Albert Graef) wrote: > How long until we can get our hands on this? No guarantees, but I would think no more than a month. I'm currently preparing a release which is able to compile Win32 DLLs using MinGW. Once thats done I just need to merger from Conrad, test and release. Erik -- +---+ Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid) +---+ "Python is the most efficient language I've ever used. It's 10 times better than any of the other tools I have used. It's free, it's object-oriented, it adapts to everything, it runs on everything. There is almost an indescribable 'quality without a name' attraction on my part." --Bruce Eckel, Author of Thinking in Java
