Subject: Re: [linux-audio-dev] Another Annoying "How Do I Get Started" Question
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Wed Jul 11 2001 - 17:30:02 EEST
On Wednesday 11 July 2001 15:22, Greg Berchin wrote:
>
> Even without SIMD, GP processors are getting so fast that DSPs are no
> longer the only game in town.
Yes, I do agree: my samples does not use SIMD and it does pretty well already.
>
> >The only problem with PCs is that you have to be careful when wanting to
> >get low latencies.
>
> For my purposes it is not a problem. As long as the latency is low enough
> to avoid lip sync problems when processing audio associated with video
> (which means below approximately 30 mSec), I am happy.
Then you do not need any special hacks.
Just take a standard linux distro, install ALSA (or use if you like OSS),
install a a low latency kernel (the best one is Andrew Morton's 2.4.5 patch,
but I think a patch for 2.4.6 will be out soon)
and run your app with SCHED_FIFO privileges.
That's all. Rock solid 2.1msec input-to-output latencies under any
circumstance. (even while physically sawing the disk in two pieces :-) )
>
> >If you are careful to shut down all other stuff, not using virtual
> >memory , letting you application run SCHED_FIFO (realtime scheduling)
> >and using busywait memory mapping audio I/O ... then I believe you can
> >get pretty close to the lower limit
>
> Ultimately I would like to know enough to hack the kernel, removing
> everything that is not needed for audio support. I chose Linux simply
> because it is available and has good support; I do not consider it to be
> sacred in any way. As I said, my system will be standalone,
> single-application, audio-only. I believe that the kernel can be seriously
> trimmed and still give me what I need. I just don't know how to do it,
> yet.
No need to trim anything: you can leave the kernel as it is.
If you want to trim down the size for space reason, you can just leave out
some of the modules (eg drivers for network cards, isdn etc), but when it
comes to realtime performance there is no need to make any change rather than
having a kernel patched with the low latency patch.
A friend of mine will produce an RPM package of the 2.4.5-lowlat kernel so in
a few days so if you want to avoid the burden of doing the recompilation,
you can install in in matter of seconds.
I will post the download link in a few days (probably early next week).
>
> >When you chose to stay in userspace (sacrificing single sample latency)
> >you things get very confortable for you:
> >you write a simple LADSPA host once (eg one that simply loads one/more
> >plugins and then sits in a loop reading from the soundcard, calling the
> >dsp stuff contained in plugins and then output it to the soundcard).
>
> THAT is exactly what I am looking for, then. My first goal is creation or
> adoption of this basic framework with a simple dummy DSP routine in the
> middle. Once the I/O framework is in place, then it is a simple matter of
> plugging-in the appropriate subroutine(s) in place of the dummy routine.
Look at the applyplugin.c routing in the LADSPA sdk, basically all you need
to add is a routine that opens an ALSA (or OSS) device, reads from ADC, feeds
it to the LADSPA plugin chain and write the output back to the output.
That's all folks. (just cut'n paste the ALSA code from other apps).
Probably I will write such stuff by myself since I do need it anyway for my
stresstests. (I love to stress the OS to its limits)
>
> >Greg, your help for DSP stuff will be very welcome, especially when
> >trying to squeeze out the maximum performance of applications.
>
> I will be glad to (try to) answer any questions that come my way. If I
> don't know the answer, I probably know someone who does. The audio DSP
> world is rather small, and most of us know each other.
Ok, thanks.
BTW: I'd like to know some people that are experts in programming FPU code on
intel cpus (I hate it because the fpu stack is really weird).
It might help to speed up some of the interpolation code.
>
> >BTW: at LinuxTag we made some experiments with Muse driving the
> >disksampler and on Frank's 1Ghz machine ... 70voices ... causes a CPU
> >load of about 30-35% which is quite acceptable IMHO.
>
> That is encouraging. I do know from experience, however, that the Ideal
> Gas Law applies (the application expands to fill the available processing
> power). There is always some new feature to add ...
Of course, but I plan to integrate some fancy stuff like dynamic
recompilation of audio rendering routines in order to maximize speed, a
technique that closed source software cannot use. (otherwise you discover
their "trade secrets".
>
> Thanks again, to you and all who have responded,
Always at your disposal.
:-)
As we use to say in Italy: "una mano lava l'altra" which translates into "one
hand washes the other one" (not sure if it makes sense in english but it
means something like I help you and you help me"
:-)
Benno.
This archive was generated by hypermail 2b28 : Wed Jul 11 2001 - 17:55:56 EEST