alsa-jack issues

[Radoslaw Szkodzinski]

Hello,

A recent change in alsa-plugins 1.0.28 alsa-jack has changed the poll semantics.
This breaks audacious and mpv, perhaps more applications.

The regression is caused by:
Commit: 9217377337cdceb62abeb5969112b738bb5cd551
jack: fix polling and recovering


This might or might not be related to lack of
snd_pcm_poll_descriptor_revents call or the use of a timer instead of
repolling.

Another major problem is the lack of handling of DRAINING state. This
breaks short sample playback with aplay and possibly other
applications. That also was present in older alsa-jack and is not a
regression.

[Takashi Iwai]

At Sat, 6 Sep 2014 07:09:17 +0200,

Post by Radoslaw Szkodzinski
Hello,
A recent change in alsa-plugins 1.0.28 alsa-jack has changed the poll semantics.
This breaks audacious and mpv, perhaps more applications.

Could you elaborate more? What's broken and how?

Post by Radoslaw Szkodzinski
Commit: 9217377337cdceb62abeb5969112b738bb5cd551
jack: fix polling and recovering

Let's add the patch author to Cc.

Post by Radoslaw Szkodzinski
This might or might not be related to lack of
snd_pcm_poll_descriptor_revents call or the use of a timer instead of
repolling.
Another major problem is the lack of handling of DRAINING state. This
breaks short sample playback with aplay and possibly other
applications. That also was present in older alsa-jack and is not a
regression.

A fix patch is welcome :) I guess this won't be too difficult to
implement.


Takashi

[Radoslaw Szkodzinski]

Post by Radoslaw Szkodzinski
A recent change in alsa-plugins 1.0.28 alsa-jack has changed the poll semantics.
This breaks audacious and mpv, perhaps more applications.
Commit: 9217377337cdceb62abeb5969112b738bb5cd551
jack: fix polling and recovering

I'm initial author of this commit and I'd love to fix the issue,
but it never happens to me. I need your help to fix it.
Can you provide some steps to reproduce this bug? How much time it
takes to reproduce it? Can you reproduce it with alsa 1.0.27 and

I'll test this during the weekend. 1.0.27.x was fine with alsa 1.0.27.

By the way, what distribution are you using?
Is there a livecd that I can download to reproduce this problem?

This is actually Gentoo, so not really. However, I think it should be
reproducible anywhere.

Post by Radoslaw Szkodzinski
This might or might not be related to lack of
snd_pcm_poll_descriptor_revents call or the use of a timer instead of
repolling.

It should not. But we can't be sure until we find what causes it.

I'm not entirely sure myself. The above mentioned applications cause
the problem.
The whole setup consists of:

Highly patched 3.12.x kernel, no RT patches but in full preempt mode.
Jack2 in DBus mode, realtime and mlock enabled. ALSA output to ICE1724
soundcard, sample rate matched everywhere to 44.1kHz.
ALSA set to use speexrate_best and 44.1kHz by default if this is important.

Applications:
Ladish
Carla with Caps equalizers and one other personal LADSPA plugin (RT safe).
Directly connecting to playback also reproduces the issue.

Any period size and nframes, though very long period sizes vastly
reduce the likelihood this is reproducible.
It is not related to xruns directly, but an xrun can precipitate the issue too.

Reproducible in audacious 3.4.1 or older and mpv (git revision, from
this month or older), but not with sox or aplay.
No problems with direct Jack outputs of the above applications whatsoever.

Both of the problematic applications use a sleep timer in addition or
instead of polling. (audacious due to a bug, mpv by design I think)

I'm sorry for bothering you.

Not a bother at all, I'd like to see this fixed.

R.

[Radoslaw Szkodzinski]

On Thu, Sep 11, 2014 at 11:02 AM, Radoslaw Szkodzinski

Post by Radoslaw Szkodzinski

Post by Radoslaw Szkodzinski
A recent change in alsa-plugins 1.0.28 alsa-jack has changed the poll semantics.
This breaks audacious and mpv, perhaps more applications.
Commit: 9217377337cdceb62abeb5969112b738bb5cd551
jack: fix polling and recovering

I'm initial author of this commit and I'd love to fix the issue,
but it never happens to me. I need your help to fix it.
Can you provide some steps to reproduce this bug? How much time it
takes to reproduce it? Can you reproduce it with alsa 1.0.27 and

I'll test this during the weekend. 1.0.27.x was fine with alsa 1.0.27.

Sorry it took this long, the following version is fine:
media-plugins/alsa-plugins-1.0.27-r3 was built with the following:
USE="ffmpeg jack libsamplerate speex -debug -pulseaudio" ABI_X86="32 64 -x32"

It takes between 1 and 10 minutes to reproduce the bug with alsa-plugins-1.0.28.

Alsa-lib info is in both cases:
media-libs/alsa-lib-1.0.28 was built with the following:
USE="python -alisp -debug -doc" ABI_X86="32 64 -x32"
PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7"

I'm somewhat suspicious is it caused by a wrong Jack buffer size, and
only masked by incorrect handling of buffer fill in the older version.
Verbose log from aplay is attached (w/ alsa-jack 1.0.27.x).
Note the discrepancy between JackClient period size (not divisible by
actual period size) and ALSA min_avail.

Best regards,