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.
>
> > - removal of resolution in sequencer -- sequencer invokes timer with
> > the highest possible interrupts (for the assigned source).
> > so now it doesn't matter which timer source is.
>
> I don't agree so much with it. For example: The GUS cards have one 80000us
> and second 320000us timers with maximum up to 256 ticks. I think that it
> would be better to use the user specified tick rate using the parameter
> snd_seq_default_timer_resolution. I also don't see how your code affects
> the slave timer. It must work as now, because period or base_period
> members are not used in any time counting expression.
Ok, I'll put it back.
The sequencer itself isn't related whether the timer is slave or
master. It receives interrupts, updates the time stamp, and process
the queues. So when the timer is stopped, the queue stopps too.
That's all.
> > Please give a try!
> >
> > BTW, I removed slave timer instance (not HW_SLAVE) from timer.c,
> > because it was buggy. I'll try to put back if it's inevitablly
> > necessary.. What do you think, Jaroslav?
>
> I can easily imagine an application using same slave timer for
> a sequencer queue and an user space task to run in sync.
The problem was that snd_timer_add_slaves() was not correctly
implemented. When a slave instace starts, it brokes the master-slave
list. I'll work on it later.
Takashi
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
