Posts by fat-tony

    I had only tested PCM so far. But all PCM bitrates were fine up to 192kHz - but only in stereo, no multichannel. Interestingly, my SACD ISO test file with 2.0 and 5.1 layers had the track list displayed with each track appearing twice in the list - the stereo and multichannel version. Each track played back as 2.0 though. The same ISO played in Kodi 18 on CoreELEC just plays back as noise, so the SACD ISO filesystem support is much improved even if the PCM audio has not quite caught up yet. I'll test passthrough audio on my DD and DTS test files later.

    EDIT - passthrough audio in general plays ok, I tested DD+, DD TruHD, DTS-MA channel test videos and all were ok in audio, but video playback varied from working ok to blank screen or picture tearing or sparklies. None of my DVD ISO files worked (just displayed as folders with Video_TS files), but I think this is a known kodi 19 issue.

    chewitt - Finally resolved my booting issues on my N2+. It seems that my Sandisk Ultra 8GB microSD card is not liked by my odroid hardware! I am now using a Samsung 16GB microSD card and your latest builds are booting ok. However, my multichannel FLAC files are not playing back properly. Everything is playing as 2.0 PCM, although the sampling rates seem to be ok. Is this expected (and worked on) or do you need logs and/or sample high-res FLAC files for testing?

    Yes, I looked at the log. U-boot in my image is not suitable for direct launch in SD\eMMC mode for N2+. Need to build a different version of u-boot for your model. But I don't have an N2+ sample, so I'm sorry, I can't help you. The standard u-boot, which is in SPI, uses a clueless PITEBOOT that interferes with the direct execution of u-boot commands, so I doubt that you will be able to use my image in SPI mode (using boot.ini). For the N2 model (not plus), I created a special version of UbootSPI that allows you to run any system with USB \ SD\eMMC\LAN, but I think it will not work on N2+, need to create a special version for N2+.

    I discovered that part of my issues with booting LibreELEC on my N2+ were caused by a failure to boot my Sandisk Ultra 8GB microSD. Eventually, I started to use a Samsung 16GB microSD card. @chewitt's builds boot ok, but your builds still fail to boot on my N2+

    balbes150 - did you get a chance to look at the boot log in post #1,624 posted by cdu13a? I originally installed a chewitt build by mistake from a link in this topic, but subsequently tried one of your builds on my N2+ (not ordinary N2) which won't boot for me. I think your builds theoretically should be more likely to boot properly on the N2+ as they contain the boot.ini expected by the initial bootloader on the system.

    Thanks cdu13a - this is the image I downloaded and burned to an 8GB uSD card - LibreELEC-ARMv8.arm-9.80-devel-20201123124859-d174eba-odroid-n2.img.gz

    I edited extlinux.conf to point to the n2-plus dtb. Contents as follows:

    Code
    LABEL LibreELEC
      LINUX /KERNEL
      FDT /dtb/amlogic/meson-g12b-odroid-n2-plus.dtb
      APPEND boot=LABEL=LIBREELEC disk=LABEL=STORAGE quiet console=ttyAML0,115200n8 console=tty0 systemd.debug_shell=ttyAML0

    Powered off the N2+, removed the existing eMMC card, inserted the uSD card and ensured the switch was set to MMC position. My N2+ is connected to the TV through a Sony AVR.

    Powered the N2+. Nothing on-screen.

    I just can't get balbes150 N2 build (from Yandex folder) to boot on my N2+. I have burned the image to uSD and edited extlinux.conf to point to the /dtb/amlogic/meson-g12b-odroid-n2-plus.dtb for my N2+, but the image does not even start to load. It seems to be missing some essential component to allow the boot to proceed. I have the boot switch pointing to the right (MMC) and have removed my eMMC card.

    I'm testing the image with my new Odroid N2+. So far, so good. Most of my audio collection is ok, except for FLAC 5.0 and 3.0 files (all 2.0 and 5.1 files at various resolutions from 44.1kHz to 192kHz are ok). Even my SACD ISOs are mostly working. Very good for a "bleeding edge" build, thanks!

    The image I downloaded and configured dated from 12/11/20. I can't see a specific N2 update tar file in the Yandex folders. I tried the g12 tar but the update is looking for an AMLGX version which I can't see in the folder. Any specific date I should search for an update?

    edit - I think my problem is that I used chewitt image (from a link about 20 pages back) instead of the Yandex image :cry:

    Can someone confirm that I should use the N2 image from Yandex link on page 1 and then use the g12 tar to update ??

    I am getting crazy... Did a clean instal onto a new SD card and the result is same, surround mapped to the front.

    kszaq, could you help us?

    I must say that I'm not getting this problem at all on a Venz Pro10 (S905X). I ran all the usual DD, DD+, DTS, AAC, TruHD videos and they play back correctly with all the correct channel placings. AAC is converted to PCM as usual (my AV amp, like many, does not support raw AAC). My multichannel FLAC (PCM) audio files are output correctly also. Would this be an issue with the conversion from DD variants to PCM in your case? I use passthrough for all the high-res audio formats as my amp supports them.

    edit - just saw your second post. You seem to be using some kind of pseudo or auto surround mode on your AV amp.

    Shut :|

    At this point I don't know where is the problem.

    Any suggestion? Thanks.

    .dsf files play ok on my S905X box. Is there a particular reason why you are storing .dsf files in the first instance? Most PC-based or AML media players need to convert the DSD stream to PCM for transport across the HDMI connection to the AV amplifier. Why not convert the .dsf file to PCM offline and store it as .flac?

    I have about 100 SACDs and have them ripped to .iso images using an old PS3. I do have a Sony Blu-Ray player and Sony AV amp which will handle bitstreamed DSD data, so I can actually play the raw DSD data stored on my NAS (as .dsf files) using either the amp or the Blu-Ray. However, any other media player will require to convert the DSD to PCM on-the-fly. Kodi (on the S905x anyway), seems to transcode the data to 192kHz PCM. This is not a usual or recommended sampling rate for DSD as 176kHz or 88.2kHz is recommended for best results.

    To be honest, I can't detect (with my old ears and quality of kit) any playback difference between the raw DSD stream and the pre-converted 88.2kHz PCM data or the 192kHz on-the fly PCM data from Kodi. :-/

    The advantage I find with pre-converting the DSD data to 88.2kHz flac files for storage on my NAS is that I can tag them easily using standard tagging tools and that I can download them directly to my phone or other mobile devices for mobile playback without any further processing.

    If you're using high-end playback gear there's probably a case for storing the .dsf files, but Kodi is going to transcode them, so you would need another means for playing them if you wanted the native DSD sent to your amp. In my case, the method for playing .dsf over the network on the Sony is only via DLNA and that's a very unsatisfactory method as I don't see the tagged data properly. The sound is good but the interface is rubbish!

    [hr]


    Fat Tony,

    That is the only issue with the s905x. Should have charged 50 instead of 40. For the clip that you just couldn't get enough bandwidth for, I have something to try. Have you tried mounting the NAS so the OS handles the network stuff, instead of Kodi. I had a lot of troubles with my box and larger files. But it was always almost enough, so I would keep struggling with it. Haven't had a single stutter since and I play some huge files. I wish I had done it months ago when it was suggested.

    R4w has been suggesting this and I wish I'd listened sooner. It's a mount command like here:

    Mounting network shares - OpenELEC

    If you have tried this and it's too basic for you, apologies.
    [hr]
    8.0.1j seems to have everything perfect with my box as well. Smooth as butter playback in all rates, audio files, and dts-hd trueHD. I have to keep testing but you've really made this box a winner kszaq, Thank You!


    Thanks for the suggestion but I'm not sure that this would resolve the issue for me. I'm familiar with mounting network shares locally as I do it on another machine but this particular clip (jellyfish) is 528MB in size and is 30 seconds long. This works out at a sustained data rate of 17MB/s which is way in excess of what a 100Mb/s ethernet connection can handle. Typically you might get 10 - 12 MB/s max. I don't know if the jellyfish clip is typical of HDR samples or if it's not compressed properly, but a one hour version of the file would be 60GB in size. This would take about 90 minutes (rough calculation) to download, so you would have to buffer probably 30 minutes before starting to play the file to ensure you didn't "catch up" with the buffer. I have a couple of other 4K VP9 encoded samples which require sustained data rates of about 5 - 6 MB/s which is comfortably handled by 100mb/s ethernet. It's just this particular test clip that won't play for me. I don't yet have a 4k TV, so my interest is mainly in "future-proofing" but the downscaled output on my 1920x1080 TV is pretty stunning, nevertheless. Just like HD TV was when it came out about 10 years ago, before the broadcasters started reducing the bit rates :(
    Perhaps your file data rates are just marginally in excess of your network speed so that you don't have to buffer quite so much?

    kszaq - the 8.0.1j build is working great for me on both my S905 (Tronsmart) and S905X (Venz V10 Pro) boxes.

    All my stereo and multichannel PCM audio files play back properly at the correct sampling rate (44.1, 48, 88.2, 176.4 and 192kHz).
    All of the HD proprietary audio formats from DTS and Dolby play back correctly, including Dolby True HD which was causing me an issue before.
    Suspend seems to work fine on both boxes also.
    The S905X box is limited by its 100Mb/s ethernet connection, though - it is not able to pull data fast enough from my NAS to play the "jellyfish" UHD sample video, whereas the S905 box with its 1Gb/s ethernet plays it without difficulty. Running a monitor on my NAS shows the S905 pulling 22MB/s (176Mb/s) when playing that particular sample, so you definitely need Gb LAN or fast wifi. The S905X plays the file perfectly from USB and it has the advantage of supporting VP9. Pity they skimped on the ethernet!

    Many thanks for all your efforts.

    Guys - anyone else having issues with Dolby TruHD playback? I have various test files which include all the usual HD audio formats including DTS variations including Master Audio and the Dolby variants including Dolby EX and TruHD. All are playing back via passthrough to my Sony DN1060 AV amp except Dolby TruHD which is silent. If I set my amp as incapable of TruHD, then Kodi resamples to multichannel PCM, so it's recognising the format but somehow is not passing it through. My amp is certified for DolbyHD playback and it works on another LibreELEC install on an x86 motherboard.

    Snip from my logfile below:


    Thank you everybody for testing and reporting on development build.

    I ask once again: for any playback-related issues you have to post a link to a sample that I can reproduce the issue with.

    I have posted 8.0.1f build in OP with some fixes and improvements. As always, I hope there won't be many regressions - if any. I also hope there are no derps in the build - you have to understand that I develop during sleeplessness periods and have no time to test my builds. :)

    kszaq - many thanks! I saw your comment on github audio thread and checked back here to see your new build.
    I've done some testing on my audio collection using my S905X box. All bitrates (44.1, 88.2, 96, 176.4 and 192kHz) both stereo and multichannel are playing back at their native rates through HDMI to my AV amp. These are all FLAC files which are played as PCM to the AV amp. All sound excellent, although I noticed one instance of "ticking" (at very low volume) through the rear speakers on one particular track which didn't happen on a second play. I may spend some time looking at logs later today to see if there is anything odd.
    I did some limited DD and DTS passthrough testing from some music videos which seem to be ok also. I may get some time later to check some HD video testfiles.

    Money for coffee sent :)