> On 25 Oct 2018, at 08:37, Takashi Iwai <tiwai@xxxxxxx> wrote: > > On Thu, 25 Oct 2018 00:02:34 +0200, > Kirill Marinushkin wrote: >> >>>> When you play sound - the pointer increments. >>> >>> Unfortunately, when you play sound, the pointer does not actually increment, for up to about 10 milliseconds. I know of no way to actually access the true “live” position of the frame that is being played at any instant; hence the desire to estimate it. >>> >> >> Your vision of situation in the opposite from my vision. What you see as a >> symptom - I see as a root cause. As I see, you should fix the >> pointer-not-incrementing. Why do you think that it's okay that the pointer is >> not updating during sound play? Why do you insist that there is a delay? I don't >> understand why we are so stuck here. > > Well, in the API POV, it's nothing wrong to keep hwptr sticking while > updating only delay value. It implies that the hardware chip doesn't > provide the hwptr update. > > Though, usually the delay value is provided also from the hardware, > e.g. reading the link position or such. It's a typical case like > USB-audio, where the hwptr gets updated and the delay indicates the > actual position *behind* hwptr. That works because hwptr shows the > position in the ring buffer at which you can access the data. And it > doesn't mean that hwptr is the actually playing position, but it can > be ahead of the current position, when many samples are queued on > FIFO. The delay is provided to correct the position back to the > actual point. > > But, this also doesn't mean that the delay shouldn't be used for the > purpose like this patchset, either. OTOH, providing a finer hwptr > value would be likely more apps-friendly; there must be many programs > that don't evaluate the delay value properly. > > So, I suppose that hwptr update might be a better option if the code > won't become too complex. Let's see. Indeed. It will take me a few days to look into this… Regards Mike > One another thing I'd like to point out is that the value given in the > patch is nothing but an estimated position, optimistically calculated > via the system timer. Mike and I had already discussion in another > thread, and another possible option would be to provide the proper > timestamp-vs-hwptr pair, instead of updating the timestamp always at > the status read. > > Maybe it's worth to have a module option to suppress this optimistic > hwptr update behavior, in case something went wrong with clocks? > > > thanks, > > Takashi _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
