>> >did also notice when running the pcm example in async mode, if I started
>> >moving scrollbars and the like in my KDE environment, continuous glitches
>> >came into the audio.
>> no suprise there. i imagine you were handling the "audio device ready"
>> SIGIO signal in the same thread as the GUI, right? common mistake #1.
>
>Well, no... there is no GUI as such - this is an embedded application.
>Actually, correction - there is a GUI, but not on the PC. ;)
>
>All the stages are linked via. circular buffers, from input to output. I
>was under the impression that the "async" callback routine executes at
>effective "realtime" priority (it wouldn't make sense to have it any other
absolutely not. SIGIO is delivered to your process/thread just like
any other signal. it will mark your thread as ready-to-run if it was
not ready before. when its scheduled to run, it will execute its
signal handler (or exit if it hadn't defined one). now, as to when it
gets scheduled to run depends on the threads scheduling class and
priority, amongst other things. if its class is SCHED_FIFO and the
priority is right, it will run extremely soon after the SIGIO signal
is raised (or delivered to it, to be more precise, but they are almost
contemporaneous on Linux). how soon depends on the kernel. this is
what the low latency (and preemption) patches are all about: reducing
this delay in the running of a ready-to-run thread to the absolute
bare minimum. however, even with those patches, without using
SCHED_FIFO or SCHED_RR, the delay prohibits the system from being
considered "realtime".
>way - why would Jaroslav bother implementing it otherwise?), and mine serves
>the purpose of picking off buffers as available, dumping them to the
>soundcard - the bare minimum for very low CPU usage.
poll(2) accomplishes this with a synchronous execution path, thus
removing the problems of executing code within a POSIX signal handler.
>The disappointing thing is that the machine should get so overloaded by a
>simple window movement that it misses the SIGIO and falls over. I was under
its not overloaded. there is a lot more to this than you're seeing,
though i agree that there should not be. there are, for example,
problems with the interaction between some video interfaces, the PCI
bus and some versions of the X server that can produce effective
"processor stalls". thats just one example.
>I know I need another thread even though there is little going on at the
>control level. I recognised this many months ago... just surprised at how
>badly Linux reacted to code which worked fine under Win9x.
the multithreading models are extremely different.
>> i'm sad to say this, but most people don't have a clue about writing
>> real-time audio applications for linux (or POSIX systems in
>> general). the issues are subtle, some of them are complex. ALSA
>> doesn't address them, nor does it seek to (at least not at this time).
>
>Hmm... I thought the one the main reasons for ALSA was to introduce
>low-latency audio to Linux?!
And it succeeds admirably at that goal. That doesn't mean its simple
to get it to work, notably because the Linux kernel has to play ball
as well, and standard versions of the kernel do not play
ball. applications also have to correctly designed and written, and
most are not.
>Took a quick look at the website. Looks interesting. Could you send me a
>CVS snapshot? I don't have dialup on the Linux machine to access it via.
>CVS.
there will be tarball release next week. check back then.
>on Linux, but I didn't see a whole lot of issues to deal with.
thats what i thought when i started out doing this stuff :)
>Once the kernel is scheduling to my requirements, with (preferably) no
right, but this is not a trivial thing. interactions between the VM
system and the scheduler have caused constant headaches in this area
for a long time. its distinctly non-trivial to get an application
in which a certain block of code will be executed at the right time,
on time, every time. it can be done, for sure, but its not trivial,
and it has complications in that it requires either root permissions
or a kernel built with capabilities enabled and a program that can
grant CAP_RESOURCE. why? how does the kernel know that your program
won't simply take over the machine?
>Latency is not critical... a total of up to 500ms is acceptable. Given that
Not much hardware can offer than much. A typical limit is on the order
of 8k to 16k frames of audio. BTW, most of us wouldn't consider this
even in the realm of low latency, which for most people means
something like 1-5msecs.
>the system will spend 99% of its time operating from a non-realtime source,
>there is plenty of opportunity for buffering.
sure. but you can still mess things up with application design. take
the following example:
while (1) {
wait_for_audio_to_be_possible ();
read_audio_from_disk ();
write_to_audio_interface ();
}
that design will work just fine under some circumstances, and be
guaranteed to cause dropouts under others. lets add some buffering:
thread 1:
while (1) {
wait_for_disk_data_needed();
fill_buffers ();
}
thread 2:
while (1) {
wait_for_audio_to_be_possible ();
write_to_audio_interface_from_buffers ();
}
well, that looks better, except if the implementation of
fill_buffers() and write_to_audio_interface_from_buffers() uses a
mutex and its not used "appropriately", this design will still work in
some cases and cause dropouts in others.
and so on and so forth ...
>The CPU is probably going to be a 1.2GHz Celeron-II. No shortage of grunt.
>When all of my code is optimised, I'm looking at maybe 40% max.
>utilisation... if I can't get it low enough after significant opt. work,
>I'll get the Intel compiler and maybe throw some SSE in there.
>
>> async mode is not the right choice for apps in that class:
>
>Well, logically, using realtime callbacks to generate buffers as and when
>the soundcard requires them is the _perfect_ choice for a realtime system.
true. but thats not what you're doing. what you're doing is getting
the driver to generate POSIX signals that are delivered to your
process. that's nothing like a true callback system, because as i've
said, the code that can safely be executed within the POSIX signal
handler is limited. this is more like MacOS <X, where ASIO (and other
audio APIs) cause the audio code to be executed in "interrupt
context", so you can't do certain things (a perennial problem for some
VST plugin writers).
>My same code works just fine using ASIO at low latency. Steinberg have come
>up with a simple API that does the business... it was a pleasure to work
>with.
True. I consider ASIO to be a useful model for JACK, though Apple's
CoreAudio (no doubt inspired by ASIO) is cleaner and slightly more
elegant because its not only providing for i/o associated with h/w.
>I was not aware of the method which ALSA employed to generate the callback -
>I just expected it to _work_ like it does in Win9x (optimistic, it would
>appear). Okay, ALSA async is dodgy... I won't use that mode, then. But at
>least Jaroslav has fixed it so it doesn't crash on shutdown now!
if you use poll(2) for synchronous notification, things will work
pretty much the way they do under ASIO. better actually, though ALSA
doesn't wrap the use of poll(2) in any particularly pretty clothing.
--p
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
