Posts by 5schatten

    It picks whatever Pulseaudio picks. My NUC has two cards with several devices, PA correctly detects 0,7 and it’s what my script generates config for.

    How do you tell PA which output it should use? Because normally you would get this output if PA is not running any sinks:


    It works fine for me once I start a frontend & PA has created a sink I've chosen. But then again I could use this code to let PCSX2 use the "fake" ALSA output while still PA is running :/

    I guess this config file is just an option to add your custom channel config if you run into quirks :/

    So basically this works for systems with a single audio card on the first output? The problem is once you use dedicated GPUs or not the first video output you run into trouble. Otherwise probably fine -> have to test it.

    Well what in particular could be the reason for 44% volume on master in this file? I've played a bit with decreasing the volume by using dB but wasn't able to exactly hit 44% which also isn't exactly what I would expect once you set 25% for PA. /shrug:/

    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. :rolleyes:


    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 :thumbup:

    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. :/

    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 :S 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. :angel:


    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. /shrug

    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. /shrug

    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.

    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.

    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. /shrug

    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. /shrug
    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./shrug


    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.

    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?

    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. /shrug

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

    Being too lazy to research how to use it properly does not equal being useless ;)


    HDMI is a digital signal so it's only logical that volume control doesn't work (ever try adjusting the volume on your TV when connected to a soundbar with optical?). What Pulseaudio does is resampling the audio stream before passing it along, so in that way increasing the volume is possible. You could do the same thing with ALSA as well by using dmix/softvol. As for PCSX2, if you wanted to use Pulseaudio you could just configure your container properly so that it would use it. You can have sound in video previews at the same time as you have sound in the menus as well, there is nothing that requires Pulseaudio.


    And how do you think Pulseaudio talks to your sound card? ALSA :)

    Well I'm aware of those ALSA plugins & I know that basically Kodi and PA just resamples the given audio stream and in- or decreases the volume this way. AFAIK the master volume just controls the onboard amplifier and sets the output voltage for analog outputs.


    But to be honest I had other priorities. Maybe some would call it lazy but I was to busy to overhaul the docker scripts & images to make sure you always get a defined tagged version of the container and I was also busy to fix PCSX2 for at least most Nvidia users by figuring out what's wrong with the driver. So yes you might have to take your remote and lower the volume but at least you can run ps2 games. ;)


    If someone isn't pleased by using one of three frontends that all feature theming, assets or video previews then c'est la vie. Feel free to use any third party stuff and I help to fix some bugs if I can but I'm not motivated to reconfigure the ALSA stuff while a fully functional PulseAudio backend is available which even the average user can configure in a Kodi addon without having to deal with a terminal or other cli stuff. But as I said priorities /shrug


    In the end you can either use this build which basically runs ootb after some minor adjustments or you craft a custom solution. Pick your p0ison :P

    Build RR-20190423-716b9f8 | is mostly online | C2 uploading

    • updated copyright & license in package files
    • added basic Rockchip project for RockPro64 RK3399 -> WIP
    • updated to latest LE 9.x
    • updated to Kodi 18.2
    • updated Generic kernel to 5.0.9 | RPi kernel to 5.0.8
    • updated Mesa to 19.0.2
    • updated Vulkan to v1.1.106
    • updated dav1d to 0.2.2 & fixed multi threaded SW AV1 decoding
    • updated Gstreamer to 1.16.0 | added gst-omx for RPi -> WIP
    • updated FluidSynth to 2.0.5
    • added Kodi announcement when a frontend & Spotify is started
    • fixed ALSA volume for analog audio -> restores 100% after exiting frontends
    • added recording options to Retroarch -> you have to delete your retroarch.cfg before you update, start, exit & start RA again if you use PulseAudio
    • splitted libretro cores & coreinfo into separate packages -> clean up & satisfies my ocd ;-)
    • added lr-nSide SNES emulator based on higan v106r25 to Generic builds
    • updated (lr-)ppsspp to v1.8.0-dev for Generic | reverted v1.7.5 for all other projects due speed issues
    • updated GLideN64 to 4.0 for Generic | fixed build for RPi but still WIP
    • updated DOSBox to 0.74-2 | r4156
    • updated several libretro-cores
    • updated citra & dolphin

    You could try to insert "amixer set Master 25% unmute" at some point of the script that launches the game... But I don't know if there's a "close script" where you can insert the same code to roll back alsa master volume to 100%.


    Hope this gives you the start point for your solution.

    This could work if he uses analog audio too, but at least on my systems the master volume did not change the volume of my HDMI audio output.


    So something like amixer -q set Master,0 75% unmute in front of the dolphin start command could work.

    In the past I used alsa as audio backend because I didnt manage to run pulseaudio. Now I gave it another try because this volume difference between dolphin and the rest annoys me too and just noticed that everything I had to do was unchecking "Use module-udev-detect to autodetect PulseAudio device". So the sound is working now and also decreasing the volume in the rr config tool works fine.

    However only with Emulationstation 5schatten you maybe remember that Im using a different script in Rom Collection Browser and I dont get it working with pulse. Currently I have no sound in dolphin if I start it via RCB. Can you please take a look and tell me what I have to change? Is it even possible to use pulse on this setup because I dont freeze kodi and I use alsa in kodi?


    I just tried to change =alsa to =pulseaudio but that doesnt work.

    In short? No. As long as Kodi is running the ALSA device is locked and PulseAudio can't create the sink. So unless Libreelec itself won't rework the whole audio subsystem to use PulseAudio this is not an option.

    Aw, okay. I misunderstood... I thought you were using pulseaudio even in kodi for digital output.


    So, if you're using alsa in kodi like me, the only difference is analog or digital output? With digital audio your scripts work fine but with analog don't?


    I'll wait for your fix now that it's identified. Thanks a lot for your work.

    I guess they use PA because it's able to detect & configure bt devices on the fly. In the past PA had some issues and so they did not fully made the step to use PA for everything.
    My workstation has some analog speakers attached but it's a while since I used it. Maybe the sound output changes there too but I guess only a small minority don't uses a digital audio system ://shrug