From alsa-devel-owner@alsa.jcu.cz  Mon May 11 23:32:08 1998
Received: from altrade.nijmegen.inter.nl.net (altrade.nijmegen.inter.nl.net [193.67.237.6])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id XAA06525
	for <alsa-devel@jcu.cz>; Mon, 11 May 1998 23:32:04 +0200
Received: from obelix.fvdpol.inter.nl.net by altrade.nijmegen.inter.nl.net
	via bd99-17.Breda.NL.net [193.79.246.242] with ESMTP for <alsa-devel@jcu.cz>
	id XAA05298 (8.8.8/3.27); Mon, 11 May 1998 23:32:01 +0200 (MET DST)
Received: (from frank@localhost) by obelix.fvdpol.inter.nl.net (8.8.7/8.7.3) id VAA23981 for alsa-devel@jcu.cz; Mon, 11 May 1998 21:38:21 +0200
From: Frank van de Pol <F.K.W.van.de.Pol@inter.nl.net>
Message-Id: <199805111938.VAA23981@obelix.fvdpol.inter.nl.net>
Subject: Re: New Sequencer core
To: alsa-devel@jcu.cz
Date: Mon, 11 May 1998 21:38:21 +0200 (MET DST)
In-Reply-To: <Pine.LNX.3.96.980510232232.31248A-100000@entry.jcu.cz> from "Jaroslav Kysela" at May 10, 98 11:53:05 pm
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

Jaroslav Kysela wrote:
> 
[snip]

> Ticks shouldn't be used in all situations. Example application:
> 
> 1. song is in event queue with tick timestamps
> 2. sound effect is posted to queue at some tick

Fully agreed.

> 
> Problem occurs if application want for some reason change tempo of song,
> but it doesn't want change sound effect position.
> 
> Possible problem solving:
> 
> 1. application should create two independed event queues
>    - driver should contains some time synchronization feature for
>      sequencer queues
> 2. implement two queues to sequencer
>    - song queue - tick timestamps
>    - realtime queue - us timestamps

I think the 2nd option you mention is basicly the same idea I posted (not in
my first version, but in some later posting)

A client (whatever, say a MIDI player) writes a event to the sequencer core.
That event has a timestamp. Timestamp can either be in ticks or in us. The
sequencer puts the event in the right queue. (say song queue or realtime
queue).

The event with the earliest timestamp (from either queues), depending on the
tempo in case of song queue, will be dequeued and dispatched to the
destination clients the event has to go to. 


> 
> Next idea: Note effect
> 
> Application want play notes with pretty echo effect. This effect should do
> this: Start note + delay + start same note again with different volume...
> 
> Delay should be:
> 
> 1. in ticks
> 2. in us
> 
> Above mechanism should be used in driver for internal effect timing, too.
> Note: Effects for InterWave chips uses us timings...

Hmmmm, what _could_ be done is something in the lines of this:

Player enqueues an event with tick timestamp. Sequencer puts it in the song
queue, and at the right time (tick) the event is dispatched to the interwave
driver. This interwave driver simply resubmits the event with a timestamp of
NOW + 6ms to get the reverb, and starts playing the original event.

The newly submitted event (which goes through the realtime queue) will be
played after 6 ms.

"....InterWave chips use us timing...."

Does that mean we have to feed it a us resolution????? I don't hope so!
 

> 
> ======
> 
> What about to create this sequencer:
> 
> 1. one event queue
> 2. timestamp should be in us or tick
>    - selectable, but can't be used simultaneously
> 3. timer should be shared with many queues (master/slave)
> 
> Possible problems:
> 
> 1. security - how identify applications which want share same timer?
>    - maybe only within one application can be timer shared

Let's combine 1 & 2, and have (from applications (=client) 's point of view)
one queue that allows both us and tick timestamps. Internally this can (and
probably will) be implemented as 2 separate queues: the song queue and the
realtime queue. But this is internal, not visibible from outside.

I don't understand what you mean with the '...shared with many queues..'. I
guess that you mean multiple independent sequencers (for the multi-user
sequencing). In that case, where each sequencing systems has it's own timing
module, all these 'timers' are driven from one master 'clock'. 

> 
> ======
> 
> Other synchro issues:
> 
> All things in ALSA driver should be synchronized with master (system)
> clock - gettimeofday.

Of course

> 
> - native digital audio code already contains this synchronization

???? not from the number samples played???  There could (is a) drift in the
crystal oscillation when compared to the master clock. That could be a real
time source if one wants to sync to an audio track.


> - synchronization for sequencer should be done with:
>   - shared timer

- so you mean just a (any) clock source

>   - echo event which should return current gettimeofday time to application

no problem.

And of course

- adjust time according to SMPTE, FSK, MTC

- adjust tempo/position according to MIDI Clock/Songposition

Frank.


========================---------------->
#define NAME    "Frank van de Pol"     
#define ADDRESS "mgr. Nelislaan 10"  
#define CITY    "4741 AB Hoeven"    
#define COUNTRY "The Netherlands"  
#define EMAIL   "F.K.W.van.de.Pol@inter.NL.net     -o)
                                                   /\\
Linux - Why use Windows, since there is a door?   _\_v

