N2+ running CE 19.4 stable
- Play multichannel flac (Testfile 24Bit 96KHz 6 Channel)
- Play any regular flac (CD rip)
- Play again multichannel
- Play again regualar flac
- Play DTS audio file
- Play .dsf file
.
.
.
N2+ running CE 19.4 stable
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
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
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
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
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â
About | FAQ | Terms of Service | Privacy Policy | Legal Notice