LibreELEC-RR 9.x [ Emulationstation | Retroarch | Pegasus | DolphinQT | Moonlight | Chrome | Spotify ]

Quote from escalade

Prioritize all you want, that doesn't make ALSA useless is all I'm saying. In fact it's very powerful by itself and certainly a better choice for low power systems.

As I said for my usecase a pure ALSA audio device is useless. ALSA is fine as long you just have to satisfy basic needs without mixing. Also on many systems PA manages autodetection of the available devices & and sets them up the without the need of any terminal magic so personally I prefer it. My RPi3B and my S905X based devices seem to handle PA also fine but maybe I'm not "audiophile" enough to hear a difference or see any performance regressions.

And if Kupo91 wants to play with dmix nobody will stop him to do so.

Of course the "Advanced Linux Sound Architecture" itself is not useless but the basic functionality it provides without additional mixing plugins or a soundserver that uses the ALSA API. But in the end this discussion is splitting hairs since you always need a more advanced setup once you use more than one source at a single time & if ALSA would suit all needs nobody would develope PulseAudio or PipeWire or whatever comes next.

Once you "touch" the audio stream I guess it's always resampled in one way or another. The standard volume is way to loud which was the reason why I added a slider to reduce it in the first place. ALSA resampling works faster because it offers only a simple linear resampler but I have no clue if it still is the only sampler it uses.

Have you tried to run PA with resample-method = trivial Looks like most of the resamplers work quite well so maybe we should give speex-float-1 a try and build PA with speex support?

Quote from escalade

You're still wrong, as I have been trying to tell you ALSA by itself can mix different sources at the same time just fine. Mixing sources is not the only use of Pulseaudio so that logic does not work. You can also choose different resamplers in ALSA. I'm currently investigating all options, for Pulseaudio the "avoid-resampling" and "alternate-sample-rate" options are interesting and of course the different methods. Another option I have read about is openal-soft which has a NEON optimized resampler.

Okay then these guides are probably wrong too? Because all tell me the same. If your soundcard lacks hardware mixing support, which most of them do, then you need the dmix plugin.
https://wiki.archlinux.org/index.php/advanced_linux_sound_architecture#dmix
https://wiki.debian.org/alsa#sharing_a_card_among_multiple_processes

https://alsa.opensrc.org/dmix

According to this forum Audiokonfiguration – DebianforumWiki you end up with this package Debian -- Informationen über Paket libasound2-plugins in sid & it's resamplers. The amount is negligible And I guess once you use speex as ALSA plugin it also uses quite some CPU power otherwise it's probably magic.

This overview also points to speex as best resampler PulseAudio under the hood

EDIT
speexdsp supports NEON speexdsp/resample_neon.h at master · xiph/speexdsp · GitHub also if FFmpeg is used as resampler it might uses NEON too since it is build with NEON support.

Quote from escalade

Dude, dmix is a part of alsa-lib. Yes, mixing requires CPU power if it's ALSA/dmix or Pulseaudio doing the job. I'm interested in either not doing any mixing at all or using the most efficient method if that's not possible.

alsa-lib =! ALSA

You have the ALSA kernel driver then libasound as wrapper then SDL audio, OpenAL, PulseAudio or whatever on top. Dmix is just a plugin that extends functionality and can be build but isn't exactly needed to make it work. Mixing is inevitable for me otherwise you won't get any sound output from video snaps because ES or Pegasus either use VLC or Gstreamer libs to provide audio output. Depending on what played first you get menu sounds or video sounds if you have no working audio mixer which is not the desired user experience. If you come up with a more sophisticated solution I'm all in otherwise this discussion is pointless.

Quote from escalade

What do you mean alsa-lib is not ALSA? What is it then? OSS? It's not a wrapper, it's the ALSA userland library which talks to the ALSA kernel module. You're always using alsa-lib when you're getting sound from your computer. "Dmix is just a plugin that extends functionality and can be build but isn't exactly needed to make it work" I really don't understand what you're trying to get at here, dmix is a _part_ of alsa-lib, it's built in by default and it's automatically enabled for any analog outputs. You can enable it for your HDMI output as well and then you can have menu sounds and video sounds at the same time like you seem to think people have moved to Pulseaudio for.

There's several possibilities like I've been trying to tell you:

1. With Pulseaudio there seems to be "avoid-resampling" that is normally not enabled.

2. You can set up an asound.conf with one pcm that uses direct hardware (point emulators to this) and one pcm that uses dmix (point frontend to this)

3. Use pasuspender which temporarily suspends pulseaudio (then run emulators with ALSA direct to hardware)

EDIT:

4. Not sure about this one, but since RetroArch does it's own resampling you might end up remixing the stream twice. Setting the RA resampler to null might be an option.

5. As mentioned, there's OpenAL that has NEON optimized resampling. This might be faster but haven't tried.

Display More

All I say is that ALSA consists of more than alsa-lib & the dmix plugin is an _optional_ part of this lib otherwise explain me why it can be disabled. The Kernel uses an ALSA driver which can't talk straight to SDL sound so you use libasound to provide an API for SCI. You wouldn't call Retroarch libretro, would you?

About the alternatives:

1. As long as I alter the audioo stream volume I probably have to resample it so this could be an option for analog but not for me personally
2. So I would still resample & have to use speex which PA also supports while lose autodetection of audio devices which PA provides?
3. Not an option if you want to use FluidSynth so I still would have to use dmix

In the end the only thing that is interesting for me is how to properly run Docker & PA to get rid of the actual implemented on & off script which temporary disables the PA sink for PCSX2.

It's quite possible that RA still uses it's own resampler because afaik it also has the ability to alter the volume. But since most consoles & home computers used different sample rates I guess it's not a great idea to disable sampling in RA

Some emulators like FS-UAE or Yamagi Quake II already use OpenAL but I guess it's not as versatile & widespread as PA. If it's not already the default I would give the ffmpeg resampler a try LibreELEC.tv/package.mk at master · LibreELEC/LibreELEC.tv · GitHub but I doubt recent codes aren't optimized for NEON anyway.

Quote from escalade

I'm well aware that dmix can be disabled, I'm just not sure what that has to do with anything. Alright so it's not interesting for you, just informing others that ALSA definitely is not useless. I have ES with menu sounds and omxplayer both outputting at the same time with ALSA at the moment, it's an option. I don't do guessing, I do testing

Without altering/reworking the provided configuration and without the dmix plugin ALSA is useless. And since many users tend to fail to copy & paste a single line of the aplay -L output they will run into trouble if they would have to create a more advanced config file.

If you really think my build is based on guessing & not testing it's fine. But at least I test all emulators on all SBCs before I upload a build that uses someone else. Can you say the same? So feel free to go on with this rather pointless discussion. You proved your point that ALSA with the dmix plugin is able to mix streams. But the PulseAudio server is running all the time anyway at a standard LE build so the only reason to use ALSA over PA would be that the resampling works at the same quality with lower cpu usage.

Quote from escalade

I'm not talking about your build, I'm talking about ALSA which you now again are calling useless (remove ALSA then if you think it's useless). Your attempt at a pissing contest is just weird, just accept that you were wrong and move on. I'm using Pulseaudio as well, but like to test all options. Pulseaudio needs to be modified from the default setup to work with ALSA and users aren't able to do that either unless you do it for them. FYI kodifreeze.sh was written at a time when I was lazy too. Congrats on finding a typo in my tree there are probably plenty more

Keep on splitting hairs if there is no proper mixing & correct configured sink it won't work so without script magic it won't work. If you read the posts there was probably not a single page blaming not working audio or other quirks because setting up asound.conf was too complicated for many users. I made a decission for my build to rely on PA & it works. If someone want's to use RCB as Kodi addon which needs reworked scripts he can just disable my config addon and set the vars by hand. Good luck.

If you use my build with the provided frontends & enable PA as backend everything works and for common systems the udev modul will autodetect the given sound hardware. Since you don't use Kodi anymore and start straight to ES or RA you don't need kodifreeze.sh anymore. If you prefer a LE based media center with some more or less proper emulation addons you still need to shutdown Kodi properly or you need some additional script magic to stop Kodi & other programs figthing for the console.

The point is not the typo the point is that you tell me I don't test things while you integrate emulators into your build which you never tried to run. And this somewhat pisses me off. And if you think it's pure laziness to not overhaul the ALSA config to satisfy the needs of a single user that only has to lower his volume a bit while he uses completely different frontends & custom scripts well yes then I'm probably lazy.

Quote from escalade

Proper mixing is enabled by default on analog outputs and it's a oneliner if it isn't. Do whatever you like personally and in your builds, this is besides the point which is that you are spreading misinformation. You certainly haven't tested dmix when you keep insisting what I'm saying isn't possible. Again with the pissing contest, I could not care less what works in my build I'm not claiming it does. The laziness is you giving false statements on subjects you clearly have no clue about. Not saying you should rework anything to do ALSA, just don't tell that "single user" that it's not possible. It's a public forum, more than the single user are reading it.

Keep splitting hairs as long as you wish. If I write ALSA is useless then it should be obvious that it's useless for my build and for the given scripting & configuration. It just won't work because even if he alters the asound.conf file it will be recreated by a script after a reboot. So it's not possible to use it in my build at the current state because the intention was to use PA not pure ALSA without dmix.

But as I said priorities... I'm more focused on the other 99% of users & achieving a nice overall experience without forcing them to use a terminal for absolute basic things like setting up sound.

But yes escalade is right. In theory a pure ALSA configuration is not useless. I could have reworked the asound.conf file, the config addon & the scripts to create a config that uses the dmix plugin to either use a crappy low-quality linear interpolation or the speex codec to achieve mixing at a better quality. Still it would lack autodetection and still PulseAudio would run without sinks in the background and still dmix + speex would take a fair share of cpu resources but yes you would not need PulseAudio to achieve a somewhat similar experience.

All I have to do is reworking the existing scripting to achieve the exact result of an already up and running configuration that might improve the experience on outdated low-end SBCs

I am glad that we have clarified that So I'm open for suggestions. Should I focuse on updating and improving the build, add more emulators or optimize stuff or should I just rework stuff that already works.