From alsa-devel-owner@alsa.jcu.cz  Fri Oct  2 17:33:49 1998
Received: from pat.bath.ac.uk (pat.bath.ac.uk [138.38.32.2])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id RAA30499
	for <alsa-devel@alsa.jcu.cz>; Fri, 2 Oct 1998 17:33:14 +0200
Received: (qmail 17922 invoked from network); 2 Oct 1998 15:33:10 -0000
Received: from midge.bath.ac.uk (HELO bath.ac.uk) (138.38.32.34)
  by pat.bath.ac.uk with SMTP; 2 Oct 1998 15:33:10 -0000
Received: from tobi.bath.ac.uk by midge.bath.ac.uk id aa03812;
          2 Oct 98 16:33 BST
Message-ID: <3614F201.59E2@bath.ac.uk>
Date: Fri, 02 Oct 1998 16:32:17 +0100
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
MIME-Version: 1.0
To: kde-multimedia@alpha.tat.physik.uni-tuebingen.de
CC: alsa-devel@alsa.jcu.cz
Subject: Re: Playing and mixing wave files
References: <19980930155236.58475@space.twc.de> <98093017050002.03411@magicon> <19981001182216.23605@space.twc.de> <3614C50B.5DC46588@scram.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Johannes Walch wrote:
> 
> Stefan Westerfeld wrote:
> 
>      1. Client 1 arrives, and wants to play wav-File foo.wav
>      2. Your server does a write to OSS with the first 4096
>      samples of foo.wav
>      3. 1ms later, Client2 arrives, and wants to play wav-File
>      bla.wav
>      4. Now, only the first 44 samples of foo.wav have been
>      really played,
>         while the others are still in some OSS buffers.
> 
>         But IMHO the only chance now is to mix the next 4096
>      samples of foo.wav
>         with the first 4096 samples of bla.wav, and then write
>      them to OSS.
> 
>      Then, the delay you produced is 4096*(1/44100s) = 92ms,
>      instead of the 1ms
>      delay in reality.
> 
>      The only solution I can think of is to use really small
>      buffers, and that's
>      what KSynth is doing. But if you do so, you will need a high
>      priority, to
>      be able to generate continous output, even if other
>      processes need the cpu
>      badly. ;)
> 
> 
> I think of another possibility. It's just not ok that the sound system
> take so much cpu time. All the people who don't need low latency audio
> will turn off the sound system then and that's not the approach.
> I think the audio server should not work with a fix buffer size. In
> normal environment (system sounds) a buffer size of 4096 is ok (or
> even more) and when a "realtime sound" application is started (like
> games or ksynth or something) then the buffer size is decreased. I
> think this would be a simple and effective solution. I don't know if
> this is possible with OSS but we should probably not focus so much on
> OSS anyway. I don't like the commercial aspect of OSS and there's an
> alternative sound driver project going on. It's called  ALSA  and
> allready quite advanced. So maybe we should give this a thought.

 From what I hear on the ALSA list the audio drivers are pretty good
(better than OSS). I used the ALSA driver in the OSS emulation
mode without problem. However ALSA has not yet got the internal synth
support
for all sound cards (e.g. my AWE32). 
Untill this is implemented I would not recommend using the ALSA drivers 
because you would still need OSS and I don't think you can just load up
the synth driver part of OSS (I could be wrong).


 cheers Paul.

