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