[alsa-devel] [patch] snd-pcsp fixes
tiwai at suse.de
Fri Oct 30 13:27:38 CET 2009
At Fri, 30 Oct 2009 15:22:39 +0300,
Stas Sergeev wrote:
> 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
> > 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
More information about the Alsa-devel