Re: [linux-audio-dev] Realtime restrictions when runningmultipleaudioapps .. 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 runningmultipleaudioapps .. Was: Re: disksampler ...
From: Erik Steffl (esteffl_AT_pbi.net)
Date: Wed Jul 19 2000 - 21:05:55 EEST


  it looks like the overall idea would be to have sort of two-level
user-space sound server - low latency part would trade some stability
for performance (the applications would be loaded into one process
space), the 'general' part would offer better stability (masking the
crashes of low latency part).

  most of the programs would use the general slower and safer level,
while the programs that really require real time response would use the
low latency level (these would have to be able to deal with crashes).

  there can be only one low latency part (it has exlusive access to
audio HW) but there can be more than one general server (something along
the lines arts or esd etc.).

  seems to make some sense. does it?

  what latencies do we hope to get for both levels? <5ms (almost
guaranteed) for low latency level, <15ms (with slightly weaker
guarantee) for general level?

        erik

David Olofson wrote:
>
> On Tue, 18 Jul 2000, Erik Steffl wrote:
> > > For realtime we simply have to live with this crash-problem.
> > > At least we do not get a complete system lockup but only a simple
> > > segfault.
> >
> > I don't think it's as simple as that. most of the programs today have
> > some sound support, for example all gnome programs (as far as I can
> > tell, I checked the games, pan (news reader) and other gnome programs)
> > have sound support. so if the sound server crashes, all of these
> > programs crash. for a desktop system (including music studio system)
> > it's almost the same as system crash.
>
> No, they will just have to deal with the audio I/O being dead until
> the RT daemon is up running again. The API emulation could deal with
> this so that applications will never see any weird error codes or
> anything; just a drop-out, or some zero input or dropped output data.
...


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 - 21:43:01 EEST