Finally got pd-0.21 to compile on my linux platform. Mea culpa.... I had installed 'egcs' , an experimental gcc 'improvement' (even higher degrees of optimization than standard gcc available ...someone on the csound list reported a major increase in speed in csound compiled with this compiler)...the compiling went without hitch, and it reported linking ok, but died when the egcs linked binaries tried to dynamically link in libc . Which means, before any pd code even got called. So I changed back to "cc" (a link to the real gcc),and voi-la! (voi-ci?) Like my mid-western buddy always says: "like, weird, with a beard, man...."
Onwards into the OSS world, and hopefully, full duplex on linux .
Anybody else seen the problem I found on NT (dacs often die almost immediately, but when they don't they function perfectly.)..I betcha this has to do with the multiple soundcards I have on my system....I will try the new args to specify card/midi under NT. You know, it's nice to have the source!
CharlieB
Charles Baker writes:
Onwards into the OSS world, and hopefully, full duplex on linux .
Yeah, would be cool. I just received a patch from Larry for s_linux.c and will merge this into a version pd-0.21.1. If you'd like to improve full duplex, please use that version.
Guenter
Guenter Geiger wrote:
Charles Baker writes:
Onwards into the OSS world, and hopefully, full duplex on linux .
Yeah, would be cool. I just received a patch from Larry for s_linux.c and will merge this into a version pd-0.21.1. If you'd like to improve full duplex, please use that version.
Guenter
Be aware that I'm pretty sure that you will need to tweak my version further to get dull duplex to work. Since I don't use it I didn't bother coding it, but I think I remember reading in the 4front docs about some ioctl you need to do to actually enable it.
-- Larry Troxler -- lt@westnet.com -- Patterson, NY USA --
Charles Baker wrote:
Finally got pd-0.21 to compile on my linux platform. Mea culpa.... I had installed 'egcs' , an experimental gcc 'improvement' (even higher degrees of optimization than standard gcc available ...someone on the csound list reported a major increase in speed in csound compiled with this compiler)...
How much an increase, percentage-wise?
As an aside, I notice an almost 100 % increase on Pentium-100 Linux when I use a 128-sample DAC Block size instead of 64 samples! THis is based on what "top" reports for CPU%, which is also consistent with what the "profile" object reports. However, I don't yet know whether this is perhaps due to the complex timeing interactions between the DAC size and the OSS fragment size and the scheduler advance.
It think it would be usefull if someone else on similar hardware would verify this. IIRC, it's the DACBLKSIZE parameter that I'm speaking of.
That much difference does seem a bit suspicious, but maybe it makes sense due to the tiny first-level cache (each dsp performance loop easily fits in to the cache and runs at breakneck speed). Or could there be some inefficiency in what happens between DSP runs? I looked and didn't immediately see any glaring errors, but ...
But regardless, 128 samples represents just under 3ms at 44100Hz, which isn't too bad compared to MIDI latency. So it's not a bad deal :-)
Larry
-- Larry Troxler -- lt@westnet.com -- Patterson, NY USA --
-
Charles Baker -
Guenter Geiger -
Larry Troxler