[GH-ISSUE #488] Neither rodio nor alsa output working when using dmix plugin / alsa-jack bridge.

kerem commented

2026-02-27 19:29:56 +03:00

Owner

Originally created by @mr-berndt on GitHub (Jun 8, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/488

Hello, I am the developer of Aroio OS, an embedded audio player distribution based on GPL software. There are commercial products available but the OS is free and can be run on any Raspberry Pi. -> https://www.abacus-electronics.de/produkte/streaming/aroiosu-11/aroiosu.html

At the moment I am trying to integrate librespot into the system but sadly I am facing issues with each of the audio outputs I am trying to use.

We are using mostly jackd in order to be able to run multiple player services simultaneously and feed them into BruteFIR, if wanted. Since jackd and BruteFIR run on a fixed sampling rate, this leads to a chain which automatically needs to insert a resampler for players which output with a sampling-rate that differs from jack's/BruteFIR's. So using jack straight away is no option, due to the lack of a resampler. Overcoming this is done via the alsa dmix plugin followed by an alsa-jack plugin. This chain is running stable with aplay, squeezelite, gmediarender, shairport-sync and bluealsa-aplay, even when running all of them simultaniously, so I consider it to be functioning properly.

Now when trying to output into our alsa-jack bridge using librespot's alsa-ouput module, I get the dreaded EINVAL-error:
ERROR librespot_playback::audio_backend::alsa] Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument'

When tring to output using rodio I end up with:
ALSA lib pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slave ALSA lib pcm_dmix.c:1024:(snd_pcm_dmix_open) The dmix plugin supports only playback stream

To me it looks like rodio is trying to open a capture channel, which can not work, since we do not have audio inputs. Also it is not needed in this case.

How to go about fixing this? I understand that librespot on the long run might drop all other audio ouputs in favour of rodio, so maybe it makes most sense to concentrate on getting this to work. Sadly there are no options for influencing parameters of any of the given output possibilities, so I have no way of trying to debug this myself.

Can you help here or point me in the right direction for fixing this error with rodio?

Any help would be very welcome, especially since it concerns hundreds of users who would surely love being able to use your very appreciated software on their streamers!

Originally created by @mr-berndt on GitHub (Jun 8, 2020). Original GitHub issue: https://github.com/librespot-org/librespot/issues/488 Hello, I am the developer of Aroio OS, an embedded audio player distribution based on GPL software. There are commercial products available but the OS is free and can be run on any Raspberry Pi. -> https://www.abacus-electronics.de/produkte/streaming/aroiosu-11/aroiosu.html At the moment I am trying to integrate librespot into the system but sadly I am facing issues with each of the audio outputs I am trying to use. We are using mostly jackd in order to be able to run multiple player services simultaneously and feed them into BruteFIR, if wanted. Since jackd and BruteFIR run on a fixed sampling rate, this leads to a chain which automatically needs to insert a resampler for players which output with a sampling-rate that differs from jack's/BruteFIR's. So using jack straight away is no option, due to the lack of a resampler. Overcoming this is done via the alsa dmix plugin followed by an alsa-jack plugin. This chain is running stable with aplay, squeezelite, gmediarender, shairport-sync and bluealsa-aplay, even when running all of them simultaniously, so I consider it to be functioning properly. Now when trying to output into our alsa-jack bridge using librespot's alsa-ouput module, I get the dreaded EINVAL-error: `ERROR librespot_playback::audio_backend::alsa] Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument'` When tring to output using rodio I end up with: `ALSA lib pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slave ALSA lib pcm_dmix.c:1024:(snd_pcm_dmix_open) The dmix plugin supports only playback stream` To me it looks like rodio is trying to open a capture channel, which can not work, since we do not have audio inputs. Also it is not needed in this case. How to go about fixing this? I understand that librespot on the long run might drop all other audio ouputs in favour of rodio, so maybe it makes most sense to concentrate on getting this to work. Sadly there are no options for influencing parameters of any of the given output possibilities, so I have no way of trying to debug this myself. Can you help here or point me in the right direction for fixing this error with rodio? Any help would be very welcome, especially since it concerns hundreds of users who would surely love being able to use your very appreciated software on their streamers!

kerem

2026-02-27 19:29:56 +03:00

closed this issue
added the
audio
label

kerem commented

2026-02-27 19:29:57 +03:00

Author

Owner

@ashthespy commented on GitHub (Jun 8, 2020):

Now when trying to output into our alsa-jack bridge using librespot's alsa-ouput module, I get the dreaded EINVAL-error:
ERROR librespot_playback::audio_backend::alsa] Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument'

This happens because the alsa back-end implementation here makes some assumptions of the buffer size, and sets them. It is quite possible that your alsa-jack plugin doesn't support the default buffer size. You could play around with the buffer size and/or check the documentations for the alsa-jack plugin to see what are the parameters it supports.

EDIT: So a quick google suggests the alsa-jack is picky with the buffersize

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.

So you could try playing with the buffer size.. I vaguely recall a discussion about if this should be a configurable setting, so we could revisit that if you get it working :-)

I understand that librespot on the long run might drop all other audio ouputs in favour of rodio, so maybe it makes most sense to concentrate on getting this to work.

I hope not - rodio has quite some overhead on little SBCs compared to alsa!

@ashthespy commented on GitHub (Jun 8, 2020): > Now when trying to output into our alsa-jack bridge using librespot's alsa-ouput module, I get the dreaded EINVAL-error: > `ERROR librespot_playback::audio_backend::alsa] Alsa error PCM open ALSA function 'snd_pcm_hw_params_set_buffer_size_near' failed with error 'EINVAL: Invalid argument'` This happens because the alsa back-end implementation here makes some assumptions of the buffer size, and sets them. It is quite possible that your `alsa-jack` plugin doesn't support the default buffer size. You could play around with the [buffer size](https://github.com/librespot-org/librespot/blob/dev/playback/src/audio_backend/alsa.rs#L44) and/or check the documentations for the alsa-jack plugin to see what are the parameters it supports. EDIT: So a quick google suggests the alsa-jack is [picky with the buffersize](https://bbs.archlinux.org/viewtopic.php?pid=1870460#p1870460) >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. So you could try playing with the buffer size.. I vaguely recall a discussion about if this should be a configurable setting, so we could revisit that if you get it working :-) > I understand that librespot on the long run might drop all other audio ouputs in favour of rodio, so maybe it makes most sense to concentrate on getting this to work. I hope not - rodio has quite some overhead on little SBCs compared to alsa!

kerem commented

2026-02-27 19:29:57 +03:00

Author

Owner

@mr-berndt commented on GitHub (Jun 8, 2020):

Thx for your answer and the link, which looks very interesting. I am just going out right now and will look into it tomorrow and report back.

@mr-berndt commented on GitHub (Jun 8, 2020): Thx for your answer and the link, which looks very interesting. I am just going out right now and will look into it tomorrow and report back.

kerem commented

2026-02-27 19:29:57 +03:00

Author

Owner

@mr-berndt commented on GitHub (Jun 9, 2020):

The patch linked in that thread simply solved the problem - many thanks for pointing this out!

@mr-berndt commented on GitHub (Jun 9, 2020): The patch linked in that thread simply solved the problem - many thanks for pointing this out!

kerem commented

2026-02-27 19:29:57 +03:00

Author

Owner

@ashthespy commented on GitHub (Jun 9, 2020):

Just to confirm - you mean the patch from this post?

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.

@ashthespy commented on GitHub (Jun 9, 2020): Just to confirm - you mean the patch from [this post](https://bbs.archlinux.org/viewtopic.php?pid=1870631#p1870631)? >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](https://octet.space/files/alsa-plugins-1.1.9.tar.xz). 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.

Rows
Columns

[GH-ISSUE #488] Neither rodio nor alsa output working when using dmix plugin / alsa-jack bridge. #308