[alsa-devel] [PATCH - JACK PCM plugin] jack: Use boundary as hw_ptr wrap around
Takashi Iwai
tiwai at suse.de
Thu Feb 15 12:32:04 CET 2018
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
More information about the Alsa-devel
mailing list