From alsa-devel-owner@alsa.jcu.cz  Wed Jun 24 21:52:08 1998
Received: from obelix.fvdpol.inter.nl.net (root@bd99-16.Breda.NL.net [193.79.246.241])
	by marvin.jcu.cz (8.8.8/8.8.8) with ESMTP id VAA32040
	for <alsa-devel@jcu.cz>; Wed, 24 Jun 1998 21:50:56 +0200
Received: (from frank@localhost) by obelix.fvdpol.inter.nl.net (8.8.7/8.7.3) id VAA25193 for alsa-devel@jcu.cz; Wed, 24 Jun 1998 21:44:47 +0200
From: Frank van de Pol <F.K.W.van.de.Pol@Inter.NL.net>
Message-Id: <199806241944.VAA25193@obelix.fvdpol.inter.nl.net>
Subject: Time resolution needed for sequencer
To: alsa-devel@jcu.cz (alsa)
Date: Wed, 24 Jun 1998 21:44:47 +0200 (MET DST)
Content-Type: text
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list



Hi,

I'm working on a prototype for the ALSA sequencer and would like to know
what timing resolution / what unit for timestamps is needed. Please give
some input on this subject.

- Actual scheduling resolution is dependend on the (hardware) timer source
  that is used (100 Hz system clock or better is other timer is used).

- Timestamps that specify at what time an event is to be executed/fired can
  be specified in 
        a) song position (ticks)
        b) real-time: us/ms or other unit   <<=== This is what I need to
                                                  know the units for.

Some people on the list told that this real-time timestamps should be
microseconds or even higher resolution (Jaroslav mentioned 1e-7s). Drawback
of these fine-grained timestamps is that it requires more than 32 bits to
give a reasonable range, and looks like a problem to me with the 32 bit
machines most of us have today.

Having musical applications in mind where these events are used for changing
parameters, triggering notes/samples etc. I don't think a super high
resolution is needed. For most applications centi-second (10ms) time stamps
are accurate enough (about the resolution of the human ear regarding
distinct sounds), and 1 milli-second should cover everything. When compared
to the actual samples used in cd-quality sound this might seem coarse, but
remember that only 44.1 samples fit into 1 ms.

Specifying event timestamps with a finer resolution that the hardware timer
will deliver is of very little use.

Here is an overview to see what ranges are yielded for the various units and
data types:

+-----------------+------+-------------------------+
| Data type       | Unit | Range                   |
+=================+======+=========================+
| 32 bit unsigned | ms   | 49.7 days               | <== My Favorite [tm]
|                 | us   | 1.2 hours   (too short) | 
|                 | ns   | 4.2 seconds (too short) |
+-----------------+------+-------------------------+
| 48 bit unsigned | ms   | 8925 years              |
|                 | us   | 8.9 years               |
|                 | ns   | 3.2 days    (short?)    |
+-----------------+------+-------------------------+
| 64 bit unsigned | ms   | 584E6 years             |
|                 | us   | 584E3 years             |
|                 | ns   | 584 years               |
+-----------------+------+-------------------------+


Questions:

1) What unit for specifying a real-time timestamp is needed? And why?

2) What data types are practical? Remember that choosing for 'difficult'
   datatype very much affect application code because the application has
   most to to with these timestamps.


Thanks for your time,

Frank.


+---- --- -- -  -   -    - 
|Frank van de Pol                  -o)
|F.K.W.van.de.Pol@inter.NL.net     /\\
|                                 _\_v
|Linux - Why use Windows, since there is a door?

