From alsa-devel-owner@alsa.jcu.cz  Mon Jan  4 19:49:57 1999
Received: from pat.bath.ac.uk (qmailr@pat.bath.ac.uk [138.38.32.2])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id TAA12188
	for <alsa-devel@alsa.jcu.cz>; Mon, 4 Jan 1999 19:49:25 +0100
Received: (qmail 20200 invoked from network); 4 Jan 1999 18:49:22 -0000
Received: from mary.bath.ac.uk (HELO bath.ac.uk) (mmdf@138.38.32.14)
  by pat.bath.ac.uk with SMTP; 4 Jan 1999 18:49:22 -0000
Received: from tobi.bath.ac.uk by mary.bath.ac.uk id aa22910; 4 Jan 99 18:49 GMT
Message-ID: <36910D64.3F54@bath.ac.uk>
Date: Mon, 04 Jan 1999 18:50:12 +0000
From: "P.J.Leonard" <P.J.Leonard@bath.ac.uk>
MIME-Version: 1.0
To: Jaroslav Kysela <perex@jcu.cz>
CC: alsa-devel@alsa.jcu.cz
Subject: Re: ALSA Sequencer API
References: <Pine.LNX.3.96.990104183837.29500A-100000@entry.jcu.cz>
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

Jaroslav Kysela wrote:
> 
> On Mon, 4 Jan 1999, P.J.Leonard wrote:
>>  Is the ../test/seq/  code meant to compile ?

> No.. This is old code for sequencer prototype (I need remove it). Latest
> test code (mostly new and some moved from driver test code) is in alsa-lib
> package in alsa-lib/test/seq*..
 
Hmmmm . . . .

eepc-elf:~/asla/alsa-lib-0.3.0pre2/test $ make seq.o
gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include  -static -Wall
-pipe -g -c
 seq.c
seq.c:9: seq-decoder.c: No such file or directory
seq.c:10: seq-sender.c: No such file or directory



> >  Also I see that user land clients sit on a file waiting for a message.
> > Has anyone
> > done any tests on the latency involved here ? This is important if I am
> 
> Note that latency depends on system scheduler, task priority and system
> load. With PCM we have latency about 1.5ms - I think that we can reach
> latency under 1ms with round-robin and maximum priority.

 That sounds cool.


> > going to
> > support alsa from cantor (my sequencer). As Frank mentioned user land
> > clients need
> > tight timing. I see that the examples run the user code as a real-time
> 
> User land DRIVERS needs tight timing, not usual sequencer applications -
> they use precise kernel-side timing and kernel side buffers...

 My application does processing of midi input events in real time 
e.g. look at the velocity information and do some modulation of effects
before routing it to the midi out. This involves very little processing
but does require the kernel/user loop to be tight.

> > task.
> > What if the user client hangs (CTRL-ALT-DELETE ?)
> 
> Why? If driver hangs - all incoming events are lost (queue overrun) and if
> user kill this client (Ctrl-C or kill -SIGTERM) then sequencer deallocate
> all events for/from this client. Note that failure of one client doesn't
> have any effect for other clients.

 My understanding was that if a program running in real time mode gets
stuck in a processing
loop then it hogs all the CPU. THis is also my experience using ksynth
(the KDE software synthesiser server) which uses the same sceduling as
the midi file player
example code in the (old) test directory. In the case of ksynth the
server
running in real time mode got overloaded with wave processing 
and did not return control to any other process.


> Note that first version of sequencer may contains fatal bugs which should
> break this model, of course..

 No problem.

> We can also make some discussion about queues.. Mainly about watermarks,
> event memory pools etc..

 Sorry ? do I need to know about these to interface my music program to
alsa ?
I implement my own queuing and sceduling that only requires alsa to
provide
real time call backs and play midi events.

 Is it wrong to believe it should be possible to do things in real time
in user land ? 

 BTW I am correct in thinking it is possible for ALSA and the OSS stuff
to co-exist ?
If this is the case it should be possible to wrap the OSS driver up in a
userland
server (until a alsa AWE32 driver appears) ?
Should I remove all reference to DSP and  FM/OPL3 from the OSS kernel
setup ?

-- 
 Cheers Paul.                                        
               __         __                  
              (  ) _ - _ (  )                 
               ~~         ~~                  
                (  0   0  )                   
----------ooO----(       )----Ooo------------ 
          '''     (     )     '''             
                   (   )                      
                    \ /                       
                   ~~O~~                      

  Tel: +44 1225 826108
  Fax: +44 1225 826305
snail: P.J.Leonard
       Applied Electromagnetic Research Centre
       Bath University,
       BATH, UK   BA2 7AY

