[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linrad] Re: Portaudio
- Subject: [linrad] Re: Portaudio
- From: Robert McGwier <comcast.net; rwmcgwier@xxxxxxxxxxxxxxxx>
- Date: Fri, 21 Apr 2006 08:15:05 -0400
Leif Asbrink wrote:
I hope this API will help you resolve some of these issues in your
favor. We can test it to find out.
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)
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
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
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
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.
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
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
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.
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.
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>