On Fri, 19 Jun 2020 22:21:54 +0100 (BST) Mark Hills <mark@xxxxxxxx> wrote: > On Fri, 19 Jun 2020, Giuliano Pochini wrote: > > > On Wed, 17 Jun 2020 12:14:42 +0100 (BST) > > Mark Hills <mark@xxxxxxxx> wrote: > > > [...] > > > You might be able to do the comparison before wrapping pipe_position, > > > but hopefully you'll consider my patch in reply to Takashi has more > > > clarity. > > > > Your patch is very interesting. I didn't take into account the idea of > > advancing the position by full periods only. If the PCM subsystem > > hasn't changed much since I last checked (I wrote the driver many years > > ago), it should work fine (and I'm sure you tested it). But I don't > > know if something else requires better resolution. > > It's funny, but I didn't take account of the opposite; that there was any > merits to polling inbetween the interrupts for better resolution. > > Takashi pointed out the need for this and we had some discussion. Check > the other thread, where I provided a newer revision of the code. > > The good thing is I think we can have all the things we want and be bug > free, just I have to understand the specification. > > It would be great if you would like to take a look at the newer code for > any problems you can see. I was going to run it for a few days then turn > it into some patches. I looked at your code and I think it's OK. I'm using it for some days without any problem. I also stressed it with pretty tight timings and it worked fine all the time. Since I could not reproduce that problem before, except in some rare random circumstances, I'm not a good tester at all. At most I can say that your patch does not make things worse :) -- Giuliano.
