At Fri, 30 Oct 2009 15:22:39 +0300, Stas Sergeev wrote: > > Hi. > > Takashi Iwai wrote: > > I applied the patch now as is, as I suppose you tested it well :) > Well, no! :) I only tested it on 2 > machines yet. Please give it more > testing if you can. OK, will check later. But I think it should be irrelevant with machine since it's the core part of hrtimer. > > I don't remember exactly the changes for pcsp driver right now, > > but the change of the initial delay was due to the change of start > > logic. At least, at the time HRTIMER_CB_IRQSAFE was removed, starting > > with zero didn't work at all on my machine. Maybe something got fixed > > in the core side. > OK, it would be nice if you can check > whether or not the problem is there on > that particular machine... Maybe I have no more that machine. Anyway, more testing would be needed. > > But, I still don't understand why it has to be zero. The first > > bit-flip is done inside the trigger-start, so the next wakeup should > > be after the calculated ns. Isn't it? > That was the logic you invented, but > initially, and with my patch, there > is no bitflip on start trigger. Or, > at least, not supposed to be - there > was only a timer mode setup, or if not - > that was a bug. :) OK, then we should revert the zero-delay logic again. The zero-delay start means to do the bitflip again immediately. This is wrong, of course. > Also, you added some caching variables: > > + unsigned int fmt_size; > + unsigned int is_signed; > > What was the intention? Is this a speed-up? > If not - reverting that too? It's for speeding up. We should minimize any calculations in the hrtimer callback. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
