On Thu, 15 Feb 2018 11:36:21 +0100, Wischer, Timo (ADITG/ESB) wrote: > > Hello Takashi, > > > This happens only when the application uses periods=1, > > It can also happen with 2 periods per buffer e.g. when the user application is too late. > I will try to illustrate the use case with the following time line: > > Time line: 0--R1-W1-R2--R3-W2-W3-... > > 0 buffer is full (2 periods) > R1 JACK daemon reads 1 period (1 period left in the buffer) > W1 User application writes 1 period (2 periods in the buffer) > R2 JACK daemon reads 1 period (1 period left in the buffer) > R3 JACK daemon reads 1 period (buffer empty) > But it is not yet an under run because JACK has not yet read invalid data. > Due to the blocked user application (e.g low scheduling priority) the pointer() callback was not called before the second read. > In this case the next pointer() call has to result in a delta of 2 periods. > But this is not possible if pointer() is not allowed to return >=buffer_size. > > W2 User application writes 1 period (1 periods in the buffer) > W3 User application writes 1 period (2 periods in the buffer) > Continue with 0 > > > It notifies the period elapse via file-descriptor > But this notification will be processed later if the user application is blocked at the moment (e.g. by higher priority tasks). > > Do you also see my problem, now? I know that's the problem, but you're scratching in the wrong surface. This isn't the issue to be fixed in the backend side. The fact that the pointer callback returns 0 to buffer_size-1 is *the* design. You can't ignore that. If you need to improve such a situation, you'd have to fix in the ioplug implementation itself, not the jack plugin. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
