Re: [Alsa-devel] Re: [linux-audio-dev] midi events in jack callback / ALSA Sequencer

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [Alsa-devel] Re: [linux-audio-dev] midi events in jack callback / ALSA Sequencer
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Thu Aug 22 2002 - 16:21:17 EEST


> Why is it important to keep the API simple, shouldn't it be functional in
first place and make the API usage simply?

Who says a simple API can't be functional?

> Anyway (IMHO), there should really be an API which combines audio and MIDI
playback, recording and timing of events and makes it possible to keep MIDI
in sync with audio (ALSA sequencer API seems to support only tick and time
synchronization modes, no audio clock sync mode). Professional API's like
ASIO and VST (and DirectMusic) synchronizes everything to audio clock
(sample position). Even when MTC is used the audio clock is the main clock
source, digital I/O or world clock is used to sync the audio clock to the
audio clock of the external device. There is no need for other sync modes
than audio (_maybe the tick mode could be useful if ALSA takes care of
sending MIDI clock, SPP, MTC etc. data to external devices). Sequencer
application can easily convert sample position from the beginning of the
song to measures / beats, time etc. whatever is needed when the time
signature, tempo and sample rate is known - reading the sample position from
the sound card is no problem at all!

Well, I disagree. I think using UST is better. You might want to use MIDI
without audio. Also
MIDI hardware that supports scheduling will not support scheduling to the
audio position. Using
UST just means mapping different clocks to one common clock.

> , PCI chipset's DMA registers have usually such current play position
register, or if not, the sample position can be calculated by measuring the
time between IRQ's and calculating the time between current time and the
time when last interrupt was received.

The current sample position does not tell me anything about when some
earlier sample occured or
a later sample will occur. In your example you already use two UST/MSC
values to estimate
the current MSC. Allthough it is possible on some hardware to read the
current sample position
(MSC) it is not possible to the OS (or other hardware) to schedule on it and
so you'll have to
convert to another clock at some point.

--martijn


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Aug 22 2002 - 15:24:13 EEST