In message <[EMAIL PROTECTED]>you write:
>> > The only thing I can think of is that the sound card clock is drifting
>> > too.
>>
>> Do you mean the drift as the difference between the "real" wall-clock
>> time and sequencer ticks? Or between the sequencer time and ticks?
>
>The sequencer clock
At Tue, 18 Sep 2001 10:03:45 -0600,
Jack Moffitt wrote:
>
> > > The only thing I can think of is that the sound card clock is drifting
> > > too.
> >
> > Do you mean the drift as the difference between the "real" wall-clock
> > time and sequencer ticks? Or between the sequencer time and ticks?
> X = real interrupt period, x = truncated in nsecs
>
> X = x + a
>
> Y = real tick duration Y, y = truncated in nsecs
>
> Y = y + b
So X/Y is ticks/period, and x/y is what we are calulating as ticks per
period. That means (X/Y) - (x/y) is the drift in
At Tue, 18 Sep 2001 10:07:37 +0200 (CEST),
Jaroslav wrote:
>
> On Mon, 17 Sep 2001, Takashi Iwai wrote:
>
> > Hi,
> >
> > in this weekend I worked on the ALSA timer stuffs, too.
> > The attached patch includes:
> >
> > - use standard list struct for handling of timers.
>
> It looks good.
>
> >
> > The only thing I can think of is that the sound card clock is drifting
> > too.
>
> Do you mean the drift as the difference between the "real" wall-clock
> time and sequencer ticks? Or between the sequencer time and ticks?
The sequencer clock generates ticks on the pcm clock interrupt. But
Hi Jack,
At Mon, 17 Sep 2001 20:06:48 -0600,
Jack Moffitt wrote:
>
> > Ah, I meant that total .851 msec for 5 minutes.
> > Thus it's still enough small. Sorry, I was too lame.
> >
> > I guess the problem is hidden somewhere in other place..
>
> I noticed that after I posted. Sorry.
>
> If th
Thes is a good summary of problems of precision found is tempo/ticks
conversions
and possible solutions by using integer and keeping fractionnal parts.
http://www.manning.com/Messick/Chapter7.html
Stephane Letz
Grame: Centre National de creation musicale
9, Rue du Garet
69001 Lyon
Tel: 04-72
On Mon, 17 Sep 2001, Takashi Iwai wrote:
> Hi,
>
> in this weekend I worked on the ALSA timer stuffs, too.
> The attached patch includes:
>
> - use standard list struct for handling of timers.
It looks good.
> - removal of resolution in sequencer -- sequencer invokes timer with
> the highest
> Ah, I meant that total .851 msec for 5 minutes.
> Thus it's still enough small. Sorry, I was too lame.
>
> I guess the problem is hidden somewhere in other place..
I noticed that after I posted. Sorry.
If this was the only drift, we'd have 16ms after an hour. Not _great_
but probably accept
At Mon, 17 Sep 2001 19:49:55 -0600,
Jack Moffitt wrote:
>
> > In theorecially maximum case:
> >
> > max D = (freq * t / pepriod) * max(x, y) / x^2
> >
> > max D = .851 msec
> >
> > This looks reasonable?
>
> Yes. That results in 255.3ms of drift over 5 minutes. That sounds
> right.
> In theorecially maximum case:
>
> max D = (freq * t / pepriod) * max(x, y) / x^2
>
> max D = .851 msec
>
> This looks reasonable?
Yes. That results in 255.3ms of drift over 5 minutes. That sounds
right.
jack.
___
Alsa-devel mailing l
At Mon, 17 Sep 2001 18:23:52 -0600,
Jack Moffitt wrote:
>
> > Isn't it in nanoseconds (1e-9)?
> > If so, the following drift will be 1/1000...
>
> Yes. But reading through more code, we're also losing 2/3 of a
> nanosecond in tick resolution:
>
> tick->resolution = (tempo * 1000) / ppq;
>
>
> Isn't it in nanoseconds (1e-9)?
> If so, the following drift will be 1/1000...
Yes. But reading through more code, we're also losing 2/3 of a
nanosecond in tick resolution:
tick->resolution = (tempo * 1000) / ppq;
Which means we're losing about 1.25 nanoseconds every period.
I can definate
> > 10 * period / rate
> >
> > and truncated to an integer. for a period of 32 and a rate of 44100,
> > this means we are throwing away .58276643 microseconds per period.
>
> Isn't it in nanoseconds (1e-9)?
> If so, the following drift will be 1/1000...
That definately looks like the c
At Mon, 17 Sep 2001 17:37:23 -0600,
Jack Moffitt wrote:
>
> > There is still the same amount of drift though.
>
> I have calculated the drift:
>
> the interval in microseconds is calculated by
> snd_pcm_timer_resolution_chage() like so:
>
> 10 * period / rate
>
> and truncated to an
> There is still the same amount of drift though.
I have calculated the drift:
the interval in microseconds is calculated by
snd_pcm_timer_resolution_chage() like so:
10 * period / rate
and truncated to an integer. for a period of 32 and a rate of 44100,
this means we are throwing a
> in this weekend I worked on the ALSA timer stuffs, too.
> The attached patch includes:
This patch against CVS does the same thing as my code (although probably
does it much better!). It fixes the resolution problem and we have
nearly perfect sync.
There is still the same amount of drift thoug
Hi,
in this weekend I worked on the ALSA timer stuffs, too.
The attached patch includes:
- use standard list struct for handling of timers.
- removal of resolution in sequencer -- sequencer invokes timer with
the highest possible interrupts (for the assigned source).
so now it doesn't mat
> The first part looks good (I've put it to CVS), but the second part can
> cause trouble when the PCM is not initialized (resolution is zero). I
> think, if the timer is slave (we can't predict the tick time), then it's
> better to stay with some reasonable defaults.
So have you committed a fixe
On Sun, 16 Sep 2001, Jack Moffitt wrote:
> Of course I forgot the patch.
>
> It's now attached.
The first part looks good (I've put it to CVS), but the second part can
cause trouble when the PCM is not initialized (resolution is zero). I
think, if the timer is slave (we can't predict the tick ti
Of course I forgot the patch.
It's now attached.
jack.
diff -u -r1.53 seq_timer.c
--- seq/seq_timer.c 2001/06/06 17:46:51 1.53
+++ seq/seq_timer.c 2001/09/16 22:52:54
@@ -151,7 +151,7 @@
if (!tmr->running)
return;
- resolution = tmr->period;
+
Once again I'm working on the MIDI timing (when synced with the pcm
device). I've finally been able to trace through much of the code and I
think I found some problems.
THe attached patch does two things:
1) in snd_seq_timer_interrupt() the resolution is passed in from the
pcm timer. This pat
22 matches
Mail list logo
