[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linrad] Re: Portaudio

Leif Asbrink wrote:

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.
I hope this API will help you resolve some of these issues in your favor. We can test it to find out. 
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.
This should be easy to do and I can start it during the first of May. I am finding that portaudio provides facilities to handle many of these problems but we can do psetad and provide the alternative versions.
For those wishing to download and compile the latest PA code, (the only version worth having in the v19 development branch), you will need subversion (svn). Then the following command will download the code 

svn co https://www.portaudio.com/repos/portaudio/branches/v19-devel

./configure
make
sudo make install
will configure, make and install the code on Linux and OSX. On Windows, I can provide a dll and implib from PowerSDR.
As I said, me personally doing this will be delayed until I get my DttSP work done and will be for early May.
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.
I do not care about making linrad smaller though I am sure some do. Yes, you are right, the hardware does 24 bits A/D at best. However, internally FOR SPEED it will deliver the samples on 32 bit quantities in most drivers so no packing/unpacking is required. We can tell Portaudio what type of format to deliver: 8,16,32 int or 32 bit float but this is not a size of code or speed issue to me. It is a dynamic range, noise floor issue. I do not believe psetad will be hard to do so we can try it. 


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.
After we blow all of this other stuff up and get it stable, then tackling graphics speed with various tools (OpenGL, etc.) will be of great interest. Right now, I would like to see linrad, Xlinrad, Wlinrad all run across myriad platforms with free development tools and free libraries stable. These wholesale changes always introduce instability as you have already said so taking small steps will be good. It is my opinion that in the end, all this will be a big win for all users. 



73

Leif / SM5BSZ
I am traveling for most of the next ten days. I hope to see some of you at NE VHFS meeting or at the SE VHF meeting in the next two weeks. 

Bob

--
AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats,
NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman
Laziness is the number one inspiration for ingenuity.  Guilty as charged!


#############################################################
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