Hi, I'm a novice in Linux, and I cannot run PD. I've unpacked the pd-032-linuxppc.tar, and I make it in scr dir. In the shell I read: s_linux.c:26:sys/asoundlib.h: file o directory non esistente. I use Mandrake 7.2 and I've installed X interface, gcc, and XFree-devel. When I digit "wish" a windows appear. Can someone help me telling as I must compile and install the program, or what I do to do that. With many thanks MAX
Suddenly I'm curious if everyone experiences this, or just me:
Whenever I destroy a Gem window, PD segfaults. I'm using Miller's PD 0.32 patch 1, and Guenters GEM 0.84 (it happened with 0.83 also). Perahps I should be using Guenters PD with Guenters GEM?
(It would be really nice if all of these disparate distributions got merged into one another, with suitably intelligent "configure" scripts or something - eg the two PDs and the two GEMs)
The (somewhat useless) output from gdb:
GEM: Mark Danks GEM: ver: 0.84 GEM: compiled: Mar 17 2001 GEM: Only using 8 color bits GEM: window created GEM: Start rendering GEM: Stop rendering (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x400cb731 in free () from /lib/libc.so.6
I am using the NVidia accelerated drivers under X4.0.2, so I'm willing to blame them :)
pix.
I get lots of segfaults closing Gem windows too. For he moment I ignore them although someday if nobody else does it I'll track them down...
I agree we need someday to merge distributions and get them so they won't go out of sync... I can't yet get a version of Pd together that can run under both RH 6.2 and RH 7.0!
cheers Miller
On Sun, Mar 18, 2001 at 11:24:50AM +1030, pix@test.at wrote:
Suddenly I'm curious if everyone experiences this, or just me:
Whenever I destroy a Gem window, PD segfaults. I'm using Miller's PD 0.32 patch 1, and Guenters GEM 0.84 (it happened with 0.83 also). Perahps I should be using Guenters PD with Guenters GEM?
(It would be really nice if all of these disparate distributions got merged into one another, with suitably intelligent "configure" scripts or something - eg the two PDs and the two GEMs)
The (somewhat useless) output from gdb:
GEM: Mark Danks GEM: ver: 0.84 GEM: compiled: Mar 17 2001 GEM: Only using 8 color bits GEM: window created GEM: Start rendering GEM: Stop rendering (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x400cb731 in free () from /lib/libc.so.6
I am using the NVidia accelerated drivers under X4.0.2, so I'm willing to blame them :)
pix.
Hey, I 'fixed' this problem (for me at least) by upgrading my NVidia driver. It also seems to have fixed another bug I was experiencing in which closing a patch that still had an open data subpatch would kill PD.
If anyone is interested I'm running Debian unstable, with XFree86 4.0.2-1, the NVidia drivers 0.9-769 (Riva TNT2 card), PD 0.32p1 (Miller's version) and GEM 0.84 (Guenter's linux version). Oh, and kernel 2.2.18.
Previously I was running the 0.9-5 NVidia drivers, and that seemed to be causing both problems (which makes some sense since they were both graphic-related).
So, the code is in the clear! :)
Maybe now I can look into doing something interesting with GEM. Did anyone come up with any cluey ideas for getting performable video output from a PC/Linux situation?
pix.
On Sat, 17 Mar 2001, Miller Puckette wrote:
I get lots of segfaults closing Gem windows too. For he moment I ignore them although someday if nobody else does it I'll track them down...
I agree we need someday to merge distributions and get them so they won't go out of sync... I can't yet get a version of Pd together that can run under both RH 6.2 and RH 7.0!
cheers Miller
On Sun, Mar 18, 2001 at 11:24:50AM +1030, pix@test.at wrote:
Suddenly I'm curious if everyone experiences this, or just me:
Whenever I destroy a Gem window, PD segfaults. I'm using Miller's PD 0.32 patch 1, and Guenters GEM 0.84 (it happened with 0.83 also). Perahps I should be using Guenters PD with Guenters GEM?
(It would be really nice if all of these disparate distributions got merged into one another, with suitably intelligent "configure" scripts or something - eg the two PDs and the two GEMs)
The (somewhat useless) output from gdb:
GEM: Mark Danks GEM: ver: 0.84 GEM: compiled: Mar 17 2001 GEM: Only using 8 color bits GEM: window created GEM: Start rendering GEM: Stop rendering (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x400cb731 in free () from /lib/libc.so.6
I am using the NVidia accelerated drivers under X4.0.2, so I'm willing to blame them :)
pix.
On Thu, 22 Mar 2001 pix@test.at wrote:
So, the code is in the clear! :)
It is, that part of the code didn't change for years, and it has always been running on mesa. It stopped working for when GLX came up, and in fact the problem is not a segmentation fault, but a failed X windows request. (for me at least). As X runs asyncronous it is hard to track them down generally. You first have to make X run in synchronous mode and put a breakpoint into the "exit" function (The exit function is the default handler for failed X windows requests). The you are able to find out which call causes the problems. Starting from that you might be able to remove the problem by doing the same thing in another way, changing paramters for the call, or .. it just might not be possible to remove the problem.
Maybe now I can look into doing something interesting with GEM. Did anyone come up with any cluey ideas for getting performable video output from a PC/Linux situation?
We are using an external VGA/TV converter ...
Guenter
On Fri, 23 Mar 2001, guenter geiger wrote:
On Thu, 22 Mar 2001 pix@test.at wrote:
Maybe now I can look into doing something interesting with GEM. Did anyone come up with any cluey ideas for getting performable video output from a PC/Linux situation?
We are using an external VGA/TV converter ...
can it select a subsection of the screen, or are you running the interface on a different machine? as the problem is that you can't have the gem window on the video output, while having the pd interface still visible at the same time.
or perhaps you are using midi control or somesuch, so that having no interface is not an issue?
my patches are all still somewhat reliant on pd numberboxes and ggee sliders/envgens for interactivity.
my current thought is to have the pd interface on another machine using the new gui options... i dont know if this is a possibility tho (i havent tried it yet)... also if it did work, would the gem window open up on the machine running pd or on the machine running pd-gui (i'm hoping it would open on the machine running pd).
pix.
This should work... you can feed Pd a command line option "-guicmd" to set how Pd will start the GUI up, which could use rsh to start up on another machine, or even set the DISPLAY variable. In either case Gem's window should start up on the machine Pd is running on.
I got this working once but I have another problem, which is that I don;t have a good way of sizing and positioning the Gem window to cover all of the display. Should be easy, but it didn't just work instantly when I tried it.
cheers Miller
my current thought is to have the pd interface on another machine using the new gui options... i dont know if this is a possibility tho (i havent tried it yet)... also if it did work, would the gem window open up on the machine running pd or on the machine running pd-gui (i'm hoping it would open on the machine running pd).
pix.
On Fri, 23 Mar 2001, Miller Puckette wrote:
I got this working once but I have another problem, which is that I don;t have a good way of sizing and positioning the Gem window to cover all of the display. Should be easy, but it didn't just work instantly when I tried it.
since resizing the gem window doesnt acutally seem to change the size of the area being rendered (even after stopping/starting rendering), you are going to have to know the screen size in your patch and set it in the window. but as for getting the window in the right place: most windowmanagers will let you setup default display properties for certain windows (determined by title, or other features). with sawfish it's all done in the gui (gnome control centre thing) in the "matched windows" section. you would just tell it that you want the gem window (conveniently always titled gem) to be maximised, and rendered as borderless. then tadah, you are rendering to the entire display.
you will probably want to verse yourself with the control keeys for navigating your windowmanager, so that you can kill the window, or push it to the back. and get back to normality.
pix.
HI Pix, Miller and others
the way I have this running is to seperate the control to a laptop and the rendering to a linux box with a good graphics card. i use netsend/netreceive to send info from the laptop to a patch i have written on the box which opens the gem window at maximum size. i use pd -nogui on the box to get rid of the gui. i use twm as the window manager as it should be the simplest and fastest. i have added my own .twmrc to remove title bars and boundaries from the window, but i cannot get the positioning requests to be honoured, so i have to drag the top left corner of the gem window to the top left corner of the screen manually. suggestions welcome
i chose netsend as the control mech because i believe it would be the simplest and fastest rather than using some remote control / X-window confusion.
this is planned also to be very portable - for a workshop i need only take the video card and linux install CDs, all the extra code is on the laptop, so i can de-Bill a PC at the venue and make it do clever (well, half-clever) things [hopefully] quite quickly....
haha
tm
Miller Puckette wrote:
This should work... you can feed Pd a command line option "-guicmd" to set how Pd will start the GUI up, which could use rsh to start up on another machine, or even set the DISPLAY variable. In either case Gem's window should start up on the machine Pd is running on.
I got this working once but I have another problem, which is that I don;t have a good way of sizing and positioning the Gem window to cover all of the display. Should be easy, but it didn't just work instantly when I tried it.
cheers Miller
my current thought is to have the pd interface on another machine using the new gui options... i dont know if this is a possibility tho (i havent tried it yet)... also if it did work, would the gem window open up on the machine running pd or on the machine running pd-gui (i'm hoping it would open on the machine running pd).
pix.
I'm really interested in the 'remote gui' option rather than the netsend/receive option, as it doesnt really require any functional changes to existing patches. but at the moment im not in a oaition to test it, only having the one pc. but real soon now i'll be getting a laptop (curently in the 10-14 business days tease-zone), so i'll probably give it a whirl then.
another thing i hadn't thought about until today was looking into the possibility of using multiple gfx cards under x4. it might not be possible, but if it were possible to do multi-head using two different kinds of cards (i know its possible with expensive cards that support multihead) than you could just have the gem window appearing on whichever one has video out. maybe i'm ascribing mythical superpowers to x4 here :)
also, a friend forwarded me some mailing list exceprts about huge latencies using usb-audio solutions on laptops under windows (using audiomulch). has anyone on this list played with usb-audio (especially under linux), and what kind of latencies have they got? i'm hoping the latency isnt inherent in usbaudio, but i wouldnt be surprised if it was...
(then again, my current patch has so much inherent latency, that this wouldnt really be a problem for me anyhow, but i'm just curious).
On Wed, 28 Mar 2001, Timmy B wrote:
HI Pix, Miller and others
the way I have this running is to seperate the control to a laptop and the rendering to a linux box with a good graphics card. i use netsend/netreceive to send info from the laptop to a patch i have written on the box which opens the gem window at maximum size. i use pd -nogui on the box to get rid of the gui. i use twm as the window manager as it should be the simplest and fastest. i have added my own .twmrc to remove title bars and boundaries from the window, but i cannot get the positioning requests to be honoured, so i have to drag the top left corner of the gem window to the top left corner of the screen manually. suggestions welcome
i chose netsend as the control mech because i believe it would be the simplest and fastest rather than using some remote control / X-window confusion.
this is planned also to be very portable - for a workshop i need only take the video card and linux install CDs, all the extra code is on the laptop, so i can de-Bill a PC at the venue and make it do clever (well, half-clever) things [hopefully] quite quickly....
haha
tm
Miller Puckette wrote:
This should work... you can feed Pd a command line option "-guicmd" to set how Pd will start the GUI up, which could use rsh to start up on another machine, or even set the DISPLAY variable. In either case Gem's window should start up on the machine Pd is running on.
I got this working once but I have another problem, which is that I don;t have a good way of sizing and positioning the Gem window to cover all of the display. Should be easy, but it didn't just work instantly when I tried it.
cheers Miller
my current thought is to have the pd interface on another machine using the new gui options... i dont know if this is a possibility tho (i havent tried it yet)... also if it did work, would the gem window open up on the machine running pd or on the machine running pd-gui (i'm hoping it would open on the machine running pd).
pix.
--
\ / Tim Boykett mailto:tim@timesup.org \ / TIME'S UP / Industriezeile 33 B /\ A-4020 Linz /xx\ ph/fax:+43/732-787804 /xxxx\ http://www.timesup.org
I read:
latencies using usb-audio solutions on laptops under windows (using audiomulch). has anyone on this list played with usb-audio (especially under linux), and what kind of latencies have they got? i'm hoping the latency isnt inherent in usbaudio, but i wouldnt be surprised if it was...
Not exactly, but I remember reading an article about usb midi interfaces for professional (i.e. recording studio) application and it stated sth. about general USB latencies being in a range that are unacceptable even for tightly timed midi usage (not to mention audio). So I guess esp. for mobile use we all rather get laptops with IEEE1394 ifaces and wait for good audio products here ....
hope that helps, if I can dig up the URL that info comes from I'll let you know.
atb
x
I've been using the Swissonic Studio D USB audio interface under Linux with my laptop and after some initial difficulties it seems to work fine. The latency is nominal. I haven't done any hard-core testing, but the total latency (including audio buffer) is definately under 50 ms. It seems all the horror stories about usb are not true (well, most of them anyway). I can even use a usb joystick on the same port (with a hub) at the same time, which makes sense since full duplex 44.1k 16 bit stereo should only require about 350KByte/s of bandwidth and USB (ideally) offers 1.5MByte/s.
The trick with linux is that the drivers only work with devices that are 100% usb audio class compliant. I've only found two devices that can claim that, the Swissonic Studio D and Sound Technology's SoundBuster. The prolem is they're both kind of expensive and the Soundbuster is more of a data aquisition device for acoustic measurements. You also are going to want to get the latest usb kernel modules. I had some problems using a 2.2 backport that all went away when I moved to 2.4.1. Also, I have an OHCI controller which everybody seems to say doesn't wor well, but it's been working fine for me. Some things are a little weird but nothing unworkable.
In my understanding, most of the usb audio problems come from the fact that usb is, by default, asynchronous. Latency becomes a huge issue, then, since there's no way to ensure data is getting to its destination on time, especially if there are other devices sharing the buss. USB does, however, have an isosynchronous mode, which is, I think, used with the "audio class" devices you mentioned. This mode is designed to solve major latency issues, but has not been used by many manufacturers and is, therefore, very expensive. That's my two cents.
Tschuss, Greg
"Joseph A. Sarlo" wrote:
I've been using the Swissonic Studio D USB audio interface under Linux with my laptop and after some initial difficulties it seems to work fine. The latency is nominal. I haven't done any hard-core testing, but the total latency (including audio buffer) is definately under 50 ms. It seems all the horror stories about usb are not true (well, most of them anyway). I can even use a usb joystick on the same port (with a hub) at the same time, which makes sense since full duplex 44.1k 16 bit stereo should only require about 350KByte/s of bandwidth and USB (ideally) offers 1.5MByte/s.
The trick with linux is that the drivers only work with devices that are 100% usb audio class compliant. I've only found two devices that can claim that, the Swissonic Studio D and Sound Technology's SoundBuster. The prolem is they're both kind of expensive and the Soundbuster is more of a data aquisition device for acoustic measurements. You also are going to want to get the latest usb kernel modules. I had some problems using a 2.2 backport that all went away when I moved to 2.4.1. Also, I have an OHCI controller which everybody seems to say doesn't wor well, but it's been working fine for me. Some things are a little weird but nothing unworkable.
-- __________________________ | | Joseph A. Sarlo | Computer Music Dept. | Peabody Conservatory | Johns Hopkins University | | jsarlo@peabody.jhu.edu |__________________________
On Fri, 30 Mar 2001 pix@test.at wrote:
I'm really interested in the 'remote gui' option rather than the netsend/receive option, as it doesnt really require any functional changes to existing patches. but at the moment im not in a oaition to test it, only having the one pc. but real soon now i'll be getting a laptop (curently in the 10-14 business days tease-zone), so i'll probably give it a whirl then.
another thing i hadn't thought about until today was looking into the possibility of using multiple gfx cards under x4. it might not be possible, but if it were possible to do multi-head using two different kinds of cards (i know its possible with expensive cards that support multihead) than you could just have the gem window appearing on whichever one has video out. maybe i'm ascribing mythical superpowers to x4 here :)
also, a friend forwarded me some mailing list exceprts about huge latencies using usb-audio solutions on laptops under windows (using audiomulch). has anyone on this list played with usb-audio (especially under linux), and what kind of latencies have they got? i'm hoping the latency isnt inherent in usbaudio, but i wouldnt be surprised if it was...
(then again, my current patch has so much inherent latency, that this wouldnt really be a problem for me anyhow, but i'm just curious).
On Wed, 28 Mar 2001, Timmy B wrote:
HI Pix, Miller and others
the way I have this running is to seperate the control to a laptop and the rendering to a linux box with a good graphics card. i use netsend/netreceive to send info from the laptop to a patch i have written on the box which opens the gem window at maximum size. i use pd -nogui on the box to get rid of the gui. i use twm as the window manager as it should be the simplest and fastest. i have added my own .twmrc to remove title bars and boundaries from the window, but i cannot get the positioning requests to be honoured, so i have to drag the top left corner of the gem window to the top left corner of the screen manually. suggestions welcome
i chose netsend as the control mech because i believe it would be the simplest and fastest rather than using some remote control / X-window confusion.
this is planned also to be very portable - for a workshop i need only take the video card and linux install CDs, all the extra code is on the laptop, so i can de-Bill a PC at the venue and make it do clever (well, half-clever) things [hopefully] quite quickly....
haha
tm
Miller Puckette wrote:
This should work... you can feed Pd a command line option "-guicmd" to set how Pd will start the GUI up, which could use rsh to start up on another machine, or even set the DISPLAY variable. In either case Gem's window should start up on the machine Pd is running on.
I got this working once but I have another problem, which is that I don;t have a good way of sizing and positioning the Gem window to cover all of the display. Should be easy, but it didn't just work instantly when I tried it.
cheers Miller
my current thought is to have the pd interface on another machine using the new gui options... i dont know if this is a possibility tho (i havent tried it yet)... also if it did work, would the gem window open up on the machine running pd or on the machine running pd-gui (i'm hoping it would open on the machine running pd).
pix.
--
\ / Tim Boykett mailto:tim@timesup.org \ / TIME'S UP / Industriezeile 33 B /\ A-4020 Linz /xx\ ph/fax:+43/732-787804 /xxxx\ http://www.timesup.org
Hmm, I think this might actually be a lot better than my suggestion. thanks! Miller
On Wed, Mar 28, 2001 at 12:41:35PM +0200, Timmy B wrote:
HI Pix, Miller and others
the way I have this running is to seperate the control to a laptop and the rendering to a linux box with a good graphics card. i use netsend/netreceive to send info from the laptop to a patch i have written on the box which opens the gem window at maximum size. i use pd -nogui on the box to get rid of the gui. i use twm as the window manager as it should be the simplest and fastest. i have added my own .twmrc to remove title bars and boundaries from the window, but i cannot get the positioning requests to be honoured, so i have to drag the top left corner of the gem window to the top left corner of the screen manually. suggestions welcome
i chose netsend as the control mech because i believe it would be the simplest and fastest rather than using some remote control / X-window confusion.
this is planned also to be very portable - for a workshop i need only take the video card and linux install CDs, all the extra code is on the laptop, so i can de-Bill a PC at the venue and make it do clever (well, half-clever) things [hopefully] quite quickly....
haha
tm
On Sun, 18 Mar 2001, max wrote:
I'm a novice in Linux, and I cannot run PD. I've unpacked the pd-032-linuxppc.tar, and I make it in scr dir. In the shell I read: s_linux.c:26:sys/asoundlib.h: file o directory non esistente. I use Mandrake 7.2 and I've installed X interface, gcc, and XFree-devel. When I digit "wish" a windows appear.
asoundlib.h comes from a set of sound card drivers called ALSA. I'm not sure what the best way for you to get ALSA for Mandrake is. You could also try using the configure script to compile without ALSA support.
Good luck!
(jfm3)
-
CK -
Greg Rippin -
guenter geiger -
jfm3 -
Joseph A. Sarlo -
max -
Miller Puckette -
pix＠test.at -
Timmy B