On Mon, 29 Jun 2020, Giuliano Pochini wrote:
On Fri, 19 Jun 2020 22:21:54 +0100 (BST) Mark Hills mark@xwax.org wrote:
On Fri, 19 Jun 2020, Giuliano Pochini wrote:
On Wed, 17 Jun 2020 12:14:42 +0100 (BST) Mark Hills mark@xwax.org 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 :)
What software are you using on the device, and are you using x86_64 and dmix?
I think some issues might be exaggerated by dmix which has a unique way of opening the device several times. And then chromium exercises dmix a lot with all of its threads/forks. That would I presume be how it exercises races between pcm_pointer and interrupts.