Ah. OK. Yep passthrough via PULSE know works. Thx.
Update: RA starts up and has audio. ES and FF are not starting up properly and seem to hang somehere (Sway background is visible). Are there any PA related settings I need to adapt or remove ?
N64: Still some crackling sound with Doom64, while F-Zero X and Mortal Combat4 seem ok. So, not a general problem, it seems.
There should be no difference where the decoding is done, as long as all information is extracted (which I believe it is at this point). There is no remixing done by Kodi/PA if the sink supports the sampling format (avoid-resampling=true is set in /etc/pulse/daemon.conf).
The standards typically specify the bitstream format but not necessarily any further post-processing. So, if the receiver knows which compressed content it is dealing with, it should do a better job compared handling 'unknown' PCM. But, anyway. PT works. Thx !
As mentioned, you need to tell PA what pass-through formats are supported using the command I gave you.
Ah. OK. Yep passthrough via PULSE know works. Thx.
Also set "keep audio device alive" to off and "send low volume noise" to off. If you have previously set the PA sink as your audio device in Kodi, it might get locked before ALSA becomes available. Of course you can turn on all these things if you set PULSE. Passthrough is working great, except for HD audio of course which isn't quite ready yet AFAIK. In any case, ALSA/ALSA+PULSE/PULSE all work here in the latest image.
I think there is too much obsession over passthrough, there isn't any loss when decoding to PCM.
When configuring Kodi to use PULSE, all passthrough settings are disabled and my receiver claims to be receiving PCM. In ALSA mode, this works fine. So, I'll just stick with ALSA.
Wrt\ to 'obsession'. I would assume that my Yahama receiver does a better job in the decoding, conditioning and up/down-mixing the audio stream for my speaker setup. But, yeah, at some point it might become a question of 'believe' 
I think you misunderstand. Vsync is great if your screens refresh matches your content. If it doesn't, RetroArch will try to adjust the speed of the audio to compensate. Like I said, try some other systems. Make sure your screen is 60Hz and video framerate in RA settings matches, then use NTSC roms for best results. Unless you know the PAL versions are 60Hz compatible. For Amiga/C64/Spectrum you can/should use PAL versions, as I've set up PAL switching for those.
I tried it with Doom64 for N64 - supposedly the US version, hoping that this would be an NTSC ROM. I didn't get to dig into this deeper, yet.
You need to restart Kodi after changing KODI_AE_SINK.
Yep, I did.
You are aware that there's no audio (not in the included theme anyways) except for video previews right?
Oh. No menu sounds ? OK, my mistake. Sorry. I thought I've an ES with menu sounds somewhere...
Doom 1? Doom 3? I suppose the latter, and 50FPS sounds to me like vsync with 50Hz refresh rate. That'll probably mess up sound as RA adjusts accordingly. I haven't tested the dhewm3 core myself, could you try some other core please, and provide logs
VSync was the default. No good ? Will try different core over the weekend an report back.
I found the issue, the extensions required was in module-device-restore which I removed while trimming down the system.pa config file.
It should be fixed now in the latest image, try again. Further adjusted PA to fit in with LibreELEC paths, it will now store persistent device/stream configuration in /storage/.cache/pulse instead of under /var which is tmpfs.
Nice. Will try that out over the weekend. Thx.
Do you mind testing the latest? I think I've got it right this time. Pulseaudio behaves differently with regards to it's runtime dir when in system mode like in LE, and the upstream package hasn't gotten much attention since the OpenELEC days.
Execute rm -rf /storage/.config/pulse* before rebooting. I've tested thoroughly Kodi/ES/RA and pacmd/pactl, everything seems to be in order. As a bonus I've set KODI_AE_SINK=ALSA+PULSE which gives you the ability to connect bluetooth speakers through PA, and added the zeroconf-discover module which automatically detects other PA installations on your network. They will show up in Kodi automagically
I've tested passthrough in PA and it seems to work great actually. If you want to try full PA setup, add KODI_AE_SINK=PULSE to /storage/.config/kodi.conf and run pactl set-sink-formats $(pactl list sinks short | grep -v NON-DEFAULT | awk '{print $1}') "pcm; ac3-iec61937; dts-iec61937; eac3-iec61937". This will give you DTS/AC3/EAC3 passtrough with PA
Kodi: In ALSA+PULSE mode, I do get audio via ALSA/HDMI#0. If I choose PULSE, there's no audio. If I then switch back to ALSA, there's still no audio. After a reboot, audio via ALSA works (maybe restarting kodi would be sufficient - I can test if you like).
ES: no audio
RA: Audio works, but still crackling. Yes, it could be due to my not so powerful setup. But, we are talking about 'Doom' here, first level, not moving. FPS is between 49.9 and 50.04.
Full PA: Your shell command fails:
cinemax:~ # pactl set-sink-formats $(pactl list sinks short | grep -v NON-DEFAULT | awk '{print $1}') "pcm; ac3-iec61937; dts-iec61937; eac3-iec61937"
Failure: No such extension
cinemax:~ # pactl list sinks short | grep -v NON-DEFAULT | awk '{print $1}'
1
cinemax:~ # pactl list sinks short
1 alsa_output.pci-0000_00_0e.0.hdmi-stereo module-alsa-card.c s16le 2ch 44100Hz SUSPENDED unmuted 100% DEFAULT
Nevertheless, I get audio in Kodi ! There are no options to enable or configure passthrough in the audio menu (Expert mode).
Kodi claims to be in passthrough mode. My receiver shows its seeing PCM.
Thx again for all the time you spend on this.
Installed. Kodi works incl. passthrough. No audio in ES. RA (n64) works. Audio is there but crackling.
Display MoreIt's not required per se, but on some platforms I had to use Pulseaudio in order to get sound working in Emulationstation's video previews, also there used to be an issue back when youtube used flash plugin to output sound as the browser itself had locked the device and the plugin tried to acquire it. There will always be corner cases where you need to mix two streams together, and there's just no reason not to use Pulseaudio. ALSA has dmix as well available as /storage/.config/asound.conf.dmix , but according to my testing Pulseaudio's resampler is superior both quality and performance wise.
Here's my other reasons for using it:
- Automatic detection of the active output (mine is hw:0,3)
- A2DP audio streaming
- All apps including containers can simply point to it and have sound on the correct output
Technically, it supports passthrough of HD audio as of 13.0 but Kodi being 5 years behind on technology as usual (no HDR yet lol) it's not supported yet at least not in Leia AFAIK.
My launcher scripts lets you force ALSA if you wish, just prefix the commands with ALSA=1 in es_systems.cfg and you should be good to go (that'll use pasuspender to launch RA too though, so Pulseaudio will still be running after exit due to the current issue). The reason for you not having sound when you stop Pulseaudio is probably because the correct output is not set in asound.conf. ALSA needs to be configured for the right output, I try to detect this (by using Pulseaudio) with alsa-config.sh and output it to /storage/.config/asound.conf.hw which is symlinked to asound.conf. Have a look at it, it's not fail proof.
I used to have ALSA as a default, but then I was flooded with "no sound" reports due to improperly set up asound.conf (before I created alsa-config.sh). Either way you look at it, it's hard to have sound working automagically on all platforms and across all applications. I choose Pulseaudio because I feel it's the right way forward and when it does work it works beautifully.
Back to the issue at hand, it seems like pasuspender doesn't unsuspend the sink. This was working, I suspect an issue with glibc 2.31. I see that pactl list ends in a segmentation fault as well. A quick fix is to add a custom kodi.service with this line added:
ExecStopPost=/usr/bin/pactl suspend-sink @DEFAULT_SINK@ 0
I can reproduce, so I will get this fixed. I know my quality control is poor at times due to lack of time. I don't keep an archive of images either as my gdrive gets filled up. I'll try to get it solved after work + build time for all platforms
Thanks for sharing your thoughts here. I had imagined that dmix would be sufficient to handle concurrent PCM audio sources, while passthrough only works with one active source, anyways. But, I see your point about configuring ALSA properly. I know ALSA from the beginning and it never seemed straight forward to me - unless you invented it 
I'm OK with Pulse, it just seemed to cause quite some trouble. But, yeah, as you say, without it's maybe even worse...
I'll play around with ALSA1=1 when I get some time.
I know this all consumes a lot of spare time. Thanks for working on this. I'll try to help testing and bug hunting, where possible.
New generic image uploaded with 5.6.0-rc1 kernel and glibc 2.31.
Updated to this image. kodi works incl. passthrough. Firefox and RetroArch seem to have issues with audio.
FF behaves like its still waiting for the audio/video stream to arrive, but I believe its rather waiting or the audio device to become available.
RA starts up. black screen, says 'controller dectected...' and freezes. strace shows it looping around a nano_sleep - most likely also waiting for the audio device ? pulse ?
if I kill pulse before starting FF, then FF behaves normally, but there's no audio coming out....
I assume this was discussed before. If so, please excuse my ignorance. why is pulse actually required for a kioks-like setup such as RetroArch.
There's only one active Application, and, I'm sure they all can natively speak ALSA, no ?
Aha! Nicely spotted, I’ll upload Fixed images asap. Until then you could copy kodi.sh to /storage modify it and add custom kodi.service to /storage/.config/system.d.
EDIT: fixed generic image uploaded.
Yep. Kodi is happy. Thx !
I will be offline a couple of days can't look closely now but it's very unexpected behaviour. Kodi in my image runs with ALSA through the
KODI_AE_SINK=ALSA variable which is set in the systemd unit file (confirm it by excecuting systemctl cat kodi). The binary kodi.bin is started through pasuspender which suspends Pulseaudio until the process exits. You shouldn't be getting any sound from setting Pulseaudio in system settings, and there should be no need to stop Pulseaudio as it's already suspended. I'll have a look at your logs later though, thanks for the feedback.
yep:
cinemax:~ # systemctl cat kodi
# /usr/lib/systemd/system/kodi.service
[Unit]
Description=Kodi Media Center
Wants=kodi.target
Conflicts=weston.service sway.service xorg.service emulationstation.service
After=weston.service sway.service xorg.service emulationstation.service
[Service]
Environment=KODI_AE_SINK=ALSA
Environment=__GL_YIELD=USLEEP
Environment=HOME=/storage
Environment=KODI_TEMP=/storage/.kodi/temp
Environment=KODI_HOME=/usr/share/kodi/
EnvironmentFile=-/run/libreelec/kodi.conf
EnvironmentFile=-/run/libreelec/debug/kodi.conf
ExecStartPre=-/usr/lib/kodi/kodi-config
ExecStart=/usr/lib/kodi/kodi.sh --standalone -fs $KODI_ARGS $KODI_DEBUG
ExecStopPost=-/usr/lib/kodi/kodi-safe-mode
TimeoutStopSec=10
Restart=always
RestartSec=2
StartLimitInterval=0
LimitNOFILE=16384
TTYPath=/dev/tty1
note the lower case here (in /usr/lib/kodi/kodi.sh):
if [ "$KODI_AE_SINK" = "alsa" ]; then
I think changing cpu governor to performance is worth a try, look at /etc/profile.d/99-oem.conf and find the commands there I’m not in front of my laptop atm. Good to hear browser is working the latest rpi2 build runs it in wayland no xwayland.
Thats weird can you try a clean install? Kodi is set up to use alsa in this image, pulseaudio is disabled while kodi runs. You should be able to select the correct output and get sound. Anything else should use pulseaudio which detects the active output by default. If that should fail you can use pactl.
I did this morning. Same thing, I can only get audio out of Kodi if I select 'Pulse Server'...
'pactl exit' fails due to "Access denied"
Update: killing the pulse daemon and restarting Kodi works. Now, I can select HDMI #0 and passthrough works.
New Generic/RPi4 image out:
- updated transmission to latest git and linked against system ca certificates, extended sysctl values for maximum performance
- more font polish, if anyone has issues with fonts run fontconfig-setup.sh in a terminal
- added wireguard from upstream LE, updated modules to v0.0.20200205
- libretro core updates
- unified firefox.sh into a common script for arm/x86_64 (arm will use Xwayland by default), now runs native for all images (x86_64 uses official binaries, arm uses ubuntu 19.10.1 binaries)
- adjusted plymouth boot splash to exit on common update failures to see what's going on
Too bad, unfortunately in my experience the low-end Intel GPU's like those in your Braswell tend to have less focus by the dev team. Hard to say where the bug is though, could be in the kernel driver, Mesa, Firefox or in Sway/wlroots. Could even be caused by LTO for all I know, but it seems to work fine both on my NUC8 and my older Haswell NUC. Can you reproduce at all, or is it very random?
I don't have the OGST case myself, and I consider it quite the useless gimmick. AFAIK all you need is ffmpeg and the TFT kernel driver though, which is included in this build. If a kernel or ffmpeg config option is missing I could include it. You can add your own launch scripts through /storage/.config/emu_start.sh and emu_stop.sh.
OK, change of plans. I've upgraded my ITX mainboard to a new model with a Pentium J5005 CPU/SoC which features an Intel 605 GPU.
And, so far, FF seems to run fine. No GPU hangs, yet (let's hope it stays that way
Now, there an issue with Passthrough and Kodi (and also no audio in ES).
In Kodi, I need to choose Pulse to get any audio output. With the old system, I had chosen HDMI#2 - which also showed my Receiver/TV as connected to this port. For 'Passthrough' I had selected the same port and enabled all codecs for Passthrough. And all was good.
Now, I can selected any listed audio device but there's no audio in Passthrough mode - only in non-passthrough / PCM.
In ES, there is no audio, at all. No matter which of the listed (ALSA ?) device I choose.
I'm on the latest image and even did a 'factory reset'.
Too bad, unfortunately in my experience the low-end Intel GPU's like those in your Braswell tend to have less focus by the dev team. Hard to say where the bug is though, could be in the kernel driver, Mesa, Firefox or in Sway/wlroots. Could even be caused by LTO for all I know, but it seems to work fine both on my NUC8 and my older Haswell NUC. Can you reproduce at all, or is it very random?
I don't have the OGST case myself, and I consider it quite the useless gimmick. AFAIK all you need is ffmpeg and the TFT kernel driver though, which is included in this build. If a kernel or ffmpeg config option is missing I could include it. You can add your own launch scripts through /storage/.config/emu_start.sh and emu_stop.sh.
Well, the box is now 4 years old and it's a good match for my even older Full-HD plasma TV Once I can make up my mind what new TV to get, I'll also upgrade the the motherboard. So, it's good to know that it works with your NUCs.
In principal FF works fine, there are no rendering issues, etc. Just on multimedia-heavy websites (i.e youtube, ifun.tv), this 'GPU hang' happens from time to time. Sometimes FF crashes after a few seconds, sometime it continues to then eventually crash at some point. It does not (did not so far) happen when you enter a website and wait for it to load completely (without scrolling, etc). Heavy srolling, etc. is what triggers it. Oh, and once while watching a video.
I guess, for now, I keep updating when you have new releases. Maybe it gets fixes along the way. I really felt that the -rc6 kernel based image did not have those problems - but maybe I was just lucky.
Anyway, thanks for looking into it !
Fixed in the latest image.
Yep. Firefox starts up fine now. I'm still/again seeing those 'GPU HANG in sway' errors when browsing media-rich websites...Sometimes it happens quickly, sometimes it takes a while. So, I wonder if it ever worked properly, or if I was just lucky sometimes.
latest image: firefox.sh not executable:
-rw-r--r-- 1 root root 394 Feb 4 15:29 /usr/bin/firefox.sh
The latest image under the «test» folder has integrated Firefox 72.0.2 using official binaries, now running natively on LibreELEC / Wayland. The image has crossed over 512MB though so can only be updated to for those who installed LE with my images which have 1024 MB /flash. Works terrific
Some other improvements are fine tuned fontconfig setup with beautiful sub pixeled rendered DejaVu truetype for all GUI apps i.e. Firefox, RPCS3 and PCSX2. I’ve also added Thai fonts (ttlwg).
So far, so good !!! Will do more testing over the weekend and report back. Thanks for looking into it.
I don't configure Firefox at all, it's the upstream Arch package. I updated the container today, go ahead and run the following:
# docker pull escalade1/arch-browser
# docker pull escalade1/arch-pcsx2
The containers run entirely separate from the LibreELEC userland, so has it's own Mesa etc. I should probably redo the launcher scripts to pull the latest container on startup.
The best thing would be to compile Firefox with the LE toolchain, but that would require way too much work to set up and maintain.
Just did. Problem persists 
Checking the upcoming Linux kernel 5.5.1 patch: Nothing related to DRM.
Would you still have the 5.5-rc6-based image around ? I could try again if FF really worked flawlessly - maybe I was just lucky.
