Subject: Re: [linux-audio-dev] Re: disksampler ...
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Thu Jul 13 2000 - 23:42:00 EEST
On Thu, 13 Jul 2000, David Benson wrote:
>
> I think that since you have to separate the gui thread from
> the sound thread, the client-server model is a good one.
> alpha-versions of gdam tried another strategy:
> use the same structures in both threads
> with mutexs. I found it really hard to organize, and I was thrown
> off b/c I didn't know how to select() on a pthread_mutex;
> (now i know a nonportable way...)
>
> But of course, if you were going to do that,
> I'd have to try to talk you into just applying your
> experience to gdam :) [or at least let me document the protocol
> so we can try to behave the same "on the wire"]
Mutexes are simply too risky to use in code which has to
ensure 2msec latencies.
The way to go is using lock-free fifos / ringbuffers.
See ringbuffer.h in linuxsampler.tgz or in hdrbench.
I think developers of audio apps should learn how to
solve problems by avoiding mutexes and locks completely.
Using shared memory to exchange data works fine , but sometime
two or more threads have to write the structure or read it atomically
thus causing race conditions.
What I usually do is delegating a task to a certain thread
(eg the audio thread is responsible to write to the audiovoice structure,
other threads can only read it).
If other threads want to write data to this structure, then they send
a command via lock-free fifo to the audio thread which then acts accordingly.
Async message passing is not the nicest thing in the world , but it has the big
advantage that you can avoid locks completely.
I do not know the structure of GDAM, but having played with it, I think that it
fits into the model I described in my other mail.
For example the audio thread would be do nothing more than getting data from
ringbuffers , mix them together and output the result to the audio device.
The disk thread would decode frames of the currently playing mp3s and write
the data to the ringbuffers. At each iteration (every N KB of read data) ,
it would check the command fifo if there were new messages available,
if not simply continue decoding , if yes process the command (add new mp3
stream, remove mp3 stream etc)
regarding the soundserver war I am still standing to my opinion:
general purpose soundserver will not cover the needs of high-end audio
applications, and it doesn't make sense to wait forever until the
"holy grail" soundserver is found , which fits all possible scenarios.
So let KDE use arts and GNOME esound, but
high-end applications eg: a low-latency softsampler/synth which communicates
with (hypothetical) Cubase which runs his own VST synth modules etc etc , will
use the a protocol similar to one I described to get out the maximum out of
the hardware.
SO what if the user wants to run low-latency apps AND regular stuff
(xmms , mpg123 , quake etc) ?
simple make a small client which feed the data from esound to the
realtime soundserver.
With this approach you can hear your soft synth and xmms at the same
time but as soon as the system load will go up,
the softsysth will still play dropout free audio, while the normal apps
will dropout because these do not meet the realtime criteria
(process separation, priorities, no disk IO, mutexes, etc etc).
Oee could argue to add these features to esd or arts (eg the realtime
soundserver features), but I am totally contrary since I want to keep
things simple and will become a maintenance headache.
(we have at least two soundservers GNOME and KDE, thus the code
would need duplication and and and ... no thanks)
Plus with the above hook, users will still be able to run both simultaneously.
Anyone who disagrees here ?
If he disagrees then he has to show me that he has an alternative to
run serveral concurrent apps with 2-3msec latency at the same time and without
ANY dropout during heavy load.
Benno.
This archive was generated by hypermail 2b28 : Fri Jul 14 2000 - 00:04:39 EEST