Hi all,
I've folded in Karl's new ALSA code, and for synchronization purposes I'm putting out the result as "pd-030TEST-linux.tar.gz" in http://lena.ucsd.edu/~msp/Software
I had trouble marging the two because Karl's indentation is different from mine; I preserved 4-space indentation in the OSS and RME code but kept Karl's in the ALSA part.
I'm mystified about Guenter's report of socket() returing 1. I don't know how stdout is getting closed but I think it really shouldn't be. I'll test this tonight...
also Mark Danks reports that close() doesn't undo the work of open_via_path on NT. I'm mystified about that too but will try to track it down.
cheers Miller
Miller,
Pardon me if I'm misunderstanding, but if you're referring to the
formatting of source code by "indentation", there is a wonderful utility that functions both as a stand alone app and/or as an extension to VC6 (maybe VC5 too I don't know) called Visual Source Format. It is very powerful and flexible, allowing one to format large quantities of source code at once according to standardized formats or by any custom format that you define. You can learn more about it here:
http://www.ralgi.com/products/vsf/vsfinaction.html
It can save countless hours of headache by bring reams of disparate source into a common format in just minutes.
Sincerely, Ben
Miller Puckette wrote:
Hi all,
I've folded in Karl's new ALSA code, and for synchronization purposes I'm putting out the result as "pd-030TEST-linux.tar.gz" in http://lena.ucsd.edu/~msp/Software
I had trouble marging the two because Karl's indentation is different from mine; I preserved 4-space indentation in the OSS and RME code but kept Karl's in the ALSA part.
I'm mystified about Guenter's report of socket() returing 1. I don't know how stdout is getting closed but I think it really shouldn't be. I'll test this tonight...
also Mark Danks reports that close() doesn't undo the work of open_via_path on NT. I'm mystified about that too but will try to track it down.
cheers Miller
Miller,
Sorry about that - I ran s_linux.c through gnu indent (the unix equivalent to the product you described, Ben) because there was a lot of code wider than 80 cols but didn't mean to send you that copy. I was going to copy my code into a clean copy of s_linux.c but forgot. 4 spaces is fine with me and I will use that from now on. As a side note, anybody know how to prevent emacs from indenting braces after if statements?
About the Alsa code - please test it if you have ALSA. It should work for any version higher than .50. The code will probably continue to change as the ALSA documentation is finished and some final API decisions are made (and I remove some dubious code that I wrote just to get something for PD .30).
Karl
Benjamin Israel wrote:
Miller,
Pardon me if I'm misunderstanding, but if you're referring to theformatting of source code by "indentation", there is a wonderful utility that functions both as a stand alone app and/or as an extension to VC6 (maybe VC5 too I don't know) called Visual Source Format. It is very powerful and flexible, allowing one to format large quantities of source code at once according to standardized formats or by any custom format that you define. You can learn more about it here:
http://www.ralgi.com/products/vsf/vsfinaction.html
It can save countless hours of headache by bring reams of disparate source into a common format in just minutes.
Sincerely, Ben
Miller Puckette wrote:
Hi all,
I've folded in Karl's new ALSA code, and for synchronization purposes I'm putting out the result as "pd-030TEST-linux.tar.gz" in http://lena.ucsd.edu/~msp/Software
I had trouble marging the two because Karl's indentation is different from mine; I preserved 4-space indentation in the OSS and RME code but kept Karl's in the ALSA part.
I'm mystified about Guenter's report of socket() returing 1. I don't know how stdout is getting closed but I think it really shouldn't be. I'll test this tonight...
also Mark Danks reports that close() doesn't undo the work of open_via_path on NT. I'm mystified about that too but will try to track it down.
cheers Miller
Miller,
In s_main.c the -blockmode and -queuesize messages are in the RME define instead of the HAVE_ALSA define so they show up even if alsa support isn't compiled in - line 202. Also, pd doesn't compile without the RME code. Looks great other than that - the watchdog looks exciting though I have only had pd lock up the machine once under realtime and I think that was my fault. Oh, do you mean to be distributing a gnu chess game :) Are we going to see the gnuchess and PD file formats merge for interactive chess composition?
Thanks,
Karl
Miller Puckette wrote:
Hi all,
I've folded in Karl's new ALSA code, and for synchronization purposes I'm putting out the result as "pd-030TEST-linux.tar.gz" in http://lena.ucsd.edu/~msp/Software
I had trouble marging the two because Karl's indentation is different from mine; I preserved 4-space indentation in the OSS and RME code but kept Karl's in the ALSA part.
I'm mystified about Guenter's report of socket() returing 1. I don't know how stdout is getting closed but I think it really shouldn't be. I'll test this tonight...
also Mark Danks reports that close() doesn't undo the work of open_via_path on NT. I'm mystified about that too but will try to track it down.
cheers Miller
Thanks for the warnings... I've fixed these in my copy, except ... gnuchess??? I'm not sure where that's coming from.
I haven't been compiling for ALSA in the distributed version because I've never been able to figure out how to get Pd to link to ALSA non-shared. If you link to the Alsa shared libs Pd won't run on a non-ALSA machine. Someday I'll try again to figure out how to make this work...
Right now I'm trying to fix an ugly problem duplicating abstractions with arrays inside...
cheers Miller
On Tue, Mar 07, 2000 at 07:34:20PM -0500, Karl MacMillan wrote:
Miller,
In s_main.c the -blockmode and -queuesize messages are in the RME define instead of the HAVE_ALSA define so they show up even if alsa support isn't compiled in - line 202. Also, pd doesn't compile without the RME code. Looks great other than that - the watchdog looks exciting though I have only had pd lock up the machine once under realtime and I think that was my fault. Oh, do you mean to be distributing a gnu chess game :) Are we going to see the gnuchess and PD file formats merge for interactive chess composition?
Thanks,
Karl
Miller Puckette wrote:
Hi all,
I've folded in Karl's new ALSA code, and for synchronization purposes I'm putting out the result as "pd-030TEST-linux.tar.gz" in http://lena.ucsd.edu/~msp/Software
I had trouble marging the two because Karl's indentation is different from mine; I preserved 4-space indentation in the OSS and RME code but kept Karl's in the ALSA part.
I'm mystified about Guenter's report of socket() returing 1. I don't know how stdout is getting closed but I think it really shouldn't be. I'll test this tonight...
also Mark Danks reports that close() doesn't undo the work of open_via_path on NT. I'm mystified about that too but will try to track it down.
cheers Miller
-- _____________________________________________________ | Karl W. MacMillan | | Peabody Institute of the Johns Hopkins University | | Network and Telecommunications Services | | karlmac@peabody.jhu.edu | | 410/659-8297 |
There is what looks like a saved game of gnu chess in the tar file under pd/src. The file name is CLp79.Jan01-221509B and contains:
gnuchess 4p79 game score depth nodes time score depth nodes time e2e4 0 0 0 33 c7c5 -44 Book 0 0 d1h5 0 0 0 37 g8f6 10 10 5027040 85 h5f3 0 0 0 118 b8c6 40 8 501248 8 g2g4 0 0 0 121 d7d5 183 8 467747 8 g4g5 0 0 0 29 c6d4 187 7 1375049 18
Didn't mean to be obtuse.
As far as compiling ALSA, the programs that I have seen that used alsa (alsaplayer specifically) use 'plugins' to provide the alsa support. It seems wasteful to statically link the library so maybe some sort of plugins could be used - I assume that most of the support is there with the externals.
One other note about the ALSA support - I get some strange sounds when starting PD with ALSA sometimes that sound like garbage left in the buffers (of the driver - not PD). I make the API calls that I think should flush the buffers but they don't seem to do the trick. If anyone knows how to fix this it would be great.
Karl
On Wed, 8 Mar 2000, Miller Puckette wrote:
Thanks for the warnings... I've fixed these in my copy, except ... gnuchess??? I'm not sure where that's coming from.
I haven't been compiling for ALSA in the distributed version because I've never been able to figure out how to get Pd to link to ALSA non-shared. If you link to the Alsa shared libs Pd won't run on a non-ALSA machine. Someday I'll try again to figure out how to make this work...
Right now I'm trying to fix an ugly problem duplicating abstractions with arrays inside...
cheers Miller
On Tue, Mar 07, 2000 at 07:34:20PM -0500, Karl MacMillan wrote:
Miller,
In s_main.c the -blockmode and -queuesize messages are in the RME define instead of the HAVE_ALSA define so they show up even if alsa support isn't compiled in - line 202. Also, pd doesn't compile without the RME code. Looks great other than that - the watchdog looks exciting though I have only had pd lock up the machine once under realtime and I think that was my fault. Oh, do you mean to be distributing a gnu chess game :) Are we going to see the gnuchess and PD file formats merge for interactive chess composition?
Thanks,
Karl
Miller Puckette wrote:
Hi all,
I've folded in Karl's new ALSA code, and for synchronization purposes I'm putting out the result as "pd-030TEST-linux.tar.gz" in http://lena.ucsd.edu/~msp/Software
I had trouble marging the two because Karl's indentation is different from mine; I preserved 4-space indentation in the OSS and RME code but kept Karl's in the ALSA part.
I'm mystified about Guenter's report of socket() returing 1. I don't know how stdout is getting closed but I think it really shouldn't be. I'll test this tonight...
also Mark Danks reports that close() doesn't undo the work of open_via_path on NT. I'm mystified about that too but will try to track it down.
cheers Miller
-- _____________________________________________________ | Karl W. MacMillan | | Peabody Institute of the Johns Hopkins University | | Network and Telecommunications Services | | karlmac@peabody.jhu.edu | | 410/659-8297 |
| Karl W. MacMillan | | Peabody Institute of the Johns Hopkins University | | Network and Telecommunications Services | | karlmac@peabody.jhu.edu | | 410/659-8297 |
Miller Puckette writes:
I'm mystified about Guenter's report of socket() returing 1. I don't know how stdout is getting closed but I think it really shouldn't be. I'll test this tonight...
I'm getting more and more confused by this too. I have to investigate further, and it seems that the socket problem may be related to the fact, that it is impossible to use gem with abstractions under linux. (X uses sockets for communication to the gem window too).
I seems that that socket() somehow doesn't care if any files with the same descriptor are already open. This might work as long as we use recv() and send() on sockets, but what if we use select() and close() ? Should they work with the file (e.g. stdout) or with the socket with descriptor 1. The hack with just dup() ing the sockets fd doesn't work either, as it seem that if I open new files (e.g with sfread), I get descriptors back which are already sockets sometimes.
Considering the huge amount of network software for linux, I just can't believe that this is a linux bug, on the other hand it's not a problem on any other platform but linux.
????????
Guenter
-
Benjamin Israel -
Guenter Geiger -
Karl MacMillan -
Karl W. MacMillan
-
Miller Puckette