Subject: [alsa-devel] Re: RT timing / priorities etc.
From: David Olofson (audiality_AT_swipnet.se)
Date: to syys 02 1999 - 20:32:30 EDT
[This is from a thread on alsa-devel. I think it's starting to look like
something that could fit into the API discussion on linux-audio-dev...]
On Thu, 02 Sep 1999, Paul Barton-Davis wrote:
[...]
> >Ok, that makes sense. But does that mean average latency is more
> >important than jitter? I tend to always prefer things that are under
> >control, while jitter is noise and peaks...
>
> no, jitter is more significant here too.
Ok. But do you really need latency == resolution?
For MIDI, I'd say it's realistic, perhaps even in Linux user space, if we can
get rid of that last 2.9 ms peak. Childs play with RTL, as long as the MIDI
hardware isn't crap. But for audio, it's dedicated DSP, or possibly RTL, if you
don't mind wasting lots of CPU power on context switching, or lock one CPU in
an SMP system for the processing.
> [ pthreads, timer API's ]
>
> >Is the user space implementation missing a proper timer API, or am *I* missing
> >something? ;-)
>
> the pthreads API doesn't include a timer component that exceeds the
> timing resolution of the host OS. On Linux, this means 1/HZ seconds.
Isn't that a pthreads *implementation* issue, rather than one of the API? I
still can't se a problem here, unless the standard specified a maximum allowed
timer resolution or something...
[...]
> >Yes, but that's not going to work if running Cubase and Reaktor together is
> >the basic requirement... :-)
>
> I am not sure that Steinberg or Cubase claim that you can do this kind
> of thing.
They're probably not, as it wouldn't work without increasing the buffer sizes.
But then again, there's so much buffering anyway, that it might not make much
difference what steals the CPU power from one of the applications... They're
tuned for running in a non real time system anyway. (Windoze doesn't have
anything like SCHED_FIFO. Raising the priority of a task to <can't
remember>_REALTIME is about all you can do, and it will NOT give you much
better response time. It *will* make your task stress the system in a very bad
way, though. Nice work, M$...)
[...]
> >things... Lots of user space code, that is. The basic API may not be
> >that hard to port, though, and if it's enough for making applications
> >user space <-> RTLinux portable, that's the way to go.
>
> This is an area where I am not entirely sympathetic to Jaroslav's
> design. I like the idea of hiding a certain amount of change in the
> kernel API with a user-library, and have that done that myself
> before. But I think that the kernel API should be "Unix-compliant" and
> work in obvious ways. The user-level library shouldn't do anything
> "clever". To a large extent this is already true. If you look at most
> of the alsa-lib PCM functions, for example, they are really just
> trivial wrappers for system calls. So I think that making the
> driver/kernel API available is quite sufficient.
Well, if we can get Jaroslav to accept that we still want the kernel API
around... Or the user space library will have to be made very portable. Or
Audiality will have to be integrated with ALSA, which I don't think is a very
good idea if ALSA is to be in the standard kernels. Finally, there's always the
OSS API... But I think I'll need some extra ioctls for sample accurate sync and
that kind of stuff, as I don't think starting all soundcards at the same time
is a very nice approach. Pro cards *have* sync hardware, and it would be a
shame not to use it when the entire Audiality/RTLinux engine could sync rock
solid with anything.
> [ quasimodo, processing nets, plugins-vs-programming ]
>
> >But does that save you from solving the actual problems...? You still have to
> >get buffers of sufficient size together to drive sound cards, and what happens
> >if you have two or more, which require different buffer sizes? And what's the
> >difference between plug-ins and other solutions WRT code optimization?
>
> can you give me a more concrete example ? i am having trouble figuring
> out a real life case that has problems associated with it.
FFT. It is *possible* to do on non-power-of-2 buffer sizes, but that's hard to
optimize. Many other algorithms, and most SIMD implementations have similar
restrictions, so we *could* just say that "a buffer is always 2^N samples", and
hope that noone will come up with an algorihtm that works better with, say,
3 * 2^N samples...
The point is that I don't want to force plug-ins to use internal buffers just
because the engine refuses to accept it's buffer size requirements. It's kind
of pointless to copy data around in such cases, when the engine will need to
support mixed buffer sizes anyway for other reasons.
> >(Processing of arrays, array size restrictions for certain algorithms etc. No
> >other way to do it, unless you have lots of CPU registers, which is not the
> >case with toys like x86...)
>
> Quasimodo compiles down its module definitions into a linked list of
> ptrs-to-functions (although it inlines all arithmetic and logical
> expressions). If the audio block size (the number of frames generated
> per DSP cycle) is reasonably sized (i'm not sure how big that is, but
> its probably about 16-32 frames and above), then the
> pointer-indirection+function call overhead is insignificant compared
> to the computation done by 99.5% of the functions, particularly those
> that generate audio samples. As a result, even though you are using an
> interpreted language, using an expression like
>
> an_output oscil arg1, arg2, arg3
>
> is going to end up as native, compiled, optimized code, implemented as
> well as your C++ compiler can do it. No global register optimization, true.
So how much does this differ from a (properly designed) plug-in system WRT
function call overhead? To me it seems more like a matter of implementation
than of design... True, the event system I proposed for the new plug-in API
will result in one extra buffer to pass to the plug-in callbacks, but I can
hardly see a way to get around that without completely killing all flexibility
and extensibility. And that event system handled *everything* that's not audio
data, so there's really nothing more to it. No hidden complexity, or
plug-in-to-host callbacks that may be used more frequently than expected. Just
events + data in, events + data out.
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
------
To unsubscribe from <alsa-devel_AT_alsa-project.org> mailing list send message
'unsubscribe' in the body of message to <alsa-devel-request_AT_alsa-project.org>.
BUG/SMALL PATCH REPORTING SYSTEM: http://www.alsa-project.org/cgi-bin/bugs
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:53 EST