CoreELEC 19.4-Matrix Discussion

N2+ running CE 19.4 stable

  1. Play multichannel flac (Testfile 24Bit 96KHz 6 Channel)
  2. Play any regular flac (CD rip)
  3. Play again multichannel
  4. Play again regualar flac
  5. Play DTS audio file
  6. Play .dsf file
    .
    .
    .

The USB issues are caused by the fact that my N2+ has a “fried” USB3 controller since new. I don’t use the USB3 ports on the box. I just the USB2 OTG port on the front for the RF remote. I use the 7.1 Mch PCM HDMI output in Kodi as always. I have been using the same FLAC files for years, first in LE and now since CE got multichannel PCM working on the N2. The files work perfectly in 9.2.8, so I think it’s something to do with the audio driver or configuration as it seems to enumerate the ALSA devices three times ar startup in 19.4. Both logs are from clean boots.

Thanks for confirming that you can play 24 bit 96kHz 6 channel file followed by regular CD rip on 19.4 stable. There must be some issue on my setup between my N2+ and my Sony DN1060 AVR which is different between 19.4 build and 9.2.8. It’s very strange. On the 19.4 build I can see the AVR reporting “2.0 44.1kHz” format messages every time I press the BACK key on my remote. It’s as if there is some audio format change happening all the time. I have no issues at all with the 9.2.8 EOL build.

I don´t know about Sony AVR.
My setup is N2+ connected to my Denon AVR-X3300 via HDMI cable

1 Like

Can I ask if I can suppress checking of the USB3 controller? It’s definitely not working as it was one of the earlier N2+ boxes which blew up the controller due to USB power issues.

Also, why do I see a Bluetooth device (Pulseaudio) detected at startup? There is no Bluetooth or WiFi on the N2, unless you use a USB dongle.

Enumerated PULSE devices:
2022-03-08 19:02:21.091 T:5359 INFO : Device 1
2022-03-08 19:02:21.091 T:5359 INFO : m_deviceName : Default
2022-03-08 19:02:21.091 T:5359 INFO : m_displayName : Default
2022-03-08 19:02:21.091 T:5359 INFO : m_displayNameExtra: Bluetooth Audio (PULSEAUDIO)
2022-03-08 19:02:21.091 T:5359 INFO : m_deviceType : AE_DEVTYPE_PCM
2022-03-08 19:02:21.091 T:5359 INFO : m_channels : FL, FR
2022-03-08 19:02:21.091 T:5359 INFO : m_sampleRates : 5512,8000,11025,16000,22050,32000,44100,48000,64000,88200,96000,176400,192000,384000
2022-03-08 19:02:21.091 T:5359 INFO : m_dataFormats : AE_FMT_U8,AE_FMT_S16NE,AE_FMT_S24NE3,AE_FMT_S24NE4,AE_FMT_S32NE,AE_FMT_FLOAT

  1. Check with this dtb.img: 70.5 KB file on MEGA

  2. Pulse is always enabled regardless of the BT device.

Many thanks for specialised no-USB3 DTB. It will an hour or two before I can test as grandchildren are here and I’m cooking dinner!

Thanks, that booted ok, with no USB3 errors showing. Did you have to generate that specially, or did you have one “ready”?

I burned a Nexus image to SD card and tried that also. Same issue with 2.0 sound after playing 5.1 It may be due to some weird interaction between the newer kernel/ffmpeg and the switching of sampling rates with my AVR, perhaps? If I fix the sampling rate at (say) 192kHz, then I don’t have an issue switching between 5.1 and 2.0 sound. If I go back to 9.2.8 then I don’t have an issue with varying sample rates on 5.1 and 2.0. All very strange!

I made it. Luckily it booted. If not we would be in big trouble :slight_smile:

Can you upload 2 samples for 2.0 and 5.1?
And try same on CoreELEC 19.3 because with 19.4 new linux kernel was used.

It booted ok. I had renamed the old DTB, so it was no difficulty in going back. However, is it possible that my remote (IR) would stop working? The remote (from VenzV10) has IR and RF, so I was able to use RF on your DTB. I switched back to the standard DTB and the IR was working again. I plan to re-test with your DTB again this morning. I think the sound issue is with the new kernel as the ALSA enumeration happens three times at startup in 19.5, whereas it only happens once in 19.3. I really don’t think my FLAC rips are at fault as I’ve been using them on various S905 devices for years with LibreELEC and CoreELEC and on the N2+ since July 2020 on 19.3

Try with this dtb if there is a change with remote: 70.7 KB file on MEGA

Apologies - my mistake! It’s the RF dongle (detected as a keyboard AUTAXIN) that’s not being detected (in either of your DTB versions). The IR setting on the remote is working on both versions. The USB RF dongle is plugged into an OTG cable connected to the front micro-USB port.

lsusb on standard DTB

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0a45:0004 AUTAXIN AUTAXIN Wireless Device
Bus 001 Device 008: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lsusb on your DTB

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I have done some more testing and found that the issue was introduced in 19.4-rc2 (rc1 works), I tried bisecting the issue but it ended with several candidates that didn’t build due to undefined references in the kernel. I also built the latest coreelec-20 branch but it has the same issue.

Can you see from the NFS server what files has been fetched during boot?

There doesn’t seem to be any NFS file access in the failing case, with rc1 it mounts the folder containing the “SYSTEM” image and then the home directory.

I just tried setting “panic=0” as boot parameter and seems to stop it from rebooting but I’m still not getting any video output, just a black screen.

Try to revert this commit in kernel:

Or just set

static int auto_negotiation_en = 1;

Maybe this is the reason the kernel doesn’t get network up soon enough.

If this would work you can also try without reverting commit or variable change and only with this patch

Thanks vpeter,

Unfortunately it didn’t help, I tried changing “auto_negotiation_en” and also your patch but it still just reboots.

That’s sad. I didn’t saw any other change which could affect this.

I tested your 2.0 and 5.1 files with Multi Channel PCM HDMI set. No problem here.
You might try to set “keep audio active” as it’s disabled by default. This behavior changed from new kernel. Set it to infinitive or minimum 1 minute.

Thanks for looking at the issue @Portisch . I have used the “keep audio active” setting during my testing, but it makes no difference. I even tried a LibreELEC 19.4 build (with 5.x kernel) on my old model 2 B Raspberry Pi and it worked perfectly for multichannel and 2.0 audio, so I think the problem is not with Kodi.

The only difference I can see in the logs between 19.3 and 19.4 is the introduction of spdif codec setting. What is this used for in the context of a HDMI output? I can only think that this is causing an effect with my Sony DN1060 AVR which is not affecting other AVRs. See below:

2022-03-08 19:03:47.058 T:5360 INFO : CActiveAESink::OpenSink - initialize sink
2022-03-08 19:03:47.258 T:5360 DEBUG : CActiveAESink::OpenSink - trying to open device ALSA:surround71:CARD=AMLAUGESOUND,DEV=0
2022-03-08 19:03:47.258 T:5360 INFO : CAESinkALSA::Initialize - Configure simple control for “AUGESOUND”
2022-03-08 19:03:47.259 T:5360 INFO : CAESinkALSA - Use card “hw:0” and set codec format “2 CH PCM”
2022-03-08 19:03:47.260 T:5360 INFO : CAESinkALSA - Set codec for “Audio spdif format”
2022-03-08 19:03:47.260 T:5360 INFO : CAESinkALSA - Set codec for “Audio spdif_b format”
> 2022-03-08 19:03:47.260 T:5360 INFO : CAESinkALSA - Set Spdif to HDMITX to “Spdif”
2022-03-08 19:03:47.260 T:5360 INFO : CAESinkALSA::Initialize - Attempting to open device “surround71:CARD=AMLAUGESOUND,DEV=0”
2022-03-08 19:03:47.266 T:5360 INFO : CAESinkALSA::Initialize - Opened device “surround71:CARD=AMLAUGESOUND,DEV=0”