Hi Bob and all, > If we use PortAudio, we can have a SINGLE sound system API for all > operating systems and be able to immediately extend your Xlinrad to at > least Intel based OSX boxes (since Portaudio presents a single API for > sound on Windows, Linux, and OSX) and run this code on Windows, Linux, > and Intel-Mac. The problem with Xlinrad on PPC boxes is your assembly > routines of course will not work. For audio, Portaudio will not care > if your underlying system is OSS, ALSA, or on windows ASIO, WDM-KS, > MME, or DirectX.
I do not quite see the reason to have a layer between the underlying system and Linrad. Most problems in the past have been associated with bugs in the underlying sound system and a large fraction of the Linrad interface to sound is actually designed to work around all the different hardware and software relates problems with the sound system. It will however be very easy to modify Linrad for Portaudio Everything that depends on the sound system is contained in setad.c for which currently two versions exist: wsetad.c for Windows (1000 lines) and lsetad.c (2600 lines) for Linux (X or svgalib) If you can replace setad by a "psetad" for Portaudio I can easily include it and add three more commands to the Linrad makefile: make plinrad, plinrad.exe and xplinrad. The assembly routines is no problem at all, there is only one very small routine that has to be rewritten. The big assembly routines are user selectable options and Linrad sets flags that say whether they are allowed or not for the routines using multimedia instructions and it will be trivial to extend this to block all the assembly if the user would need that. The problem is that someone else will have to modify Makefile.in and the other input files to configure for the Linrad package to compile on other types of computers. (I am not going to bring in other kinds of computers here, but I will be happy to include whatever code needed to make Linrad compile on other systems as long as it does not interfere with the compilation under Linux for kernels above 2.2.10 (Old kernels are still needed for old computers) Linrad has a os-depending main.c: lmain.c (700 lines) Linux svgalib xmain.c (550 lines) Linux X11 wmain.c (600 lines) Windows (a large part is the handling of keyboard translation) Then there is an os-depending interface part, sys.c lsys.c (200 lines) Linux svgalib (graphics) wsys.c (600 lines) Windows (graphics, threads and timing) xsys.c (350 lines) Linux X11 (graphics) lxsys.c (380 lines) Linux svgalib and X11 (threads and timing) > Portaudio will do > the opening in the "native mode" and will also give you floating point > (based on 24 bit) samples if you open the card that way and increase > your dynamic range, improve your noise floor, etc. The hardware reads in an integer format of 16 or 24 bit (padded to 32) It is absolutely impossible to gain anything at all by having the sound card interface converting the data to floating point. Surely one can make the Linrad code smaller by reading everything in the same format, but the penalty will be slower execution - at least for 16 bit input and there will be no performance advantage at all. The numbers given above is the situation today of what will become 02-08. The xsys.c routine might grow to perhaps twice the sice when I know how to send 256 colour bitmap images and 16 bit images to X11. The current routines work for 32 bit images only. 73 Leif / SM5BSZ ############################################################# This message is sent to you because you are subscribed to the mailing list <linrad@antennspecialisten.se>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>