Re: [linux-audio-dev] Realtime restrictions when running multipleaudio apps .. Was: Re: disksampler ...

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Realtime restrictions when running multipleaudio apps .. Was: Re: disksampler ...
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Tue Jul 18 2000 - 19:03:41 EEST


Stefan Westerfeld wrote:
>
> Hi!
>
> On Fri, Jul 14, 2000 at 10:45:56AM +0200, Benno Senoner wrote:
> > It would be nice to hear comments from other list members
> > (David Olofson , Paul , Stephan etc)
>
> Okay, I'll try to briefly summarize my thoughts about realtime soundserving
> generally, and your proposal and aRts specifically.
>
> Generally, I think if linux is to be accepted as usable platform for audio,
> we should get around the one-app-only restriction. Soundserving in the user
> space is IMHO the way to go. This means, one app, the soundserver, gets
> /dev/dsp, and all other apps do their sound output with the soundserver.
>
> The soundserver should be "lossless" in a way for every app you could write
> without the soundserver, there is also an equivalent implementation using
> the soundserver. This rules out proposals like "we do a soundserver that
> supports only IPC streaming", as this approach effectively kills all low-
> latency apps.
>
> Thus, a realtime soundserver must somehow allow in-process execution, so
> that the realtime parts of apps can be gathered inside the soundserver.

  crash of an application that runs inside of soundserver would crash
soundserver, which in turn causes the crashes of all sound applications.
how do you get around that?

  you could prevent the application crash (but every application would
have to be aware of crashing sound server) but I don't see any workable
way to prevent the audio server to crash.

  isn't shared memory for data communication fast enough?

        erik


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Jul 19 2000 - 08:19:03 EEST