RuneAudio 0.6-beta for most Raspberry Pi models

[janui]

Current build version: janui-20231210-4

Way back in 2018 we published RuneAudio 0.5b. In the meantime, lots has happened, Rern has developed his own version, and we continued plugging away at the Classic RuneAudio version. The 0.6b version was nearly published several times, but we were repeatedly caught out by some sort of technical change which caused delays. We now have something stable which we would like to share with you.

RuneAudio 0.6b will run on all Raspberry Pi hardware types, except the new Pi 5B. There are now two versions:
• A RPiOS-bullseye 32-bit version which will run on all Raspberry Pi hardware, except the Pi 5B.
• An ARCH-aarch64 64-bit version which will run on the Pi 3A+, 3B+, 4B & Zero 2W hardware.

There are some differences between the images, but they are functionally the same. Some features are disabled when the RPiOS version is used on the slower single processor models.

We are still making small improvements to the images. After setting up your installation you can use the git pull function in the /dev UI to upgrade to the latest version. For instructions see here: http://www.runeaudio.com/documentation/ ... rd-updates. The current build version is mentioned in the first line of this post. Your current version van be seen in the Debug UI, Build version: janui-20231210-x.

Here is the changelog for 0.5b > 0.6b: https://raw.githubusercontent.com/gearh ... b_0.6b.txt
Here is the issue list concerning 0.6b: https://raw.githubusercontent.com/gearh ... t_0.6b.txt

Messages concerning bugs, issues, problems, and all other comments are all welcome. Please use the forum.

We are currently testing a version for the Raspberry Pi 5B, this will be available early in the new year.

Have fun,
janui & Gearhead


Here are the download links and SHA-256 hashes:

RPiOS-bullseye 32bit for all Raspberry Pi hardware, except the Pi 5B:
Download link: https://www.mediafire.com/file/gqefpesk ... mg.xz/file
Filename: 20231210_runeaudio_rpiALL_b.img.xz
Download size: 841,701kB
SHA-256 of the xz: 1A965CA8B97700C206D32E01CCBA473CB4D1C84261823A5040DA3F639AC99D9B
SHA-256 of the img: FE19D4A35351B98F577219A710A3FE9A2041A5F7A5E54E4870B1133ACC0A31BC

ARM ARCH aarch64 64bit for the Raspberry Pi 3A+, 3B+, 4B & Zero 2W hardware:
Download link: https://www.mediafire.com/file/7asixxkk ... mg.xz/file
Filename: 20231210_runeaudio_rpi64_b.img.xz
Download size: 746,001kB
SHA-256 of the xz: DBE0A340A07DFA220AD8B21BD63F03CF4F6D6178265CE79F9BF500C5C6762829
SHA-256 of the img: 6F1EB633CAFDFE6C1BD0637F88867115BC28A1F28281D9629E4BB6A87BC8F168

The images are now designed to fit on a 8Gb Micro-SD card.
The first boot of the image takes quite a while, it can take 5 minutes on the single processor hardware, have patience.

[Beelzebassie]

Exciting!

Just tried some audio files (primarily FLAC and DFF), but all bitrates except for 16/44.1 play with hick-ups/stutter at the start.
Tried raising the "audio buffer size" to 16384 to no avail.

Pi 3B, aarch64 64bit, Allo Digione

[RoyB]

Great!

Thanks janui and Gearhead for your effort!

The hickup/dropouts at the beginning of tracks are, according to me, related to (flac) files with a bitdepth of 24.



Raspberry Pi2 - Allo Digione

[janui]

Hi Beelzebassie (and RoyB),

Thanks for the feedback. First could you confirm that MPD is not updating its database when the problem occurs. RuneAudio reports 'Updating' with a rotating arrow at the bottom left of the UI when it is updating.

If that is not the case, could you log into the CLI and edit the file '/etc/mpd.conf'. Look for a section which looks something like this, where name refers to the Allo DigiOne or maybe 'WM8805':

Code: Select all

audio_output {
        name            "snd_rpi_hifiberry_amp"
        type            "alsa"
        device          "hw:1,0"
        mixer_control   "Master"
        mixer_type      "hardware"
        mixer_device    "hw:1"
        auto_resample   "no"
        auto_format     "no"
        enabled         "yes"
}

Then change it to include an extra line:

Code: Select all

        allowed_formats "*:16:* *:24:*"

So that it would look like this when using the example above:

Code: Select all

audio_output {
        name            "snd_rpi_hifiberry_amp"
        type            "alsa"
        device          "hw:1,0"
        mixer_control   "Master"
        mixer_type      "hardware"
        mixer_device    "hw:1"
        allowed_formats "*:16:* *:24:*"
        auto_resample   "no"
        auto_format     "no"
        enabled         "yes"
}

Then restart MPD:

Code: Select all

systemctl restart mpd

Then retest.
If this fails to improve things, then try replacing the same line with:

Code: Select all

        allowed_formats "32000:16:2 44100:16:2 48000:16:2 88200:16:2 96000:16:2 192000:16:2 32000:24:2 44100:24:2 48000:24:2 88200:24:2 96000:24:2 192000:24:2"

Then restart MPD:

Code: Select all

systemctl restart mpd

And retest again.

A reboot will remove the change. If this works, I will post an update which will make the change permanent.

janui

[Beelzebassie]

(...)

Hi Janui,

Tried both suggestions, but unfortunately to no avail regarding FLAC.

Your adjustments disable DoP (fixing the sample rate to 192kHz / 32 kHz resp.) and this does seem to alleviate most stutters for DFF/DSD64.

As long as the playing queue has tracks with the same sample rate and bit rate, the stuttering disappears after about a minute during the first track, and the others play perfectly. Try to skip tracks or throw in some different bit rates / sample frequencies, and the stuttering starts from scratch.

[janui]

Tried both suggestions, but unfortunately to no avail regarding FLAC...

Hi Beelzebassie,
I need some more information to go further. Some questions:
- Could you confirm that MPD is not updating (you should see a music note followed by the work 'Library' in the left tab on the main UI)?
- Did you check the the sha-256 checksum of the download and image?
- Have you tried burning a new Micro-SD card? (If you do this make a backup first, then you can restore your settings, see the Settings UI)
- Do you run RuneAudio with a Wi-Fi connection?
- Do you store your music on a NAS?
- Could you look at the debug, find the line '###### Network, connected interfaces (ip -s -h -d addr) ######', then look for the 'errors', 'dropped', 'missed' counters in that section. If any are non-zero please report it.
- Could you log into the CLI and run the following command and send me the output:

Code: Select all

journalctl | grep -iE 'error|warn|fatal'

In the meantime I have tried to recreate your problems using my very slow NAS with various PI models and soundcards (I don't have a DigiOne). When similar problems do occur increasing the 'Audio Buffer Size' in the MPD UI fixes it. I know you have tried this, so I am trying to eliminatie what is not going wrong. The tests involving changing the allowed formats seem to indicate that the DAC is working correctly with the supplied data, but the data is not arriving fast enough.

janui

[RoyB]

Hi janui,

I also tried your suggestion to test editing the file ‘etc/mpd.conf’. I only tested the option “*:16:* *:24:*”. No success.

- Doubling the ‘Audio Buffer Size’, brings no improvement.
- I’m certain that MPD is not updating, when the dropouts occur.
- I checked the SHA256 ckecksums.
- Up to now I didn’t try an another Micro-SD card.
- I do not use a Wi-Fi connection.
- Via an USB-port a HDD is directly connected as source for the music files.
- The debug info give only zero for the counters ‘errors’, ‘dropped’ and ‘missed’.
- I’m able to produce the log via Putty, but lack the (elementary) skills to copy/export it. By the way I see several ‘warnings’.
- I use at moment a Pi2 Model B rev 1.1. I’m aware this is not a ‘fast’ one, but worked fine with RuneAudio 0.5b. I could try a Pi3, but as Beelzebassie also encounters a problem with a DigiOne, I don’t think that a higher clocked Pi is the solution.
- The dropouts occur after about 1 sec, then at about 3 sec, and then approximately after 10 sec.

RoyB

[janui]

Hi RoyB,

I also tried your suggestion to test editing the file ‘etc/mpd.conf’...
- The dropouts occur after about 1 sec, then at about 3 sec, and then approximately after 10 sec....
RoyB

Thanks for trying this and giving me some extra information. You have given me some clues as to where the problem may lie. Could you log into the CLI and try running the following command:

Code: Select all

ionice -c 3 -p $(pgrep -w rune_MPDEM_wrk)

Then retest. You may find that retrieval of the album art is slower.

janui

PS This is also valid for Beelzebassie.

[Beelzebassie]

Could you log into the CLI and try running the following command:

Code: Select all

ionice -c 3 -p $(pgrep -w rune_MPDEM_wrk)

Unfortunately above command returns:

ionice: option requires an argument -- 'p'


As for:
journalctl | grep -iE 'error|warn|fatal'

Code: Select all

Aug 02 01:54:49 runeaudio kernel: WARN::dwc_otg_hcd_init:1072: FIQ DMA bounce buffers: virt = ffffffc008453000 dma = 0x00000000f8410000 len=9024
Aug 02 01:54:49 runeaudio kernel: WARN::hcd_init_fiq:496: MPHI regs_base at ffffffc00806d000
Aug 02 01:54:50 runeaudio kernel: vc_sm_cma: module is from the staging directory, the quality is unknown, you have been warned.
Aug 02 01:54:51 runeaudio kernel: snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
Aug 02 01:54:51 runeaudio kernel: bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
Aug 02 01:54:51 runeaudio kernel: bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
Aug 02 01:54:51 runeaudio kernel: bcm2835_isp: module is from the staging directory, the quality is unknown, you have been warned.
Aug 02 01:54:51 runeaudio kernel: bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
Aug 02 01:54:51 runeaudio kernel: bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
Dec 23 20:41:40 runeaudio alsactl[322]: alsa-lib main.c:1560:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -2
Dec 24 09:48:44 runeaudio logrotate[999]: error: failed to rename /var/log/runeaudio/ui_error.log to /var/log/runeaudio/ui_error.log.1: Operation not permitted
Dec 24 09:49:38 runeaudio (systemd)[1259]: pam_warn(systemd-user:setcred): function=[pam_sm_setcred] flags=0x8002 service=[systemd-user] terminal=[] user=[root] ruser=[<unknown>] rhost=[<unknown>]
Dec 24 11:18:46 runeaudio cmd_async_queue[488]: Warning: openssl_encrypt(): A tag should be provided when using AEAD mode in /srv/http/app/libs/runeaudio.php on line 1032
Dec 24 11:18:46 runeaudio cmd_async_queue[488]: Warning: gzinflate(): data error in /srv/http/app/libs/runeaudio.php on line 1033
Dec 24 11:18:46 runeaudio cmd_async_queue[488]: Warning: [app/libs/runeaudio.php][reset_cmd_queue_encoding] Encode/decode invalid cipher: 'chacha20-poly1305'
Dec 24 12:03:31 runeaudio cmd_async_queue[488]: Warning: openssl_encrypt(): A tag should be provided when using AEAD mode in /srv/http/app/libs/runeaudio.php on line 1032
Dec 24 12:03:31 runeaudio cmd_async_queue[488]: Warning: gzinflate(): data error in /srv/http/app/libs/runeaudio.php on line 1033
Dec 24 12:03:31 runeaudio cmd_async_queue[488]: Warning: [app/libs/runeaudio.php][reset_cmd_queue_encoding] Encode/decode invalid cipher: 'chacha20-poly1305'

PS. I can confirm the behavior RoyB encountered.

[RoyB]

Hello.

Recently I swapped, because of the dropout problem, several times between version 0.5b and the new version 0.6b. It could be imagination, but I noticed that the version 0.6b sounds better. The music is more detailed and has a nice and more balanced sound. The music is more at ease. Up to now I only used the default Sound Signature. I didn’t expect an improvement in sound quality, so it surprised me. Is this because of a better jitter performance with the new kernel? I use RuneAudio with a Pi2 and Allo DigiOne. The Allo DigiOne is renowned for its low jitter spdif output. So what could be the explanation of this soundwise difference between 0.5b en 0.6b?

@janui or others. Please enlighten how the Sound Signature tweaks may affect the sound.
What is the experience of other RuneAudio users with RuneAudio 0.6b?