Create /storage/.config/firmware/mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin and WIFI_RAM_CODE_MT7961_1.bin then reboot and the files will be overlaid on /usr/lib/firmware and used instead of the embedded files.
Please try the latest firmware files from: https://git.kernel.org/pub/scm/linux/…t/tree/mediatek
If those are not working, an issue needs to be reported to kernel maintainers. If they are we can bump the embedded firmware.
Start with an update to current LE13 nightlies which use a newer kernel - share dmesg again.
This is what Kodi announces over mDNS:
In theory the discover module should be automagically creating an Airplay sink based on the advertised properties (S16,44100,2-ch,etc.) and nothing more than this should be needed:
context.modules = [
{
name = libpipewire-module-raop-discover
args = { }
}
]What does the output from pactl list sinks show?
Spotted this in Google results: https://wiki.geekworm.com/NVMe_SSD_boot_…_Raspberry_Pi_5 which states "We recommend avoiding the following NVMe SSD drives which is equipped with a Phison controller due to their proven incompatibility:" .. and the Corsair MP600 is listed. However there are notes on the same page and posts in RPi forums that hint some devices are then working with after RPi firmware updates (and with updates from early 2024, which is some time ago now).
So three things to do:
Do one thing at a time so you can see what made the difference, should it start working. If it doesn't, I'll be pointing fingers at the Phison controller and suspecting not-all issues are resolved.
EDIT: Also share the URL from "dmesg | paste" so we can see if there's something in the system log.
There's nothing to change on the LE side because Kodi provides a working AirPlay target that devices can stream to - You proved that with the iPad mini. Ergo, if nothing happens (or wrong things happen) when you stream from the Arch device; something is wrong with the stream that you send.
It's not an LE problem but if you want us to guess at the issue I'd start by sharing the Arch discover.conf file so we can see what sink properties are being used. Plus a Kodi debug log that might show the inbound stream details (or not, I'm guessing).
Support for 24-bit and floating-point audio at up to 384,000hz
^ read from https://kodi.wiki/view/AudioEngine .. and visible here:
Patching that list to add a higher value would be simple, but I doubt things are that simple.
If you update to an LE13 nightly where the kernel is now on Linux 6.12, this patch (and others in the same series) is included:
[3/3] ASoC: spdif: extend supported rates to 768kHz - Patchwork
Run "pastekodi" with Kodi in debug mode again post-update.
In the older thread the "update from RPi" was a simple version bump to the MPD software used in the add-on, and that change was merged for all devices (back in 2021) and likely bumped to something more current a bunch of times since then. You can also see that we build mpd with WavPack support: https://github.com/LibreELEC/Libr…/package.mk#L91
Please run "lsusb -tvv | paste" and share the URL. This should list the USB devices and the drivers used - likely to be a generic USB audio device driver. I can then poke around in kernel code to see what max rates the driver supports (likely 384KHz).
LE 9.2.8 was released explicity to support RPi4 (Generic etc. stopped at LE 9.2.6) but "support" means the image boots/runs, it does not mean "all hardware features or RPi3 work on RPi4" and the LE 9.2.8 image will only boot on the original RPi4 hardware not newer iterations that need newer RPi firmware; although that can be fixed by copying files around. IIRC, even under LE 9.2.8 the RPi4 has never supported 3D because while many RPi4 chip features are intentionally similar/same to the RPi3, the GPU is different, and OMX etc. would need work to support it, which wasn't done for release (9.2.8 shipped the same day as RPi4 was unveiled) and then never happend once things moved to GBM/V4L2 etc. .. or something like that, I forget details now, this is some time ago!
Current LE12 or L13 nightlies will solve the issue (100% this is the newer chip needing newer mesa). LE 12.0.2 will be along soon-ish to roll up this issue.
"This only works for Home Assistant OS, running on Raspberry Pi. Not for Home Assistant Container."
^ simply means you cannot run the Pironman add-on container inside the HAOS container; because the Dockerfile for the add-on assumes a desktop OS is present, and the HAOS container is (like most containers) a stripped-down/minimal OS environment.
Adapting one of the existing Pi case GPIO fan-poking add-ons is probably the easiest option.
sparkplug have you added dtparam=pciex1 to /flash/config.txt?
I'm moderately confident the answer will be "the Linux drivers only support up to 384Khz" but please restart Kodi in debug mode, run "pastekodi" and share the URL so we can see audio properties and (hopefully) identify the kernel drivers being used.
LE runs Kodi without a desktop environment so the plumbing for e.g. Xorg/X11 graphics or Wayland are not needed and absent (minimalist distro and all that). The OutFox instructions look written for RaspiOS (Debian) which is more conventional and I don't see anything obvious in Google searching.
You probably need to reach out to someone on their forum or Discord chat. In short, you need to run OutFox under GLES on an OS with no desktop environment. This is sometimes described as "running on the framebuffer" although that's not technically correct these days - but might help people understand.
Docker won't help because the container cannot directly access graphics hardware to render anything.
USB SSD drive mounted for extra storage or NVME device attached to the PCIe connector you want to boot from?
Is the wifi chip supported at all?
The upstream device-trees for Amlogic reference boards describe a Broadcom WiFi module and your box probably has something else inside. QCA9377 would be my guess for an S912 box, but others are possible.
The "box" image here: https://chewitt.libreelec.tv/testing/ includes a patch that removes the Broadcom specifics to allow other WiFi modules to probe and work. If that's the case, please report back and share the log URL from "dmesg | paste" - You can wget the image to /storage/.update and reboot to udpate.
If that image doesn't work you'll need to share a log from the original Android kernel or other working Linux distro or share photo's of the board so we can understand what chip/module is inside.
For context, here's the patch (sent to kernel mailing lists this morning by random coincidence): https://patchwork.kernel.org/project/linux-…[email protected]/
