[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