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
hello,
is anyone out there working on the seasound solo driver? if not, what
can i do to start work on it myself? i haven't written a driver before,
but have some experience with programming languages and would like to
learn.
(i would have searched the list archives for this issue, but the onlin
> 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
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
>is anyone out there working on the seasound solo driver? if not, what
>can i do to start work on it myself? i haven't written a driver before,
>but have some experience with programming languages and would like to
>learn.
i'm pretty sure its just built on the ice1712 chipset. you'd have to
get i
> 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
> 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
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
> > 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
> 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
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;
>
>
> 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 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.
> 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
About a week ago I recompiled my kernel (2.4.7) to include rtc rather
than rtc module. At this time I compiled it optimised for my processor,
also(k6-2 475mHz). At this time, I started having problems in kde with
thrashing that would slow down my system to a dead crawl. I started
looking t
Hi all,
Attached is a patch I had to use to get the 0.9.x trident drivers to
load on my Jaton Sonicwave. I'm not an AC'97 expert, but the 0.5.x
drivers didn't used to check for this reset condition.
The soundcard itself appears to work perfectly happily with this mod
to carry on regardless if t
16 matches
Mail list logo
