From alsa-devel-owner@alsa.jcu.cz  Sat Feb 20 21:24:22 1999
Received: from cyphyn.219.org (nwhn-sh12-port178.snet.net [204.60.201.178])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id VAA08819
	for <alsa-devel@alsa.jcu.cz>; Sat, 20 Feb 1999 21:24:02 +0100
Received: from localhost (ffloberg@localhost)
          by cyphyn.219.org (8.8.4/8.8.4) with ESMTP
	  id PAA07984 for <alsa-devel@alsa.jcu.cz>; Sat, 20 Feb 1999 15:31:52 -0500
Date: Sat, 20 Feb 1999 15:31:52 -0500 (EST)
From: Fred Floberg <ffloberg@snet.net>
To: alsa-devel@alsa.jcu.cz
Subject: Re: More PCM/RT stuff (replies mostly)
In-Reply-To: <199902192113.QAA19644@smtp2.mindspring.com>
Message-ID: <Pine.LNX.4.05.9902201403340.7234-100000@cyphyn.219.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list




On Fri, 19 Feb 1999, Data wrote:

Frank wrote:
> >If the sequencer is clocked from PCM timer these two audio sources are
> >always in sync, as the only master clock is the crystal clock of the codec:
> >audio and MIDI in sync for free.
> 
> Right-O.

Just to complicate matters [:-)], what happens in the case of a system
with multiple cards with midi ports? If you're going to sync a given
midi port with its associated crystal oscilator and you have an app
that wants to use several cards/hardware midi ports (such as the one
I'm writing right now) the two midi streams will be out of sync with
each other (won't they?), just as is the case with trying to use two
separate cards for multi-channel audio input/output -- the crystal oscilators on
each card are not necessarily in sync with each other.

Has any thought been given to deciding which card in a multi-card set up
will be used to provide timing interrupts?

[major snippage]
> >Perhaps an other timing clock can be considered: the RTC (real-time clock)
> >which is standard available on Intel systems and is capable of (but almost
> >never used for) generating interrupts. Frequencies up to 8192 kHz should be
> >possible, with 1024Hz being default. See Documentation/rtc.txt in the Linux
> >sources for more information. This would also be a great candidate for the
> >sequencer timer.
> 
> Hmm .. I will look in to that.  Seems that this could be implemented as a 
> time source throughout ALSA, if it's standard on Intel hardware.

According to rtc.txt:

"All PCs (even Alpha machines) have a Real Time Clock built into them."

> Of course we would have to consider other platforms as well.  I suppose
> timer.c could  be made to use this RTC instead of the kernel interrupt if it found 
> itself running on an IBM-compatible.

This sounds like a _really_ excellent source of interrupts.
There do seem to be a few minor "gotchas" -- for example, every 11 minutes the
kernel needs to update the RTC and so it shuts off the interrupts during the
write. That might cause a glitch that would need to be accounted for. But these
issues don't seem, at first glance [:-)], to be insurmountable.

> >If this cycle counter can't generate interrupts and thus be used as a clock
> >it won't do any good for synchronisation or sequencer purposes. It can only
> >be used to get an (super) accurate timeofday, which is not relevant if we
> >are syncing to an external source (eg. audio playback)
> 
> Well, at least for things like MIDI note sequencing it could be used to 
> generate highly accurate clocktimes by oversampling it.  I know I've 
> denigrated this method regarding audio, but here the data rate is much lower, low 
> enough that polling is quite practical.  (I still don't like polling though :) )
>   You're right though .. as a primary sync source it's useless if it doesn't 
> generate interrupts.

rdtsc is an assembler instruction (for Pentium class CPU's) which simply loads
the contents of the 64 bit cycle counter register into edx and eax. It doesn't
generate interrupts.

rdtsc might find a use in handling the "11 Minute Glitch" mentioned above, but
its use would be Pentium class (including the K6-2) CPU specific. I don't know
if Alphas have this instruction, but 486's do not (this is an oversimplification
actually, as I understand that _some_ 486's may have an equivalent instruction,
but I haven't researched this myself).

For more info on rdtsc, see:

	http://www.intel.com/drg/pentiumII/appnotes/RDTSCPM1.HTM



As I say, I'm in the process of writing a midi music sequencer (called
HyperSeq) which is inspired by Paul Barton-Davis's excellent SoftWerk "analogue"
midi sequencer emulator package http://www.op.net/~pbd/softwerk/softwerk.html

It'll use a spread sheet paradigm, allowing the user to use formulas in each
"step" or "cell" of a sequenced row. These formulas can include, as variables,
the values of other steps in other rows, which can of course be formulas
themselves, just like in a spread sheet program.

I'm writing it in C, as I just don't have a C++ type of mind :-), and it's
going to use ALSA's sequencer core, rather than using Paul's more generic
(and flexible) solution of reading/writing a device file.

I'm still just trying to define the GUI using GTK, but as you can imagine, I'm
keenly interested in the issues being discussed in this thread, and I'm very
happy to see people hashing all of this out.

Thanks everyone,

Fred "Frightened by his _own_ code" Floberg




