Randy the new RPi streamer and player on the block

[Sumaco]

@gideon Thank you for the new release and feature updates. In my ears, the music seems to be cleaner sounding with mpv but hey... It's been a long day and the album randomness of Randy is hitting some good headphone music. Is that a hidden feature?

Reinstalled from fresh and that went well. I repointed folders to my main library (~95k tracks). Pretty impressed getAllSongs only took a few minutes to get through it.

I do want to report some observations for you. I attached a bunch of random screenshots which maybe useful.
Randy player interface is stalled when moving between panels presumably generating the random album selection and parallel indexing perhaps?
2 CPU's pegged at 100% and reports after maybe 30s server maybe down at bottom of page. You have a timer.
~25s later it displays the random albums set and is functional to select new tracks. Clicking an album works as expected to fill the queue and start playing music. cha cha cha

After I paused, I noticed a bunch of mpv process at the bottom of the process listing. Not sure what's going on, but appears many processes are spanning, dead or forgotten perhaps? Is that expected?

 

[gideon]

Would it be possible to add a button to clear the recently played section?

When you click on Randy logo, it clears the playlist and loads a fresh random one. (it will load random songs from the music source if you have that set up, if not it will just clear it).

nteresting...re-ran the install script and Randy now reports 44.1kHz files correctly. But... output to DAC is still 48kHz as reported by the DIYinHK XMOS reciever.

The flag that I added, puts the resampling duty on ALSA instead of FFMPEG which is why you see the files' sample rate. Why does ALSA (or something else) resample? I am not sure and need to dig into it a bit, my DAC (khadas toneboard) doesn't have a display so I am not sure but I have a feeling that it may also be resampling.

@gideon Thank you for the new release and feature updates. In my ears, the music seems to be cleaner sounding with mpv but hey... It's been a long day and the album randomness of Randy is hitting some good headphone music. Is that a hidden feature?

it could be a hidden feature of long days haha..
But seriously, my test music library is full of so many hidden gems from many years ago that I go into deep nostalgia every now and then.. sometimes randomness makes beautiful moments happen.

Also thanks @Sumaco you are the first one talking a bit on sound quality! I was curious to hear how others feel about it since I am already used to it.

I do want to report some observations for you. I attached a bunch of random screenshots which maybe useful.
Randy player interface is stalled when moving between panels presumably generating the random album selection and parallel indexing perhaps?
2 CPU's pegged at 100% and reports after maybe 30s server maybe down at bottom of page. You have a timer.
~25s later it displays the random albums set and is functional to select new tracks. Clicking an album works as expected to fill the queue and start playing music. cha cha cha

Hmm.. this is interesting just so I understand better, you were switching these tabs before or after the getAllSongs completed?
Once getAllSongs completes things should get reasonably snappy.. the screenshots are helpful but if you are able to grab the log (journalctl -f -u randy-node) would be even better then I can see if maybe something gets stuck/timeout somewhere...
btw.. Randy looks for the file metadata on the fly and once it has it, it will cache it for the next time you load it. So for example getting the random albums to show on the main screen can take a bit if they are all fresh, it will look for file tags, existing album covers or use spotify album cover api if it can't find one.. for me it's never been more than 2-3 seconds and usually pretty quick.

After I paused, I noticed a bunch of mpv process at the bottom of the process listing. Not sure what's going on, but appears many processes are spanning, dead or forgotten perhaps? Is that expected?

Regarding all the multiple mpv instances in htop. this maybe helpful to explain - https://superuser.com/questions/118...processes-listed-under-the-same-title-in-htop , I am not 100% sure how mpv manages the different threads..
but on Randy side I have a function that kills all instances of mpv if there's a socket timeout or something else goes wrong before it re-spawns it again.

 

[Sumaco]

Nice to know that you only get metadata when necessary. Good design point other players have chosen to ignore for their 1st load.

When I started the system this morning, CPU pegged at 100% Randy/index.js and it is not able to generate a webpage display. 45mins so I restarted.

FYI total file count in library mount.
randyuser@randy:~ $ find /mnt/Music -type f |wc -l
129748

I have PM a log report which shows a couple of things.
The file missing which isn't
Restart after not getting a webpage for Randy
Couple of stalled panel changes

Edit:
Is there an Exclusion function possible? Because I mount to the root folder on the NAS, it is picking up the Recycle bin folders and the content of these.

 

[gideon]

@Sumaco - thanks so much for sending the log!
It seems like similar to the earlier situations you reported when Randy can't reach a specific file goes all nuts with CPU.

I still can't reproduce it, last time I tried to reproduce it by pulling off my HD in the middle of playing a playlist and I even added some things to mitigate some edge situations, but your situation seems a bit different. I am going to send you over some things to try soon

 

[Sumaco]

Interesting...re-ran the install script and Randy now reports 44.1kHz files correctly. But... output to DAC is still 48kHz as reported by the DIYinHK XMOS reciever.
I've rebooted after install.
Ubuntu server on thinclient.

I am seeing this behavior also, no change on the DAC led.

 

[gideon]

Seems like ALSA resamples things by default to 48khz.

I am testing now a change in alsa config which looks like its disabling the resampling (which should happen on the DAC).

@DRONE7 @Sumaco you can test it out like this:

sudo nano /etc/asound.conf

Then replace the existing one with the following (make sure the card number corresponds to your sound card if you changed it)

defaults.pcm.card 1
defaults.ctl.card 1
pcm.!default {
type plug
slave.pcm hw
}

Best to reboot after that for the changes to take effect.

You can then test the output on your DAC screens, or if you don't have a screen like I do there is a way that ALSA provides:
First you need to run

find /proc/asound/ -name hw_params | xargs -I FILE grep -v -l "closed" FILE | grep '/proc/asound/card./pcm.p/sub./hw_params'

it will then spit out something like -

/proc/asound/card1/pcm0p/sub0/hw_params

Then you can run the following command which will show you the output sample rate and other details

cat /proc/asound/card1/pcm0p/sub0/hw_params

If this looks good and sounds good to you guys I can add it to the install script already to be the behaviour out of the box (seems like getting more towards bit perfect this way).

Gideon

 

[gideon]

On a bright note looks like supplies for RPIs are hopefully going to pick up soon (no need to sell your kidneys to get one..) -
https://www.tomshardware.com/news/raspberry-pi-ceo-million-unit-months-are-ahead

 

[DRONE7]

Works !

 cat /proc/asound/card1/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 96000 (96000/1)
period_size: 2400
buffer_size: 9600

Noticed a much quicker access to files and selected item to play.!
Almost instant switching from selection to selection.

 

[phofman]

@gideon : For alsa, you can either configure default device in your .asoundrc, or tell mpv directly which device to use (--audio-device=alsa/device_name), not using the hard-coded "default" https://github.com/mpv-player/mpv/b...7e7f45e9abde77254c72/audio/out/ao_alsa.c#L645

For alsa config - using card name instead of its alsa ID makes the config more robust, as IDs are not guaranteed fixed between reboots. Slave pcm config - typically the card name (event. ID) is directly part of the device string:

slave.pcm hw -> slave.pcm hw:CARD_NAME

That way you do not have to configure the "defaults.pcm.card 1" separately. You may end up using a different alsa name and the onliner config defaults.pcm.card works only for the default device.

The plug plugin in your alsa config is good because it strives to be as transparent as possible, and kicks in with some changes only if the output device does not support the required params (rate, sample size, channels count).

 

[gideon]

@gideon : For alsa, you can either configure default device in your .asoundrc, or tell mpv directly which device to use (--audio-device=alsa/device_name), not using the hard-coded "default" https://github.com/mpv-player/mpv/b...7e7f45e9abde77254c72/audio/out/ao_alsa.c#L645

For alsa config - using card name instead of its alsa ID makes the config more robust, as IDs are not guaranteed fixed between reboots. Slave pcm config - typically the card name (event. ID) is directly part of the device string:

slave.pcm hw -> slave.pcm hw:CARD_NAME

That way you do not have to configure the "defaults.pcm.card 1" separately. You may end up using a different alsa name and the onliner config defaults.pcm.card works only for the default device.

The plug plugin in your alsa config is good because it strives to be as transparent as possible, and kicks in with some changes only if the output device does not support the required params (rate, sample size, channels count).

Thanks for the good information @phofman , I spent some time reading some of the alsa docs over the weekend and I am still trying to get it into my head.

I totally agree with you about using the device name rather than the number!
This is on my todo list as well as part of making it easier to choose an output device. I am thinking of grabbing the list of devices from aplay -l or from mpv --audio-device-list and letting users choose the output device they want to use and in this manner I can also get the device name programmatically.

 

[PjVervoorn]

Last weekend I received the Orange Pi R1 Plus LTS, it is a great device in a nice aluminium case.

I’m running DietPi on it, created via the script https://dietpi.com/docs/hardware/#make-your-own-distribution.
Gideon sent me a message with a way to update mpv to a more current version, it seems this fixed the memory/resource leaks.

After a few experiments I changed some of the command line arguments:

const proc = spawn(opt.bin, opt.args.concat([
'--input-ipc-server=' + socketPath
]), {
stdio: 'ignore',
detached: true,
shell: true
});

and

function createNewPlayer(){
//create player instance
var mpvargs = ['--no-config',
'--no-terminal',
'--idle=yes',
'--af-clr',
'--vf-clr',
'--vid=no',
'--no-video',
'--audio-display=no',
'--no-initial-audio-sync',
'--demuxer-max-bytes=16777216',
'--demuxer-max-back-bytes=1048576',
'--cache-secs=8',
'--script-opts=ytdl_hook-ytdl_path=yt-dlp',
'--ytdl-format=bestaudio'];
// if (os.platform() == 'linux'){
// mpvargs.push('--alsa-resample=yes');
// }

 

[gideon]

Hi Everyone,

I published a new release which brings together the latest fixes to the edge cases for memory creeps and Randy getting stuck.
Thanks @Sumaco and @PjVervoorn for helping to test all the fixes.
The release also puts the fixes to the sample rates thanks to @DRONE7 noticing these things and @phofman for helping to assure that ALSA changes are heading in the right direction.

Randy is now more stable & puts out even more pure sound thanks to the people in the forum.

Randy v1.0.15 Latest​

• Bringing together the latest stability releases
• Added a script to download the latest mpv from mpv's repo with fallback to apt repo
• Added bypass for ALSA dmix resampling into the install script

Please Note:
This release would work best on a fresh install, alternatively you can use update.sh and the temporary update_mpv_alsa.sh scripts if you wish to retain your stickies and library.

I will be away from my laptop for a few weeks (hope she doesn't miss me too much!) and a bit slow to react to things but please continue to share your experience with Randy!

Gideon

 

[picman84]

Mr Gideon
Thanks so much for Randy its very much a fun ride work commitments have me away for a while but i was able too install Randy on a Dell 3040 mini its has onboard emmc works well..i too notice a slight memory growth but looks like the team has been working out the kinks
also when i initially installed on Pi4 i noticed my d10s showed 48khz when playing 44.1khz, Looks like things are changing with updates!
Thanks again i look forward too trying out the new version when i can get off the road!
Take Care all and happy listening

 

[DRONE7]

Update went well ! Still blisteringly fast moving from track to track....all bitrate and formats reported well both in web-gui and USB reciever.
Now it is working I will audition and compare then report impressions vs other OS.
Interested to compare MPV vs MPD...

Well done Gideon ! and enjoy your weeks away !!
All the best to you and yours,
Bob.

 

[gideon]

Thanks both! really looking forward to your auditions.

 

[PjVervoorn]

Besides the changes mentioned earlier, I also added the device name, as suggested by @phofman, to asound.conf.

defaults.pcm.card 1
defaults.ctl.card 1
pcm.!default {
type plug
slave.pcm hw:AUDIO
}

(The Super High End $10 dac I’m using, apparently uses the generic name ‘AUDIO’.)

With all these changes, memory usage for mpv stabilises at somewhere between 55MB and 70 MB, depending on the stream (192k mp3 to 96/24 flac).

I have an additional feature request, for the UI: Play & Stop (or Pause) buttons.

 

[phofman]

@PjVervoorn:

IMO the defaults.pcm.card and defaults.ctl.card variables are used in default configuration in the main alsa configs in /usr/share/alsa - just rgrep that directory, e.g.

pavel@precision:/usr/share/alsa$ rgrep -w "name defaults.ctl.card" *

If you re-define pcm.!default later after the main config (e.g. in your ~/.asoundrc), the device configured by the /usr/share/alsa configs is overriden by your device and the defaults.pcm.card variable has no effect anymore. IMO it can be removed from the config.

Since you did not re-define ctl.!default in your .asoundrc, IMO your defaults.ctl.card variable is applied in the ctl.!default device created by the main alsa configs. Since your pcm.!default uses AUDIO card identifier, it would make sense to use it also in your defaults.ctl.card variable

defaults.ctl.card AUDIO

 

[gideon]

I have an additional feature request, for the UI: Play & Stop (or Pause) buttons.

You can pause and un-pause by clicking/tapping on the spinning wheel

 

[Yatsushiro]

Hi @gideon, thanks for adding Randy to the wide range of RPi music playing SW. I'm currently running it on a Dell/Wyse 3040 under Ubuntu Server. I'm running a cheap generic USB DAC:

paul@randy:~$ lsusb
Bus 002 Device 002: ID 152d:0583 JMicron Technology Corp. / JMicron USA Technology Corp. JMS583Gen 2 to PCIe Gen3x2 Bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 262a:9027 SAVITECH Corp. SA9027 audio controller
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Alsamixer doesn't 'work' on on this device and aplay -l doesn't recognise it:

paul@randy:~$ aplay -l
aplay: device_list:274: no soundcards found...

Everything works as it should with a local USB drive, but it'd be useful for me to have a (optional/switchable) volume control ; any chance?

 

[picman84]

Hello Yatsushiro
I too installed ubuntu server on a dell 3040 and lacked alsamixer i believe i fixed it with

sudo apt install alsa-utils

that got me alsamixer!
The 3040 mini is a great mini pc for Randy!