mpdPup - Simplified MPD Music Server/Jukebox - v0.9.3

[DenisP]

Those sizes sound about right - if you're really worried about the database growing you could just stick the MPD home folder on the NAS - you just need to edit mpd.conf to point there.

That sounds interesting...

So, basically, I could have separate MPD home folders for each external USB disk - each on its own disk?
That way I could avoid a new mpd library update each time the user swaps external storage (swaps existing USB disk with another... one of my friends has 3-4 LARGE USB disks with HQ flac files)

However, I guess that requires the same folder and mount structure for each of the external disks used, as stated in mpd.conf

Am I on the right track?

Basically, I'm trying to make swapping USB storage transparent for the (linux-ignorant) end user
If such a user needs to initiate a new mpd library update each time he/she connects another large USB external disk, it's not going to work without my extensive phone support

[ldolse]

So, basically, I could have separate MPD home folders for each external USB disk - each on its own disk?
That way I could avoid a new mpd library update each time the user swaps external storage (swaps existing USB disk with another... one of my friends has 3-4 LARGE USB disks with HQ flac files)

However, I guess that requires the same folder and mount structure for each of the external disks used, as stated in mpd.conf

Am I on the right track?

Basically, I'm trying to make swapping USB storage transparent for the (linux-ignorant) end user
If such a user needs to initiate a new mpd library update each time he/she connects another large USB external disk, it's not going to work without my extensive phone support

Hmm... if you're looking at a disk swapping solution it could be done theoretically. The MPD DB and music folders would indeed need the same folder structure on each disk as you note. You should mount the disks read-only to the same mount path to facilitate safer swapping, and you would ideally want a udev rule to launch the mpd init script to restart MPD automatically when the disks were swapped so it would change to the new database.

[lugili]

Hi all,
I received new firmware from DCS to be able to listen to DSD files over USB. But with my mpd 0.16.8 installation of mpdpup it does not seem to work at the moment, mpd does not recognize DSD files.

Question to people who have expercience with mpdpup and DSD files:
- Is there an easy way to change to mpd 0.17.2 from 0.16.8 in mpdpup when already installed (I think you can choose when you set it up for the first time)?
- Is there any other things to do (I read somewhere in this threat that entries in mpd.conf have to be changed)?

Thanks for help.

[lugili]

I tried to change the MPD version and I was actually able to do it in the mpdwizard - that was easy.
Adding dsd_usb "yes" to the mpd.conf file made it all work. I can listen to DSD now! Great.

Although I am having dropouts playing high resultion files now. Anyone having experience in optimizing the settings (buffersize, etc.) in mpd.conf for DSD?

[ldolse]

Adding dsd_usb "yes" to the mpd.conf file made it all work. I can listen to DSD now! Great.

Although I am having dropouts playing high resultion files now. Anyone having experience in optimizing the settings (buffersize, etc.) in mpd.conf for DSD?

Not sure if you're seeing something DSD specific or just hi-rez specific. Some users find they need to unplug and re-plug the USB DAC after the system has been booted for Hi-rez (176Khz & 192Khz) to play correctly. DSD might be in the same boat.

[luisb]

@cmiu
Works very well
Just one diference on fstab, i use mapped drives names instead of drives letters
"//192.168.2.100/d$ ....." for //192.168.2.100/backup .....
@idolse
I think having this option posted by cmiu on mpdwizard, if possible, would be a great improvement in server database management

[ldolse]

My plan for the next release is to move the default music folder location to something like /var/music, and then all the different mounted locations will be sym-linked to that directory. This will allow numerous mountpoints to co-exist easily. Updating the wizard to allow a user to define multiple mountpoints might take a bit longer, but I'll get there eventually.

[luisb]

That's good news

[wlowes]

Hi all
I have been away for a while building amps. MPDPUP was working well, so I have not checked in for a while.

I just got caught up and it looks like there was a bit of a rally to tune for sound when Dynobot came in. Jrling was on some good paths, but it appears to have dropped.

Have you given up or gone underground.

Any update on which threads to prioritize?

What about a list of things to delete?

We need to form an organized effort at sound quality. Not just take other people's wild ideas. Need to test on MPDPUP and then report to Ildose what works so he has a list of priority items to put in 9.4.

I played around with buffer size. I had been using 8192 and load 100% before start. I tried larger sizes and seemed to loose air getting that congested sound. So I went the other extreme and tried smaller and smaller. If I am not mistaken, I believe I am getting detail and air at 512 buffer size and very small 1% load before play. Running Alix 3d2.

Anyone else running Alix care to try this? Takes only a moment. Am I imagining this? Let me know.
Walter

[wlowes]

From my experience with CMP minimizing threads and processes that are not needed does help. MPDPUP is already very lean, but clearly there are system specific items that can be killed.

Alix users, with just a quick glance it is clear we can kill off bluetooth, video, line printer etc. As a teaser try the following. You'll see a nice relaxed clarity in the highs.

killall avahi-daemon
modprobe -r btusb
modprobe -r r8169
modprobe -r uvcvideo
modprobe -r ppdev
modprobe -r lp
modprobe -r videodev
modprobe -r ath9k
killall lxmd-binary

[ldolse]

From my experience with CMP minimizing threads and processes that are not needed does help. MPDPUP is already very lean, but clearly there are system specific items that can be killed.

Alix users, with just a quick glance it is clear we can kill off bluetooth, video, line printer etc. As a teaser try the following. You'll see a nice relaxed clarity in the highs.

killall avahi-daemon
modprobe -r btusb
modprobe -r r8169
modprobe -r uvcvideo
modprobe -r ppdev
modprobe -r lp
modprobe -r videodev
modprobe -r ath9k
killall lxmd-binary

Hi Wlowes, always interested in tweaks - The areas Dynobot and Jrling were discussing were interesting, and I'm sure there is some value in some of them, but no consensus was reached. We were also playing with re-nicing and re-prioritizing a number of processes.

Regarding the modules you're removing above - I didn't think the Alix had any of that hardware. Note modprobe -r won't have any affect unless the kernel actually loaded the module, and without the actual hardware I don't think they will be loaded. Use 'lsmod' to see what is actually loaded on your system. I'm curious to see what is loaded by default on the Alix hardware, so please report back - there may be some obvious modules to remove.

For the most part deleting files will save a bit of RAM because the filesystem is in memory, which is important on a RAM compromised system like the Alix, but I don't believe it should make any difference in sound quality.

I believe jrling has defected over to Windows - but the last set of attempts he sent me are below - which I believe originated from Soundcheck's squeezebox tweaks. Note I'm not specifically endorsing any of these specific settings (and some are more specific to a Squeezebox touch), but I think some of this may be on the right track

Code: Select all

#!/bin/bash
renice -20 3
renice -20 9
renice 2 -p $(pidof loop0)
renice 2 -p $(pidof loop1)
renice 0 35 #psmouse -may be slight improvement
renice 0 16 #ata-sff HDD support - Indiscernable but not worse
renice 9 -p $(pidof xfs_mru_cache)
renice 9 -p $(pidof xfslogd)
renice 9 -p $(pidof xfsdatad)
renice 9 -p $(pidof xfsconvertd)
renice -19 -p $(pidof mpd) #sometimes doesnt work
chmod 666 /sys/module/ehci_hcd/parameters/log2_irq_thresh 
echo 6 > /sys/module/ehci_hcd/parameters/log2_irq_thresh 
chmod 666 /sys/module/ehci_hcd/parameters/park 
echo 3 > /sys/module/ehci_hcd/parameters/park
#echo 999999999 > /sys/bus/usb/drivers/usbhid/module/parameters/mousepoll
echo 1 > /proc/sys/vm/dirty_ratio 
echo 40 > /proc/sys/vm/dirty_background_ratio 
echo 5000 > /proc/sys/vm/dirty_writeback_centisecs 
echo 0 > /proc/sys/vm/swappiness 
echo 2048 > /proc/sys/kernel/msgmni 
echo 65535 > /proc/sys/kernel/msgmax 
echo 65535 > /proc/sys/kernel/msgmnb 
echo 40960 > /proc/sys/fs/file-max 
echo 50 > /proc/sys/vm/vfs_cache_pressure 
echo 0 > /proc/sys/net/ipv4/tcp_app_win 
#echo "2000 2048000 1024 4096" > /proc/sys/kernel/sem #doubled suggested values for 4GB RAM awful
echo 2147483648 > /proc/sys/kernel/shmmax
modprobe -r ir_lirc_codec
modprobe -r lirc_dev
modprobe -r ir_sony_decoder
modprobe -r ir_jvc_decoder
modprobe -r ir_rc6_decoder 
modprobe -r ir_rc5_decoder 
modprobe -r imon 
modprobe -r ir_nec_decoder 
modprobe -r rc_core
modprobe -r rtc
modprobe -r power_supply
modprobe -r serio_raw # serio ports, whatever those are
modprobe -r i2c_i801 # temp sensors
modprobe -r 8250_pnp # serial driver
modprobe -r processor
modprobe -r snd-seq-oss
modprobe -r snd-pcm-oss
modprobe -r snd_seq_dummy
modprobe -r snd_seq_midi          
modprobe -r snd_seq_midi_event      
#modprobe -r snd_rawmidi
modprobe -r snd_seq
#modprobe -r snd_seq_device   
killall lighttpd
killall avahi-daemon

blacklist snd_pcm_oss

I was also trying to re-nice the CIFS threads as well to a lower priority. Unfortunately I just don't think my current system is revealing enough to make it very clear to me if any of these tweaks have a major affect.

[jrling]

Hi Walter

It is partly true that I have defected to Windows! I have been testing (actively) an optimised C++ 'hair shirt' player for a keen coder SBGK over on AA.
He has come up with a render loop coding that is of magnificent sound quality and to my surprise overcoming the enormous bloat and overhead of Windows 7.

TBH Idolse, I am eagerly awaiting 9.4 as there were some tweaks put forward by Dynobot that need kernel code changes beyond my abilities and which you are going to provide in that release.

I feel that through Dynobot's and Soundchekk's advice, I have gone about as far as I can go SQwise with 0.9.3, so was taking a break elsewhere!

Dynobot seems to have have gone quiet too?

Idolse - the code of mine you have quoted - I sent it to you and Dynobot on request for feedback. Any time to try it? I don't by any means hold the code out as the answer... it works well on my D510 dual core Atom board, but the Alix boards are much lower power and therefore one might expect different parameters will work better on Alix.

[wlowes]

Jrling
Really great to hear you are keen on continuing to push the envelop on mpdpup. The base that Ildose provide is a great jumping off point. I am going to take a while to catch up to you and Dynobot. On the Voyage site, a juy named Jan has built mods to mpd 0.17 that allows real time priority setting etc. I found voyage required just too much linux knowledge for my level. I do wonder if we could apply his mods to mpd .17 in mpdpup tho.
Remind me, on what hdw platform do you run mpdpup?

Ildose.. Thank you so much for this sampling of all the stuff Dynobot and Jrling were pursuing. It will give me days and weeks of research and tinkering.

The processes running (after killing the ones previously posted are:

1 ? 00:00:02 busybox
2 ? 00:00:00 kthreadd
3 ? 00:00:00 ksoftirqd/0
5 ? 00:00:00 kworker/u:0
6 ? 00:00:00 migration/0
7 ? 00:00:00 cpuset
8 ? 00:00:00 khelper
9 ? 00:00:00 sync_supers
10 ? 00:00:00 bdi-default
11 ? 00:00:00 kblockd
12 ? 00:00:00 ata_sff
13 ? 00:00:00 khubd
15 ? 00:00:00 kswapd0
16 ? 00:00:00 ksmd
17 ? 00:00:00 fsnotify_mark
18 ? 00:00:00 xfs_mru_cache
19 ? 00:00:00 xfslogd
20 ? 00:00:00 xfsdatad
21 ? 00:00:00 xfsconvertd
23 ? 00:00:00 scsi_eh_0
24 ? 00:00:00 scsi_eh_1
25 ? 00:00:00 kworker/u:1
27 ? 00:00:00 kpsmoused
433 ? 00:00:00 loop1
536 ? 00:00:00 loop0
767 ? 00:00:00 udevd
994 ? 00:00:00 kworker/0:2
1010 ? 00:00:00 kworker/0:3
1460 tty1 00:00:00 sh
1462 tty2 00:00:00 getty
1463 ttyS0 00:00:00 getty
1555 ? 00:00:00 avahi-daemon
1556 ? 00:00:00 avahi-daemon
1568 ? 00:00:00 sshd
1588 ? 00:00:00 dhcpcd
1612 ? 00:00:00 udevd
1616 ? 00:00:00 udevd
1644 ? 00:00:00 cifsd
1654 ? 00:00:00 mpd
1711 ? 00:00:00 sshd
1716 ? 00:00:00 flush-8:0
1717 pts/0 00:00:00 sh
1802 ? 00:00:00 kworker/0:0
1843 pts/0 00:00:00 ps-FULL
#

[wlowes]

So much for measured scientific process. I just put in all the changes listed above in Ildose's post.
Sound is very good. At this point the best I have had on this system. I still will play around with buffers etc, but this worked very well for me. Quieter background, continued great sound stage, not quite so pushed back in the distance. I have had sharper detail with more air around things, but this is the most natural. The biggest change is more base and a warmth across the spectrum. Tons of detail and great midrange, just more warmth. Well implemented Windows tends to a pleasing warmth where linux tends to be analytical. This is a fine balance of both. I spent some time building tube amps and this is what I was looking for. Lots of texture and weight but still crystal clear detail. (pic below)
After the changes, this is what MPDPUP looks like on the Alix..

Mem: 250940K used, 4232K free, 0K shrd, 3076K buff, 224516K cached
CPU: 1% usr 0% sys 0% nic 97% idle 0% io 0% irq 0% sir
Load average: 0.07 0.04 0.01 2/44 2080
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
1654 1 root S < 55416 22% 0 1% mpd
1644 2 root SW 0 0% 0 0% [cifsd]
2080 1850 root R 2628 1% 0 0% top
1845 1568 root S 6688 3% 0 0% sshd: root@pts/1
1711 1568 root S 6688 3% 0 0% sshd: root@pts/0
1568 1 root S 4104 2% 0 0% /usr/sbin/sshd
1850 1845 root S 3156 1% 0 0% -sh
1460 1 root S 3152 1% 0 0% -sh
1717 1711 root S 3152 1% 0 0% -sh
1462 1 root S 2348 1% 0 0% /sbin/getty 38400 tty2
1463 1 root S 2348 1% 0 0% /sbin/getty -L 19200 t
1 0 root S 2344 1% 0 0% /bin/busybox init
1588 1 root S 1904 1% 0 0% dhcpcd -d -I eth0
15 2 root SW 0 0% 0 0% [kswapd0]
1802 2 root SW 0 0% 0 0% [kworker/0:0]
536 2 root SWN 0 0% 0 0% [loop0]
433 2 root SWN 0 0% 0 0% [loop1]
3 2 root SW< 0 0% 0 0% [ksoftirqd/0]
2 0 root SW 0 0% 0 0% [kthreadd]
5 2 root SW 0 0% 0 0% [kworker/u:0]
6 2 root SW 0 0% 0 0% [migration/0]
7 2 root SW< 0 0% 0 0% [cpuset]
8 2 root SW< 0 0% 0 0% [khelper]
9 2 root SW< 0 0% 0 0% [sync_supers]
10 2 root SW 0 0% 0 0% [bdi-default]
11 2 root SW< 0 0% 0 0% [kblockd]
12 2 root SW< 0 0% 0 0% [ata_sff]
13 2 root SW 0 0% 0 0% [khubd]
16 2 root SW 0 0% 0 0% [ksmd]
17 2 root SW 0 0% 0 0% [fsnotify_mark]
18 2 root SWN 0 0% 0 0% [xfs_mru_cache]
19 2 root SWN 0 0% 0 0% [xfslogd]
20 2 root SWN 0 0% 0 0% [xfsdatad]
21 2 root SWN 0 0% 0 0% [xfsconvertd]
23 2 root SW 0 0% 0 0% [scsi_eh_0]
24 2 root SW 0 0% 0 0% [scsi_eh_1]
25 2 root SW 0 0% 0 0% [kworker/u:1]
27 2 root SW< 0 0% 0 0% [kpsmoused]
1010 2 root SW 0 0% 0 0% [kworker/0:3]

[wlowes]

One other question.. To implement this permanently, is it correct that I put these commands into a script and invoke it on start-up? Where would you put such a script.

[wlowes]

Ildose
I may have answered my own question. Rather than create a startup script, I added the commands to rc.local. It appears to work. Parden my inexperience.. Is this a proper approach?
Walter

[ldolse]

Ildose
I may have answered my own question. Rather than create a startup script, I added the commands to rc.local. It appears to work. Parden my inexperience.. Is this a proper approach?
Walter

Adding to rc.local will mostly work but is not really a recommended approach. The better approach is to put it in /etc/init.d and give it an alphabetical name so that it's processed after all the other scripts. This way it will re-nice all the daemons like mpd and kill avahi/lighttpd. Remember to run chmod +x on the file to make sure that it's executable.

I'm loathe to just include a script like this into the official release because there is very little documentation regarding any of this. A lot of these commands don't do anything if run individually because they are tied to the Squeezebox Touch operating system as well.

I am thinking to use a system where a script like this can run and grab the kernel parameters and re-nice values from another configuration file. At the moment the plan is to stick with configuration files - I don't see the value in adding to the wizards unless there are some clear explanations as to the how a parameter could affect audio. Some of the kernel modules being removed are things I'm looking into permanetly removing/blacklisting.

@jrling, glad to hear the defection may not be permanent I did try out your script but as I noted earlier I don't think my own system is as revealing as some others - it sounded good but I couldn't be sure if it was dramatically better or what variables had more affect than others.

[jrling]

Idolse - great to hear your plan for 0.9.4 which sounds like a good one.
Mostly 'my script' is Dynobot's. Where are you Dynobot?!

It made significant improvement to my system and I am sure that there is more to come. But as always YMMV. That's the trouble with OS like Windows and Linux too - however cut down they are made. The slightest change to parameters can have a big effect on SQ - mostly adverse!

Neither OS were designed for audiophile listening. Never were, never will be.

My Windows experience recently with a coder who really really knows what he is doing [SBGK on Audio Asylum], is that even changing one priority setting for the render loop, can ruin SQ. Conversely, getting it 'right' can really improve matters. But no amount of logic can predict which way it will go.

Being 'away' another reflection - albeit a statement of the bleedin' obvious - is that Idolse is just providing the most optimal OS for MPD to run in. But what we are left with is MPD 0.17 as the process that is rendering the music stream - for better or for worse.

So IF MPD 0.17 is not optimal, no amount of good work by Idolse will be able to break through that barrier.

SBGK is an experienced Squeezebox coder so knows his Linux. mpdPup is the most brilliant minimised version of Linux for audio that I know. His rendering code (written in C++) together with mpdPup would make an unbeatable combo. So far, he has resisted porting to Linux, as his code on Windows works so well, there is no incentive; however, the experience I have had of listening to its development, has taught me that the rendering code has by far the biggest impact on SQ rather than optimising the underlying OS.

Hope that I won't get flamed!

[DenisP]

Eh, perhaps a stupid quesiton:

whenever I start X, the MPD wizard starts automatically...

How/where do I turn this behavior off (i.e. I don't want the wizard to start automatically)?

Tried searching in config files that I could find, but to no avail

THX

[DenisP]

How/where do I turn this behavior off (i.e. I don't want the wizard to start automatically)?

Found it!

It's set in: /usr/sbin/delayedrun

Found it while searching through some other threads: I never would have stumbled upon it myself - I'm more used to .xinitrc and other more traditional config files