[linrad] Portaudio

[Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>


LINRADDARNIL