[alsa-devel] [patch] snd-pcsp fixes
tiwai at suse.de
Fri Oct 30 16:18:13 CET 2009
At Fri, 30 Oct 2009 17:23:09 +0300,
Stas Sergeev wrote:
> Takashi Iwai wrote:
> >>> 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.
> What do you mean? As I said above, there
> seems to be no first bitflip on a start trigger,
> neither initially, nor with my current patch.
> There was only the timer _mode_ setup, the
> GATE input of the timer was not supposed to
> be touched. The logic you invented, OTOH,
> does the first bitflip there, and then
> advances the timer, which is also correct,
> but is more complicated. Do you think there
> was a bug that actually did the first
> bitflip anyway?
The problem was that the first call with zero delay didn't happen
and hrtimer stopped totally on my tests. So, it had to be implemented
in my way.
I'm not sure whether this was fixed. Keep testing on your other
machines as I have really no time for checking this at all for the
time being. Still over 8,000 mails left in my inbox.
More information about the Alsa-devel