Posts by 5schatten

    Would it help if I posted my logs? I had a quick look through them all but can't see the event that locks the system up.

    On a side note.. once the system locks up I can still access the samba share but the screen is completely unresponsive.

    Again.. it only happens when the system is doing nothing.

    When playing media or a game is running.. even if noone is doing inputs.. it doesn't lockup.

    But if it's left on any screen idle doing nothing.. it will lock up within 1 minute.

    If others distros lock up I hardly doubt there is a fix for this. Basically it's a 11 year old legacy card that won't see much support anymore.

    LibreELEC 10.0 will remove support for Xorg/X11 windowing on x86_64 hardware and move the entire distro to a common DRM/GBM video framework. This change will also impact nVidia users as Kodi v19 removes support for VDPAU (it doesn’t support many new graphics features and is no longer developed) and there are currently no signs of nVidia supporting GBM like all other GPU/SoC vendors. Between now and LibreELEC 10.0 the team will be working to achieve GBM/DRMPRIME feature parity so nobody notices the switch

    X11: remove vdpau and glx by lrusak · Pull Request #16057 · xbmc/xbmc · GitHub

    Drop X11 by lrusak · Pull Request #3152 · LibreELEC/LibreELEC.tv · GitHub

    So pesonally I would suggest Nvidia users to get rid of their cards sooner than later... I have to figure out how to deal with this removals & how to integrate a substitute like Wayland/Weston but from all I heard X11 is pretty much a dead end and since Nvidia does not support other displayservers you won't be able to use their drivers anymore. Of course there is nouveau but this won't support all features as the proprietary driver does.

    Hello.

    I currently use this build on an older hp aio with a Nvidia 9300m so it defaults to using the legacy driver.

    However this driver is bugged and causes freezes after 30 minutes.

    Is it possible to change it to use the nouveau driver or the patched 340 driver that stops the crashes?

    Thank you for all your work

    Do you have a link to the 340 patch set? If there is one it should be no problem to build the driver with this patches. Nouveau on the other hand is basically no option at the moment. Well at least without complete rewrite how LE handles Nvidia drivers right now.

    I dont know if its me or if i'm lacking a method here. i have retroarch on multiple devices and OSes (two biggest ones are this and windows.) but when i transfer the .srm file (which is the save pak) from windows (1.7.3) to here (1.7.6) i always get a corrupt mempak error and its deletes my save and fill the mempak with a bunch of zero files. this prevent me from taking my game with me when im not at home....

    so.....are the saves in retroarch transferable?

    Well I can't give an exact answer about this. I have all my roms on my NAS & use Generic / RPi & KVIM builds with different emulators to run the same games. So I can play Link to the past on all systems with different emulators but all systems run the same RA version and are Linux builds. Have you tried to update your RA version? I mean 1.7.3 is about one year old and almost 4800 commits were merged since then.

    Is there a way I can resize dolphin window to be viewable on a 800x484 resolution?

    Actually I'm not able to view all the configuration windows entirely so it's very hard (or even impossible) to access all the configuration options.

    Thank you

    You can try to set custom dpi but I guess they have some fixed minimum sizes which won't play along with such low resolutions.

    Is anybody else getting screen tearing during video playback in Chrome?


    I've been running RR-20190404-1cc7fad on an Asus Chromebox (Haswell Celeron 2955u model with integrated Intel graphics) with no issues, but after a recent Chrome update, video playback started to display horrible tearing (best exhibited by opening this YouTube tearing test: YouTube. This same YouTube video doesn't tear in the YouTube Kodi add-on and neither do any videos I playback directly in Kodi or the Plex addon).


    I updated to RR-20190423-716b9f8 and this made no difference at all. I also tried creating a custom xorg.conf in the ~/.config directory with the following settings:

    If it started after a Chrome update it's probably related to Chrome. So I guess we have to wait for a bugfix then.

    The latest version I've uploaded was compiled at the 23.04. and not the 19.04. so you don't use the latest version. I've checked pcsx on my RPi3B (again) and it runs fine. I tested GT2 & Castelvania, if you get 3-5fps this is most likely not related to any missing optimizations because if the emulator is build without NEON then it runs slower but not at 5-10% of the original speed.

    Also /tmp/cores should not be touched the. If you download cores they should be placed in /storage/.config/retroarch/cores

    I merged the ones I thought were related, but maybe I missed one if it was committed a while ago, will look at them again.

    My TV is an old 1080p TV so I might need to also check that to make sure the auto detect is working.


    But since its working on your VIM at least I know its something on my end!

    Question, is there a simple way to make sure the configuration of PA and ALSA is correct? and maybe I am wrong in other areas (like emu or ES configuration)

    Well you got that wrong -> I use a complete different way to configure the audio backend because autodetect won't work reliable. But if you include all of escalade commits it should work but might break compatibility to other Kodi stuff. Been there, done that. Last time I tried to use PA in Kodi it broke audio passthrough for me so I keep it to the emulation stuff.

    Thanks for this! I tried implementing it on Amlogic but I failed (no sound at all), I think I am missing something, but I do like the elegant solution!

    Did you merge all commits touching this? You probably need a lot of other PA related ones too. One problem for my Vim was that on certain tvs udev does not detect a correct device. So even if you use this it possible that autodetection of the correct device just failed.

    I don't manually create anything, it will create a sink for the connected output.

    Indeed but a standard LE installation uses PA only for bluetooth so unless you start PA with a custom config that creates the sinks you wont't get any proper output for pactl list sinks

    Exporting -e PULSE_RUNTIME_PATH=/run/pulse \ to docker & updating the .inis is enough so run PCSX2 with PA?

    EDIT: works now.

    I’ll let you figure it out, you have no need for this useless stuff right? 😉

    Well this script makes only sense if you use a PulseAudio sink which standard LE doesn't.:/ So yes unless I use something like this it's still useless. Why should I create a PulseAudio sink and let a script create a config file that tells programs to use the same ALSA device & stop PA afterwards /shrug

    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 thought perhaps because of this, but it seems like it's not being saved anywhere.

    5schatten

    niabi

    Elegant (somewhat) configuration of ALSA (dmix) based on the default sink detected in Pulseaudio: done. Tested on XU4/RPi3/Intel. Good bye pulseaudio ;)

    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.

    HaLeXz

    5schatten

    Think I found the cause of your volume troubles:

    LibreELEC.tv/soundconfig at master · LibreELEC/LibreELEC.tv · GitHub

    It's being run by /usr/lib/udev/rules.d/90-alsa-restore.rules.

    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.