ALSA -> JACK Plug not working anymore

zoidby · 2019-10-20 17:08:49

Edit: As described by adenosine here, there are two bugs at play. The first one regarding locking might be fixed in the next alsa-lib version. The second one, which produces the error below is still obscure to me.

Edit2: adenosine found the second bug and provided a patch here. I will change the topic to [Solved] once a new version of alsa including the patch is finally out.

This doesn’t work for months.

I use the alsa-jack-plugin as described in the wiki.

But when i play some audio i get this error:

$ mpv --ao=alsa someaudio.mp3
Playing: someaudio.mp3
(+) Audio --aid=1 (mp3 2ch 44100Hz)
[ao/alsa] Unable to set buffer time near: Invalid argument
AO: [alsa] 44100Hz stereo 2ch float
^C

Last edited by zoidby (2019-10-27 12:27:21)

Maniaxx · 2019-10-22 01:17:02

- Try setting buffer explicitly in .asoundrc
- mpv supports jack directly
- use a loopback device instead

zoidby · 2019-10-22 21:18:08

- Try setting buffer explicitly in .asoundrc

How?

- mpv supports jack directly

I know, mpv was only used for testing/demonstration purposes. I need alsa to jack routing for other applications, which don’t support jack.

- use a loopback device instead

I did that before, but it sucks. It produces additional cpu load, latency and dropouts. I used both alsa_in and zita-a2j. The jack-plugin-solution was much more stable, simple and smooth for the time it worked.

Last edited by zoidby (2019-10-22 21:20:22)

Maniaxx · 2019-10-23 07:43:43

You handled the conflicting pcm statements already?
https://mailman.alsa-project.org/piperm … 41213.html

I personally use the loopback device as alsa bridge and it works properly for me with the lowest latency (5ms) my hardware supports (audigy2).

Do you have 'realtime scheduling' enabled?

Regarding 'buffers' you have to look up some example .asoundrc configs. Its just a wild guess though. Not sure if that is possible/helpful here.

If all this doesn't help you probably should ask that upstream.

Last edited by Maniaxx (2019-10-23 07:45:58)

zoidby · 2019-10-23 12:28:21

You handled the conflicting pcm statements already?

I did, but that would not be a problem anyway, because the ~/.asoundrc overrides system wide definitions. If you have a system wide pcm.jack and a user pcm.jack, the user one gets used.

I personally use the loopback device as alsa bridge and it works properly for me with the lowest latency (5ms) my hardware supports (audigy2).

But what are you using to route the loopback audio to your main-out? You need something like alsa_in or zita-a2j for this. And these programs are what causes additional cpu load, dropouts, bad audio quality or latency.

Do you have 'realtime scheduling' enabled?

I have.

Regarding 'buffers' you have to look up some example .asoundrc configs. Its just a wild guess though. Not sure if that is possible/helpful here.

I don’t know if and how you would define that for the jack-plugin. Unless i find a official documentation on that i’ll get errors like this:

ALSA lib pcm.c:7574:(snd_pcm_slave_conf) Unknown field buffer_size

Maniaxx · 2019-10-23 13:56:25

something like alsa_in

Yes, i'm using that.

these programs are what causes additional cpu load, dropouts, bad audio quality or latency.

Any particular example?

I will try to set up pcm.jack later the day myself. But i guess it's simply outdated and maybe not maintained anymore upstream (due to alsa's native bridge capabilities).

zoidby · 2019-10-23 14:13:58

Any particular example?

Example for what? I won’t go into every little detail on what sucks about these, because i want this thread to be about the jack-plugin and not these workarounds. But it should be obvious that running a separate daemon to route audio from alsa to jack produces additional cpu-load. Just check top. You can also read this page on zita-a2j to learn about the shortcomings of alsa_in. But don’t assume zita-a2j is perfect either. I had to run it in a loop, because it would suddenly crash.

I will try to set up pcm.jack later the day myself.

Thanks, i am looking forward to that.

Last edited by zoidby (2019-10-23 14:15:15)

Maniaxx · 2019-10-23 22:59:50

aplay does work with jack.pcm. Others like Audacious do not.

I've tried zita-a2j with loopback device as well but doesn't work either. So, looks like the only reliable method is 'alsa_in' at the moment.

$ zita-a2j -L -v -d hw:Loopback
playback : not enabled
capture  :
  nchan  : 2
  fsamp  : 48000
  fsize  : 256
  nfrag  : 2
  format : S16_LE
Alsa_pcmi: error on capture pollfd.
Alsa_pcmi: error on capture pollfd.
Alsa_pcmi: error on capture pollfd.
Alsa_pcmi: error on capture pollfd.
[...]

Last edited by Maniaxx (2019-10-23 23:23:02)

zoidby · 2019-10-24 13:27:55

aplay does work with jack.pcm. Others like Audacious do not.

Indeed, i did not know that.

adenosine · 2019-10-25 06:56:43

After quite a bit of time working on this, it believe it to be a bug in alsa-lib around how it handles certain types of locking.

[ao/alsa] Unable to set buffer time near: Invalid argument

is just a red herring. You can 'fix' that in mpv by using

mpv --alsa-buffer-time=0

but it still doesn't play anything. However

env LIBASOUND_THREAD_SAFE=0 mpv whatever.mp3

works just fine. You can also use

mpv --alsa-resample=yes

to work around it, at least in MPV.

The good news is, this commit from last month fixes the locking issues. I built a new package from git, installed it, and it's working now with a simple .asoundrc

pcm.!default {
    type plug
    slave.pcm "jack"
    hint.description "Jack Audio"
    rate_converter "speexrate"
}

You still get the error message, but it plays audio just fine.

zoidby · 2019-10-25 13:59:52

Thank you adenosine!

Your comment explains everything i was looking for.

Looking at their release cycle of alsa-lib, it seems, that a new release might be around the corner.

For now i have included

export LIBASOUND_THREAD_SAFE=0

in one of my startup scripts as a workaround and will consider this fixed. I will finally change the topic to [Solved] once a new alsa-lib is out and working.

Thanks again, to everyone who contributed here.

Maniaxx · 2019-10-25 16:01:23

adenosine wrote:

The good news is, this commit from last month fixes the locking issues.

Whatever it fixes in mpv it doesn't work for Audacious. I don't think that's the real culprit.

Please someone test this:

1) Check if card0 is your primary soundcard indeed. Otherwise substitute card0 with cardx in the next steps.

ls -l /proc/asound

2) Check the 'prealloc' value:

cat /proc/asound/card0/pcm0p/sub0/prealloc

3) Change the 'prealloc' value:

sudo sh -c "echo 128 > /proc/asound/card0/pcm0p/sub0/prealloc"

4) Check the 'prealloc' value again to make sure it has changed indeed.
5) Test the bug
6) Go to step 3 again and try different values (64, 128, 512, 32768...). Successful values might be completely random. Don't expect any logic here.

zoidby · 2019-10-25 16:16:40

I can not change the prealloc value, it stays at 4096.

But setting the buffer size in audacious to 100 ms works for me.

Maniaxx · 2019-10-25 16:27:50

100ms doesn't work for me but 2000ms does.

Looks like a very old ALSA bug.
https://alsa-devel.alsa-project.narkive … d-argument

zoidby · 2019-10-25 17:00:56

As it seems, the edit of my first post was a bit premature and only one of two bugs might become fixed in the next version of alsa-lib. I will edit it again.

Maniaxx · 2019-10-25 21:13:47

The 'zita-ajbridge' bug might be directly related as well. If you start it with default values it doesn't work. But if you play with the buffers you might succeed.

Not working (default values):

zita-j2a -d hw:Loopback,1 -p 256 -n 2

Working:

zita-j2a -d hw:Loopback,1 -n 3
zita-j2a -d hw:Loopback,1 -p 512

zoidby · 2019-10-25 21:38:31

Afair zita would always complain if your buffer was too small. Your first command has a smaller buffer than both second ones.

zita-j2a

Are you aware, that this is the other direction and not what this thread is about? You need zita-a2j, to route alsa to jack.

Maniaxx · 2019-10-25 22:14:08

Indeed. Buffer just too small.

Yes, should be a2j. I just copy&pasted it quickly. Talked to the zita maintainer about it. Confirmed the issue, will look into it.

Probably not related then.

Last edited by Maniaxx (2019-10-25 22:17:48)

adenosine · 2019-10-26 01:28:22

I did more research on this problem the buffer errors.

The short answer is that snd_pcm_hw_params_set_buffer_size_near() in alsa-lib is completely stupid. I still haven't been able to figure out exactly how it's (not) working, but I have discovered how you can somewhat work around it.

The trick is that the jack plugin only accepts buffer sizes that are whole units of the frame sizes that the jack server requests. For example,

~ $ jack_control dp
--- get driver parameters (type:isset:default:value)
              device: ALSA device name (str:set:hw:0:hw:DAC)
             capture: Provide capture ports.  Optionally set device (str:notset:none:none)
            playback: Provide playback ports.  Optionally set device (str:set:none:hw:DAC)
                rate: Sample rate (uint:set:48000:48000)
              period: Frames per period (uint:set:1024:256)
            nperiods: Number of periods of playback latency (uint:set:2:3)
               hwmon: Hardware monitoring, if available (bool:set:False:False)
             hwmeter: Hardware metering, if available (bool:set:False:False)
              duplex: Provide both capture and playback ports (bool:set:True:True)
            softmode: Soft-mode, no xrun handling (bool:set:False:False)
             monitor: Provide monitor ports for the output (bool:set:False:False)
              dither: Dithering mode (char:set:n:n)
          inchannels: Number of capture channels (defaults to hardware max) (uint:notset:0:0)
         outchannels: Number of playback channels (defaults to hardware max) (uint:notset:0:0)
              shorts: Try 16-bit samples before 32-bit (bool:set:False:False)
       input-latency: Extra input latency (frames) (uint:notset:0:0)
      output-latency: Extra output latency (frames) (uint:notset:0:0)
         midi-driver: ALSA MIDI driver (str:notset:none:none)

Here we can see that jack is going to ask for 256 frames per period. You can also see that I've set the rate at 48000Hz.

So we take 256 / 48000 = 0.005333 seconds per frame, or more easily 5333 microseconds (which is what alsa-lib uses), or 5.333ms. The buffer has to be almost exactly a multiple that number, and then it works. The driver will also only accept a maximum number of 64 periods in the buffer. Alsa is terrible at figuring out the correct math on these when using the resampler, which many apps will use.

For example, a 39 frame buffer would give 207,987 microseconds, or 208ms. But 208,000 microseconds (208ms buffer in audacious) doesn't work. A 42 frame buffer, 223,986 microseconds, does work with a 204ms buffer in audacious. You just have to mess with values until they start not throwing error messages.

Still trying to figure out exactly what the source of the issue is, as the jack plugin clearly reports a list of all the valid buffer sizes it will take. I've never hacked on ALSA before so it's been a little hard figuring how it all comes together.

On a side note, the stuff in /proc/asound *should* never change with any of this. That devices is being 100% controlled by jack.

Last edited by adenosine (2019-10-26 01:30:23)

Maniaxx · 2019-10-26 12:27:18

You should bring that to alsa-devel.

zoidby · 2019-10-26 13:24:11

I tried to verify this with mpv, and odd multiples seem to be only a problem above the buffer time jack is running at.

My jack server is running at 44100, period 1024 and nperiods 2, which is a buffer time of 46440 µs, and indeed, all buffer times below 46450 μs in mpv do work (Notice the 10 µs more). Times above that have to be a multiple of the frame time.

To verify this, i set my jack server to rate 44100, period 2048 and nperiods 2, which is a buffer time of 92880 µs, and again, all buffer times below 92890 µs (Again exactly 10 µs more) in mpv are working.

I’ve also installed audacious to test it, but it is totally different there. When my server runs at period 1024, no buffer time works. But if my server runs at 2048, any buffer time can be set in audacious.

adenosine · 2019-10-27 04:30:08

Ok. I figured out(ish) the problem, and I have a fix(ish)!

The problem is while the jack plugin enforces the period to be a multiple of the frame size, and allows 2~64 periods, it doesn't specify the buffer sizes that it accepts as well. Other plugins like the 'plug' plugin directly try to manipulate the buffer size, disregarding if it's a whole unit of the period sizes or not (even though it does specify that the buffer has to an integer number of the period sizes). The code in pcm_ioplug then tries to make a proper period size/number, but it can't because the buffer isn't a value that can be used.

The fix is, in addition to specifying all the period sizes and number of periods to accept, to also have it list all the buffer sizes as well... except this solution is a bit of a hack because it's actually now reporting that it will accept some combinations of period sizes and number of periods that the buffer sizes don't allow, but in practice if you ask for a huge buffer it seems to work just fine, giving you a lower, more reasonable buffer.

You can download a 'new' PKGBUILD with my patch included here. It's not a proper PKGBUILD as I just upped the revision number so now pacman will complain about how you have a package that's 'too new' when you update. But now everything works with alsa without having to specify odd buffer sizes. I guess the next step is to see if properly ask upstream to patch this.

zoidby · 2019-10-27 12:20:54

Yep, that fixes it for me. Thank you very much. Lets hope your patch will get accepted.

On a side note, your archive seems to be a just a tar file and not xz compressed. That did confuse my unpacking function. You might want to rename that, if you want to keep it up until this is officially fixed.

adenosine · 2019-10-27 18:40:20

That's what I get for using tar without actually consulting the options. It's xz compressed now!

I've already posted this patch to the alsa-dev mailing list, so I hope it gets in. It's not perfect, however. I did a bunch more testing, and it turns out that certain combinations of filters will cause failures still, but you have be very crafty about it, and additionally they got harder to be reproducible when I switched my JACK server to use 128 frame periods instead of the 256 I was using before (I wanted lower latency now that alsa is adding some to certain apps).

However, I think the fault there lies in the plug/rate plugins. The rate plugins are amazingly braindead. They can't resample on float inputs, even though libsamplerate natively uses floats so you have to convert it to 16bit linear, then resample, then convert it back to a float. No wonder MPV turns off resampling by default.

Arch Linux

#1 2019-10-20 17:08:49

ALSA -> JACK Plug not working anymore

#2 2019-10-22 01:17:02

Re: ALSA -> JACK Plug not working anymore

#3 2019-10-22 21:18:08

Re: ALSA -> JACK Plug not working anymore

#4 2019-10-23 07:43:43

Re: ALSA -> JACK Plug not working anymore

#5 2019-10-23 12:28:21

Re: ALSA -> JACK Plug not working anymore

#6 2019-10-23 13:56:25

Re: ALSA -> JACK Plug not working anymore

#7 2019-10-23 14:13:58

Re: ALSA -> JACK Plug not working anymore

#8 2019-10-23 22:59:50

Re: ALSA -> JACK Plug not working anymore

#9 2019-10-24 13:27:55

Re: ALSA -> JACK Plug not working anymore

#10 2019-10-25 06:56:43

Re: ALSA -> JACK Plug not working anymore

#11 2019-10-25 13:59:52

Re: ALSA -> JACK Plug not working anymore

#12 2019-10-25 16:01:23

Re: ALSA -> JACK Plug not working anymore

#13 2019-10-25 16:16:40

Re: ALSA -> JACK Plug not working anymore

#14 2019-10-25 16:27:50

Re: ALSA -> JACK Plug not working anymore

#15 2019-10-25 17:00:56

Re: ALSA -> JACK Plug not working anymore

#16 2019-10-25 21:13:47

Re: ALSA -> JACK Plug not working anymore

#17 2019-10-25 21:38:31

Re: ALSA -> JACK Plug not working anymore

#18 2019-10-25 22:14:08

Re: ALSA -> JACK Plug not working anymore

#19 2019-10-26 01:28:22

Re: ALSA -> JACK Plug not working anymore

#20 2019-10-26 12:27:18

Re: ALSA -> JACK Plug not working anymore

#21 2019-10-26 13:24:11

Re: ALSA -> JACK Plug not working anymore

#22 2019-10-27 04:30:08

Re: ALSA -> JACK Plug not working anymore

#23 2019-10-27 12:20:54

Re: ALSA -> JACK Plug not working anymore

#24 2019-10-27 18:40:20

Re: ALSA -> JACK Plug not working anymore

Board footer