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

[jrling]

@willemoes, glad you got SRC working - regarding Sox, sounds like you neglected to disable the default output before enabling a Sox output - depending on the hardware this can do a variety of bad things, you have to be diligent about disabling the default output before enabling a Sox output. This is because the underlying hardware is the same and if both are enabled conflicts will ensue. MPD doesn't have any features to protect a user from themselves in this case.

Once you get them both working let us know what you think of the difference.

I run mpdPup on an Intel Dual Core 1.66 GHz Atom D510 mobo with 4GB RAM.

I have now had a chance to compare SRC/SOX on that PC. I run SRC at 'Highest' quality level (0)

SOX at 176,400 was unable to run without stuttering whereas SRC at 176,400 runs fine. I have to conclude that SOX is more CPU intensive.
At 88,200 both ran fine. There was very little in it for SQ, but in the end, I prefer SRC as being more 'natural'. Both IMHO though enhance 44.1/16 CD usefully, especially at the top end.

Of course, your mileage may vary.

[luisb]

Yes Idolse, thats an issue to. I began to try to automount the card reader with the following line on fstab :
/dev/mmcblk0p1 /mnt/mmcblk0p1 auto defaults
also tryed vfat (card is in vfat) instead of auto and it doesnt mount.

But if i add to the /etc/rc.d/rc.local the following lines:

mkdir /mnt/mmcblk0p1
mount /dev/sda1 /mnt/mmcblk0p1

It works for the card reader, if i add the line

mount -t ntfs /dev/sdc1 /mnt/sdc1

it doesnt mount the usb drive. Really i am trying to make the card reader working for now.

[luisb]

Sorry, replace mount/dev/ sda for mount/dev/mmcblk0p1.

[boulogne75]

Hi,
I am starting to try mpdPup and it looks very promising, congratulations!!!
I have one suggestion and two questions.

CIFS should use a credential file to store the username and password (chmod 700 it) and uses the credentials option to mount the share. It's more secure and a wider password range will be allowed. Actually you can't use passwords with ',' (coma) characters because it is the options delimiter in fstab. I think this point should be really easy to implement.

Now, the questions...
Is there any way to change/redetect/swap audio interfaces without reinstalling or using CLI to load module and modify alsa/mpd config files? I'll be swapping Young DAC and Hiface2 but can't figure out how to "magically" make it work.
Any plan on NFS support?

Thanks and keep up the good work!!!

[boulogne75]

I've seen discussions about several tweaks. I don't know if the package exists for Puppy: rtirq-init (name in Debian). It can address a few of these tweaks (irq threading, priorities...) and you can achieve pretty good defaults/balance for USB Dacs and PCI Cards. An option to activate it in the wizzard would be possible as it is an init script that can be enabled/disabled in a config file.
It takes advantage of irqthreads/realtime enabled kernels. I am actually at work and cannot check if this is the case of mpdPup.

[ldolse]

Apologies for the delayed replies. @luisb, handling USB drives in that manner is on my to-do list, it's just quite a ways down - I'll get there eventually.

@ boulogne75, thanks for downloading and trying things out. If you have more documentation on how to store the CIFS user/pass in a credential file I'd appreciate any links you have. Increasing security isn't a major concern, but having more password flexibility would be good.

Unfortunately I don't know of any way to automagically swap interfaces. You could do this yourself with a hotplug script - basically the hotplug action would swap between diferent mpd.conf files for the different cards (or possibly edit in-place), then re-start MPD. I don't see it as something I could easily bundle into the wizards though, as the actions would be a little bit different depending on the model of the card.

NFS support hasn't been high on my priority list - I did give it a shot at one point, but didn't have much luck with it. I might give it another shot now that I have a new NAS which supports it, but I wouldn't hold my breath.

Thanks for the info on rtirq-init, I'll do some more reading on that.

[luisb]

Idolse, i just solved the network problems i had with my server so USB drive will not be in my concerns anymore. I will stay with the configuration mpdpup was designed for. A great listening pleasure it gives.
Regards

[boulogne75]

@ldolse
It's pretty straightforward:
As root:
- Create an /etc/samba/credentials file
Add username=xxxx
Add password=xxxx
- chmod 700 /etc/samba/credentials
Now only root user can read/modify/execute the file
- Mount the share in fstab
//server/sharename /mnt/musicfolder cifs credentials=/etc/samba/credentials,other,options 0 0

http://anothersysadmin.wordpress.com/20 ... tial-file/

If you don't know it, you can take a look at AutoFS:
http://www.autofs.org/
It allows to easily automount any kind of filesystem (usb, cifs, nfs...), choose the mount point, pass mount options, and automatically unmount after an idle time...

Regards.

[jrling]

Hi ldolse

In a thread over at AudioAsylum - http://www.audioasylum.com/cgi/vt.mpl?f ... o&m=117722

A guy is promoting a number of low level tweaks to Linux audio and has suggested some for mpdPup. He suggested they were posted to our forum and so I am doing so -

Here are some more settings to add into the mpdstart.sh file

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 "1000 1024000 512 2048" > /proc/sys/kernel/sem
echo 268435456 > /proc/sys/kernel/shmmax

There followed some debate on some of the values he has used. I see they include 'swappiness' which we know does not apply to mpdPup running entirely in RAM.

I would be interested to hear if any of his suggestions would be able to be run in mpdPup and/or whether what you have done would conflict with his suggestions.

Many thanks

[ldolse]

@boulogne75, thanks for the extra info - I'll see about implementing this for the next version.

@jrling, I just saw that thread on all those tweaks - lots of good stuff there to add to the wizard. Can you point out documentation for any of these items that weren't previously discussed? I'd like to be able to document the purpose for each one, I'm not inclined to implement tweaks I can't explain.

[jrling]

I am afraid not. I just saw them and passed them on. The poster gave no explanations, but is obviously well informed. If you want, I will ask him for explanations but I cannot of course guarantee that he will reply.

Before I do so, for reasons of not wanting to waste his time, are you able to confirm which ones will work in mpdPup conceptually and which ones will not with the kernel that you use? We know for example swappiness is not applicable.

Have you had any chance to look at the rt-irq tweaks that Dynobot and boulogne75 have suggested?

It looks like we are building a number of tweaks which some may want to try and others not. I was wondering whether a new '0.9.3 Tweaks' thread might be helpful, as some readers may not want to get involved in tweaking?

[ldolse]

I think it's ok to keep the tweaks in this thread. I'm not sure which ones don't apply. As you noted swappiness shouldn't matter.

• /proc/sys/vm/vfs_cache_pressure probably doesn't matter either as it sounds like it's also related to swap files.
• /sys/module/ehci_hcd/* - quite possibly relevant, more info would be good
• mousepoll - not sure if it's relevant when no mouse is attached, and not sure what it will do to X with that large a number defined when a user does want to use a mouse.
• /proc/sys/vm/dirty_* - not sure how relevant it is when the filesystem is always in memory, but it's possible that it would reduce 1's and 0's being shuffled around for no reason.
• /proc/sys/net/ipv4/tcp_app_win - setting this to zero seems to tell the kernel not to reserve memory for TCP activity - I'm not sure how this would be a good thing, so definitely need more background on this one, since TCP gets used heavily by anyone with a network share.
• /proc/sys/kernel/* - some of the suggested numbers seem quite large, definitely would want some background on the logic and what the impact on memory is along with audio, but I can imagine that changing some of these could have a positive impact. Most of these settings only show up in Google searches related to relational database tuning. I'm not saying they won't make a difference in MPD's performance, but a relational database and MPD are very different beasts.

Also note many of the other tweaks that I've implemented were validated by multiple users in these or other forums using mpdPup before I implemented them. Would be great to see more users chime in and indicate that their independent testing also saw an improvement. Basically more votes of confidence will give a given tweak priority. Most of these most recent suggestions can easily be tried by anyone - there aren't any additional binaries required like there are for some of the other tweaks.

I haven't had a chance to do a lot of work with a variety of the tweaks discussed over the last page or so aside from investigating which packages I will need to include in the next release - been travelling over the holidays so development has been slow.

[jrling]

Thanks for the feedback.

Now that they are posted on this forum, I am sure that we will get feedback if no extra binaries are required.

Will post your reply comments back to the AA correspondent.

Cheers

[Dynobot]

Hi ldolse

I looked into those settings posted on another forum. Perhaps some are on the right path BUT and a HUGE BUT...his numbers are extremely faulty. He got the numbers purely out of the air or out of his...well. Anyways I would not use any of them and even though some of the kernel tweaking can be done with proper numbers MPDPup is already at optimal. I spent some time and looked up the proper usage for each of those and how/why each value is used. I applied 'proper' values based on what Linux calls for, yes if you change the numbers the sound will change but each value is already at the optimal setting for Puppy Linux. I would caution plugging in random values like he does.

[jrling]

Hi ldolse

I looked into those settings posted on another forum. Perhaps some are on the right path BUT and a HUGE BUT...his numbers are extremely faulty. He got the numbers purely out of the air or out of his...well. Anyways I would not use any of them and even though some of the kernel tweaking can be done with proper numbers MPDPup is already at optimal. I spent some time and looked up the proper usage for each of those and how/why each value is used. I applied 'proper' values based on what Linux calls for, yes if you change the numbers the sound will change but each value is already at the optimal setting for Puppy Linux. I would caution plugging in random values like he does.

I had arrived at the same conclusion.

Having said that, there are one or two of his suggestions that I might try. For instance I run mpdPup headless and no networking for music, so the mouse polling and TCP 'turning off' ones might have some merit. Worth a try anyhow.

Do you credit his ehci suggestions as being worthy?

My Tranquil PC T2E has four USB ports on the rear panel (I have disabled the onboard USB header in the BIOS) and I only use one for my WaveIO USB/S/PDIF converter. So I wondered if I could turn off all but one USB port in Linux?

Finally, you made a sweeping statement (!) - and even though some of the kernel tweaking can be done with proper numbers MPDPup is already at optimal Could I gently question that? I am not suggesting that you are wrong, but I suspect that Puppy Linux kernel on which mpdPup is based is certainly not aimed at audiophiles and unless those settings have been modified before mpdPup release, they might not be optimal. But of course with all the variables of individual hardware set-ups, there is probably no such thing as optimal.

Regards

[Dynobot]

I had arrived at the same conclusion.

Having said that, there are one or two of his suggestions that I might try. For instance I run mpdPup headless and no networking for music, so the mouse polling and TCP 'turning off' ones might have some merit. Worth a try anyhow.

Do you credit his ehci suggestions as being worthy?

My Tranquil PC T2E has four USB ports on the rear panel (I have disabled the onboard USB header in the BIOS) and I only use one for my WaveIO USB/S/PDIF converter. So I wondered if I could turn off all but one USB port in Linux?

Finally, you made a sweeping statement (!) - and even though some of the kernel tweaking can be done with proper numbers MPDPup is already at optimal Could I gently question that? I am not suggesting that you are wrong, but I suspect that Puppy Linux kernel on which mpdPup is based is certainly not aimed at audiophiles and unless those settings have been modified before mpdPup release, they might not be optimal. But of course with all the variables of individual hardware set-ups, there is probably no such thing as optimal.

Regards

Hi jrling,

Yes I realized afterwards that the optimal statement was general and not exactly true. I did play with some of the kernel numbers with correct values and found that the stock values sounds best. Hence the statement....but what is best for me might not be for another.

As far as the TCP ....are you suggesting turning off network capabilities? If so then you will not be able to get back into the OS to make any further changes.

With another distro of Linux I used a program called Tree to help me unbind hardware from the OS. After a lot of work I actually did not hear much of a benefit.

What I did hear a nice benefit from is setting affinity for the MPD to run in a CPU by itself.

Also even though the OS does not use swapping, there is a value in the swappiness setting of 60. Poking around the OS I found that even though its pretty light weight it still has some junk inside it, like sound files for sound effects and modules that might be loaded for printing etc.

[jrling]

I had arrived at the same conclusion.

Having said that, there are one or two of his suggestions that I might try. For instance I run mpdPup headless and no networking for music, so the mouse polling and TCP 'turning off' ones might have some merit. Worth a try anyhow.

Do you credit his ehci suggestions as being worthy?

My Tranquil PC T2E has four USB ports on the rear panel (I have disabled the onboard USB header in the BIOS) and I only use one for my WaveIO USB/S/PDIF converter. So I wondered if I could turn off all but one USB port in Linux?

Finally, you made a sweeping statement (!) - and even though some of the kernel tweaking can be done with proper numbers MPDPup is already at optimal Could I gently question that? I am not suggesting that you are wrong, but I suspect that Puppy Linux kernel on which mpdPup is based is certainly not aimed at audiophiles and unless those settings have been modified before mpdPup release, they might not be optimal. But of course with all the variables of individual hardware set-ups, there is probably no such thing as optimal.

Regards

Hi jrling,

Yes I realized afterwards that the optimal statement was general and not exactly true. I did play with some of the kernel numbers with correct values and found that the stock values sounds best. Hence the statement....but what is best for me might not be for another.

Interesting and helpful.


As far as the TCP ....are you suggesting turning off network capabilities? If so then you will not be able to get back into the OS to make any further changes.

Good point. I have been influenced by 'Tony's Player' and John Swenson on AA in assuming networking running whilst playing music is a 'bad thing'! What would be good, but not practical I suspect, is the sort of CMP/CPLAY approach of turning off virtually every process before starting to play and waking them up again on finishing. Do you think that approach is worth thinking about for mpdPup?

With another distro of Linux I used a program called Tree to help me unbind hardware from the OS. After a lot of work I actually did not hear much of a benefit.

You might have saved me a lot of time and heartache

What I did hear a nice benefit from is setting affinity for the MPD to run in a CPU by itself.

I am looking forward to ldolse implementing those packages for us to be able to do that

Also even though the OS does not use swapping, there is a value in the swappiness setting of 60. Poking around the OS I found that even though its pretty light weight it still has some junk inside it, like sound files for sound effects and modules that might be loaded for printing etc.

If I knew more about what I was doing, I would be rooting out those processes that are 'unnecessary' in my dedicated approach (which of course will not suit everyone). Any pointers to their deletion much appreciated

[ldolse]

The ehci stuff is interesting to me because most people are using USB DACs with Linux, but the same settings may be radically different for a use case like jrling with USB attached storage.

The other kernel parameters are of interest, but I agree with Dynobot that there needs to be some method to the madness around the choice of defaults, and if I add a tweak to mpdPup's UI I'd like to be able to explain to a user the theory as to why it might affect the sound. As the only deep dive discussions I've seen on the settings relate to Oracle/DB2 I'm inclined to leave the defaults for now.

Regarding swappiness, I'm not sure I understand how it could impact the sound at all because it just affects when Linux decides to use the swap file, without a swap file I don't see how it would apply. I do think some of those /proc/sys/vm/dirty numbers may apply in the way you're thinking, since even though the file system is in RAM system memory is separate from filesystem memory and those figures may affect data being swapped between two different memory locations.

Regarding cruft that's still in the iso, as long as the file isn't doing something to actively change the system configuration I don't see how they can affect the sound - it just uses a bit of extra RAM. The sound sample files take up a bit of space, but I think they're fun, and I don't see how they can affect the system performance. Other cruft like printer drivers, etc should all be disabled already, affecting memory a bit but they shouldn't affect performance. I cherry pick more things for removal each release, but it's getting harder to find broad categories of files which make much of a difference in terms of reward vs. effort - please feel free to list out specific areas that are ripe for removal.

[bonalux]

Hi Idolse and all, i need some help again I've installed mpdpup on the Alix board, all went well and configured the wizard with no problem, but when trying to unmute my waveio, the unmute command seems to not working and if i try to open alsamixer i'll get the message "cannot open mixer: No such file or directory", have you got a clue? Installed a fresh copy of mpdpup 0.9.3a.

Thank you very much.

[ldolse]

Hi Bonalux, I still haven't released a proper fix for that, my last attempt was a failure, and while I've taken a new approach that hasn't been wrapped up into a new release. For now you just need to unmute it manually by typing 'alsamixer -c 1' (replace 1 with the number for your card). Then unmute by selecting the channel and hitting 'm'. Escape to exit, save the config by typing 'alsactl -f /etc/asound.state store'. Then reboot from the command line to make it stick.