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?
It's for speeding up. We should minimize any calculations in the hrtimer callback.
Ok but snd_pcm_format_signed() and snd_pcm_format_width() are really trivial functions, so I just thought this is not worth an efforts. But if you think this have to be optimized, then fine.