Posts by 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

Quote from 5schatten

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.

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.

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.

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.

No you said it’s useless actually, leaving out «for my usecase» In any case it’s wrong, as you need ALSA for your usecase to begin with as Pulseaudio is simply an extra process sitting on top of ALSA. There is definitely a difference for the RPi3b as far as performance goes, of course it depends on how u set up the resampler and what sample rate the core/emulator uses and so on. I suppose if you are using HDMI it might not touch the signal and require less resources. I have been testing on analogue.

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.

Quote from 5schatten

ALSA is basically useless & only needed for some special snowflake software like PCSX2. My TV uses HDMI and changing the ALSA Master volume does not even effect the audio output so it does not make sense to add any functions for this backend while PA normally works fine & is mandatory for video previews for example.

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

If you want to use Pulse you can run your container with -v /run:/run -e PULSE_RUNTIME_PATH=/run/pulse, I think that should do it.

I'm not maintaining the LE8 builds anymore. Here's my latest builds for Generic/RPi2/OdroidXU4: https://drive.google.com/open?id=1kjnihhx2ksdc71jfld3zb1dygpjyz0nq

Note that I've left out Kodi entirely and Emulationstation is now the main frontend, so this might not be suitable for you. If all you need is tvheadend you should be able to run that through Docker though.

You can have anything you like in a container.

Lisko

Screen is available as an addon. You can also run your scraper in the background like this:

# scraper -foo -bar > /tmp/scraper.log 2>&1 &

5schatten

I haven't done anything else since with Steam other than the initial testing so don't know if the image still works.

Personally I think tinkering should be encouraged, but on the RPi3 at least the end result was definitely not worth it. It was way too slow.

Running Xorg on Raspberry Pi through Docker

Quote from C0NPAQ

Are you really sure that this "docker solution" is actually working? Who did it actually, where is the evidence?

I did it 3 years ago, here's the "evidence": Running Xorg on Raspberry Pi through Docker

Why wouldn't it work? You can basically run anything in Docker.

No, there's no hardware support for either of those.

I am currently working on a LE9 / Lakka "remix" version for the XU3/XU4. I have a working image with RetroArch and the following libretro cores integrated: dosbox_svn, fbalpha, mame2003_plus, mame2016, mednafen_saturn, mgba, mupen64plus, nestopia, pcsx_rearmed, ppsspp, reicast, snes9x (all bleeding edge git). Anyone willing to do some testing for me?

Quote from 5schatten

You have to consider that escalades build was LE 8.2.x + Kodi 17.6 and mine is based on LE 9.x + Kodi 18.1 so they have not that much in common anymore. Also the question is if this fix isn't needed anymore why is it still in place?

There's tons of stuff still in place that isn't needed anymore

This specific hack has been around since the OE days, it got obsoleted after haswell generation managed to do 23.976 fps correctly.

Quote from rooty

It's done by

Code

# cat /flash/syslinux.cfg|grep APPEND
 APPEND boot=UUID=5C89-FBCB disk=UUID=16a7ebdb-fbf2-40e6-af03-a812e8cd0864  quiet pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier

Some related articles can be found here, and here .

Some mitigations were not disable because I didn't do microcode rollback, too much hassle I guess...

A note here, in case if discrete GPU is present, it's probably useless to spend time on this ^^, for LibreELEC purposes...

If you have an EFI system, the file should be /flash/EFI/BOOT/syslinux.cfg.

5schatten

As the N2/H2 isn't available at the moment and I decided that I don't need PCSX2 or Dolphin in my cabinet I've ordered the XU4 to play with. If I'm able to switch refresh rates it should be perfect.