Subject: [linux-audio-dev] Re: timing issues in a client/server enviroment
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: la loka 09 1999 - 12:44:23 EDT
>Are there any valid reasons to NOT adopt my proposed audio
>client/server model ? By using sharedmen / efficient IPC, we could
>even run many low-latency apps simultaneously with only little
>overhead.
As long as its clearly understood that this is not going to work like
Windoze, where the engine is part of the OS, then I think this is
fine. What I mean by this is that I don't want to see a system like
esd created, where its author(s) believe that its going to run all the
time and that all applications should use it. Instead, I want a system
set up in which *any* application might potentially be the "engine"
addressed by the API. That means some kind of registration system, but
if we use shmem, then using a well-known key for the shmem segment
will take care of that.
Specifically, I want people to be able to use a variety of different
applications that might provide the services advertised by the API;
the situation with GNOME and KDE where there is "standard" not just in
terms of an API (and runtime library) but also the actual applications
that must be running is something I don't wish to support. It might be
useful for people who need handholding with their desktop, and want
their "you have mail" messages playing back while they listen to a
real audio clip. But its not OK for those of us who want to do more
dedicated and serious audio work.
So yes, I think the development of a standard API, a library, and one
or more sample implementations is a great idea, but please don't
anyone go off and think they are writing "the Linux Sound System".
>I think kernel space belongs mainly to PCM/Midi driver, and maybe
>some eventrouter which has to be well tested and crashproof.
Agreed.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST