Page 49 of 52

Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 22 May 2018, 18:47
by Dave Platt
I'll see what I can do. It's not the prettiest beast inside, but it works :-)

I've been digging into a software issue - figuring out just why the "global random" track feature (using ashuffle) tends to offer up the same series of "random" tracks each time it's used. I think I understand the problem now, and I've figured out a couple of possible workarounds/solutions.

ashuffle uses a standard software pseudo-random-number-generator function (the POSIX "rand()" function) to drive its selection of tracks. Like all such generators, rand() is completely deterministic - if you start it out in a known state it'll generate the same set of "random" numbers. ashuffle tries to avoid this, by deliberately "seeding" the function with a unique value each time the program starts up. ashuffle's choice for this value would work well on a standard PC, but not on a Pi running RuneAudio... because it uses the current value of the time.

Since the Pi doesn't have a hardware clock, it sets the kernel time-of-day counter to the same value each time it boots (the exact value apparently depends on the software build version). Since the RPi boots up quickly and with little timing variation from one boot to the next, the time-of-day counter (measured in seconds from the epoch, I believe) will usually be the same when ashuffle samples it, and so ashuffle's behavior becomes very predictable.

The RuneAudio distribution of Arch Linux does start up a daemon (ntpd.service) which attempts to set the clock from NTP servers on the Internet. However, this takes at least a few seconds - it's an operation that happens in the background - and it usually doesn't complete by the time that ashuffle starts up.

One possible solution to this is to ensure that a better attempt is made to set the system clock, before ashuffle starts up. This can be done by making a few changes to the system service definitions. One possible solution:

  • "systemctl enable ntpdate.service". This enables a "one shot" time-setting service at boot, querying the time servers and setting the clock and exiting. It's done before the existing "ntpd.service" daemon is allowed to start, so the two will not conflict.
  • Edit the "ashuffle.service" file. Add a "Wants: ntpdate.service" line, and add "ntpdate.service" to the "After:" line.
  • Reboot.

When the system boots, systemd will fire off the one-shot "ntpdate.service" to try to set the clock (it'll either succeed or fail in a few seconds) in parallel with most of the other service startups. The existing "ntpd.service" daemon will be held off until "ntpdate.service" has finished. Most of the runeaudio software will start up immediately, as usual. However, if you've enabled Global Random, then runeaudio will run a "systemctl start ashuffled.service" command. This service won't be allowed to actually start until the ntpdate.service has either succeeded (in which case the clock is set and ashufffle will get a good value for the time) or failed and timed out (in which case ashuffle will behave as it does today).

I don't know how long the timeout is.

Another approach would be to store the current time to a file on the SD card at shutdown, and then restore it (set the clock) early in the boot process. This could be done with a single service, which runs "before" ntpdate.service and ntpd.service. Its stop action would run

Code: Select all
date +%m%d%y%H%M.%S > /my/magic/file

Its start action would check for the existence of that file, and then run

Code: Select all
date $(cat /my/magic/file)

That solution has the advantage that it will work reasonably well even if there's no Internet connectivity - the clock will always move forwards between boots, even if it was never set correctly in the first place.

Yet another, entirely different approach would be to modify ashuffle to use a different method for seeding the rand() function, or use a different random number generator entirely (e.g. the Linux kernel /dev/urandom). One could add a new --seed option to the command line, to pass in a seed value, and then have a startup script figure out such a value and pass it in. The value doesn't have to be cryptographically strong, just different each time... the script could maintain a "boot counter" in a file on the SD card, and seed ashuffle with values like 1, 2, 3, ... on subsequent boots. Or, the script could do something like

Code: Select all
cat /var/log/runeaudio/* | wc -c

and figure that the total sizes of the logs would vary a lot from boot to boot.

Using /dev/urandom is tempting, but I think risky. The Linux kernel entropy pool is notorious for being low in quality immediately after boot, because not enough has happened to trigger the built-in entropy sources (timing-related, mostly). It's possible to save the pool at shutdown and restore it on reboot, but I don't know if Arch does that, and it wouldn't be dependable if one doesn't remember to shut down cleanly.

Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 22 May 2018, 22:01
by janui
Hi DavePlat,
ashuffle works fine when a more recent Linux version is installed. It's random function will then not return the same track results. Unfortunately updates to v0.4 are now very difficult. If this is important for you the image here works as it should: runeaudio-0-3-beta-for-raspberry-pi-t502-520.html#p23625
You will lose most of the 0.4 functionality.

Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 23 May 2018, 00:33
by Dave Platt
Thanks very much for the information, janui!

Since my NTP-service-based workaround seems to be effective on my system, I think I'll stick with my current lightly-modified 0.4 setup for now, and await the eventual "grand convergence" of the 0.4 features, and the more modern kernel and other backing packages that you've put in the 0.3 update.

Is there any standard repository available online for the source code for the various versions? I looked at the github repositories pointed to by this site, and they don't seem to have been updated in the last couple of years. Since there are components in RuneAudio which are under GPL, keeping current source code available for download would seem to be essential...?

Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 23 May 2018, 01:29
by rastus
Hello Dave,

I am reading your few posts with keen interest. So polite too: "grand convergence" Giggles!



Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 23 May 2018, 04:37
by Dave Platt
Heh... thanks! :) I know that mergers between development branches can often be a bear to manage successfully... I've seen a few which were more train-wrecks than convergences... but I'll gladly keep my fingers crossed that this one goes well.

Here are a couple of quick photos of my weekend-project player:


Part of the challenge to this, was that I wanted to make the player out of as many recycled, surplus, and out-of-my-big-junk-box-of-interesting-stuff parts as I could, with as few "new-item" purchases as possible. I could certainly have gone out and gotten a nice commercial case and kit for it, but as they say, where's the fun in that? The rest of the system I'm using it with is of the same ilk... a pair of rotted-out Minimus 77 mini-speakers that I bought for about $5, and gave a tender-loving upgrade (re-foamed the woofers, scratch-built a new Zilch crossover with decent 5-way connectors, vibration-coated the cabinets) and a Proton D940 that needed a bunch of TLC (new power switch, full cleaning of the controls, and an IF alignment). I love bringing old stuff back from Beyond.

So... anyhow, what you see is the result of my recycling and improvisation over the course of a weekend. The case is (clearly) from an old Black Box GPIB converter that I'd bought for $5 (and you can't find a nice new metal case for that sort of price). The TO-220 heatsink came off of the converter's PC board. The back panel had been mounted to the converter PC boards and was now floating loose, so I just mounted it with a couple of angle brackets and some JB Weld. The power switch, polyfuse, capacitors, and regulators came out of my junkbox (the big regulator is a Micrel high-reliablility part from a surplus buy - basically a 7805 on steroids - I measured 3 and they were all between 5.00 and 5.02 volts). The RCA jacks were a surplus buy (the yellow "video" jack is unused). Hot-melt glue was used where appropriate.

There's certainly more I could do to this... maybe some front-mounted GPIO-driven LEDs for status, and/or some switches hooked up to a script which would issue play/pause/skip/shutdown commands. I'll wait to see if inspiration strikes.

I may build another of these at some point, for the primary music system in the living room. If I do I'm sure I'll pay a lot more attention to detail and cosmetics, in addition to audiophilia. I like the idea of using a DAC with a low-jitter on-board "master" clock - running the DAC directly from a crystal has always appealed to me. Maybe use a box big enough to support a decent-sized LCD touchscreen (I got one of the 2.8" screens along with the Pi I bought, but it's really too small to be useful for control).

Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 25 May 2018, 19:39
by LeighP
Looking really good Dave!

Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 10 Jun 2018, 09:48
by tetedecon
Hi there,

Pretty sastified with Rune 0.4 Audio running on Rasp 3.

Is there any way or a setting already existing to manage playback autoswitch off?


Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 18 Jun 2018, 23:25
by Ripa
Does any can help me out with spotify, i have an premium account
how can i stream to the runeplayer?

i also need to protect the setup menu my kinds f*ck up the settings


Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 21 Jun 2018, 09:55
by tml3nr
Ripa wrote:Does any can help me out with spotify, i have an premium account
how can i stream to the runeplayer?

i also need to protect the setup menu my kinds f*ck up the settings




Re: RuneAudio 0.4-beta for Raspberry Pi2/3

PostPosted: 22 Jun 2018, 12:21
by Ripa

i will try this, i have RPI3 not 2, hope this will work

Anyone an solutions for protect the menu settings?