Re: Forcing an absolute timestamp for every midi event.

[Takashi Iwai <tiwai@suse.de>]

At Sun, 18 Aug 2002 19:17:01 -0300,
Juan Linietsky wrote:
> 
> On Sun, 18 Aug 2002 14:48:49 +0200
> Frank van de Pol <fvdpol@home.nl> wrote:
> 
> > 
> > 
> > 
> > On Sun, Aug 18, 2002 at 05:57:40AM -0300, Juan Linietsky wrote:
> > > Hi! I wanted to ask, how about forcing
> > > an absolute timestamp for _every_ midi event?
> > 
> > It's not 100% clear to me wat you mean. When using the sequencer api
> > you already have a timestamp (either tick/clock) for every event
> > scheduled. Midi data captured from eg. the midi input port is
> > timestamped upon receive IRQ.
> 
> Well, thats what i thought too by watching the code, but I check any
> received
> event, from any source and all variables are all zero. Instead, alsa
> promises to deliver events at the right time, which is fine.. but not
> enough!
> 
> include/alsa/seq_event.h:row 421
> This is the struct of any event I receive when polling the device,
> on my sequencer client:
> 
> typedef struct snd_seq_event {
> [..] which includes...
>         snd_seq_timestamp_t time;
> [..]
> } snd_seq_event_t;
> 
> this struct has...
> 
> typedef union snd_seq_timestamp {
>         snd_seq_tick_time_t tick;       /**< tick-time */
>         struct snd_seq_real_time time;  /**< real-time */
> } snd_seq_timestamp_t;
> 
> To which i wonder.. first, why is this an union? why cant both be
> there?
 
because a tick time cannot be always mapped to the wallclock time.
the tempo can be changed at any time.

for incoming events, yes, both of them can be, though.
in such a case, you can connect twice the same route with different
flags (see below).


> well, anyway.. snd_seq_tick_time_t is an int,
> and snd_seq_real_time is:
> 
> typedef struct snd_seq_real_time {
>         unsigned int tv_sec;            /**< seconds */
>         unsigned int tv_nsec;           /**< nanoseconds */
> } snd_seq_real_time_t;
> 
> This should technically give me info about the absolute time in which
> the event has to be played,

yes.
but please note that the time is not system time but is a time of the
specified queue.

> basically what i need in order to do a certain amount of offline
> processing.
> This way, my softsynth wont need extremely low audio latency to play
> accurate timing.
> 
> But! All this struct is zeroed, _allways_ zeroed, no info is ever
> proovided to my sequencer client.
> I think this is either a design problem, or a serious bug in the api. 

the time-stamping on incoming events is enabled only "update_time"
flag is set at the subscription (connection), corresponding

void snd_seq_port_subscribe_set_time_update(snd_seq_port_subscribe_t *info, int val);
void snd_seq_port_subscribe_set_time_real(snd_seq_port_subscribe_t *info, int val);
void snd_seq_port_subscribe_set_queue(snd_seq_port_subscribe_t *info, int q);

the first two set "yes i'll update the timestamps of incoming events"
and "yes, i'll use the real (wallclock) time as timestamp values".
and the last one specifies the queue to be referred to.
if the queue is not running, the time is always same (if not started
at all, then is zero).


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390