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

For talk and support relating specifically to Puppy derivatives
Post Reply
Message
Author
bonalux
Posts: 22
Joined: Wed 20 Jun 2012, 11:02

#81 Post by bonalux »

Almost all WaveIo users have the same problem as you (included me), but is easily solved with the procedure previously posted by Idolse
Type the followingat the command line:

Code: Select all

nano /etc/init.d/unmute
Then paste the following into the editor:

Code: Select all

#!/bin/sh 

unmute_audio(){ 
   CARDS=`aplay -l | grep card | cut -f 1 -d ':' | uniq | cut -f 2 -d ' '` 
   for card in $CARDS 
   do 
      CONTROLS=`amixer -c $card scontrols | cut -f 2 -d "'"` 
      for control in $CONTROLS 
      do 
         amixer -c $card sset $control unmute >/dev/null 2>/dev/null 
         amixer -c $card sset $control 100% >/dev/null 2>/dev/null 
      done 
   done 

} 

unmute_audio 
press ctrl-x to exit, then y to save the script.

Lastly type this command:

Code: Select all

chmod +x /etc/init.d/unmute
Then run "alsamixer", unmute the card, exit and type:

Code: Select all

alsactl -f /etc/asound.state store
before using 'save2flash' or a full reboot.


Reboot to save the config, and give it a good 5-10 minutes or so before yanking any plugs to give it time to do whatever it's trying to do and make sure the changes stick.

After that the cards should be unmuted as part of the boot process no matter what state they decided to boot up in on their own.
Most important part is, as Idolse said, give it at least 10 minutes (better if you go away for at least half an hour to be sure) before restarting again and see if it works. For me it worked and there is no more the mute problem.

As all WaveIo user, another problem with it is that if you restart the system without turning off the WaveIo then it is not recognised, have to unpower the card and power on it again, but it's a card problem not mpdpup one.

Idolse: just that i'm writing, as Jrling say, with the latest release there is a problem with usbnrpacks that is stuck at 8, regardless of the choice in the wizard, checked it now at the cli with the cat command, maybe a bug to be fixed in the next release.

jonnyc
Posts: 6
Joined: Mon 16 Jan 2012, 16:27

Installation on a Harddrive / IDE Flash Device

#82 Post by jonnyc »

Hi Idolse, thanks for your reply. I already worked with an USB-drive and Unetbootin. And there was also no problem to get mpdpup working with this very method.

Next goal for me is to install mpdpup to a fake harddrive / IDE Flash device, because there is no rear USB Port on this cute little device and I wanted to have it a little more sexier. And also I have 4 of this IDE Flash Devices, which should work well for this distribution.

Today I tried to install syslinux on the drive and afterwards I copied all files from the loop mounted iso file. It still didn't work.

Next will be an slitaz installation and afterwards I will copy all files from the mounted iso image...

ldolse
Posts: 367
Joined: Fri 23 Oct 2009, 16:33

#83 Post by ldolse »

Hi JohnnyC, what I meant was once you booted off the Unetbootin stick you can then use that live Puppy Linux/mpdPup instance to install to the SSD drive. I added instructions to the second post of this thread. Other users have gotten it working following these basic instructions, but I'm not sure if they're exactly correct. If you go with something like a CF-SATA adapter as you mentioned it would bypass all of these extra steps.

@bonalux, thanks for highglighting that post - in 0.9.3a that script is a included in the iso. I did find there is a bug with it, which is apparently why it doesn't work for some WaveIO users. It needs to be updated to handle spaces in the sound device name. Here is the latest code:

Code: Select all

#!/bin/sh

unmute_audio(){
   SAVEIFS=$IFS
   IFS=$(echo -en "\n\b")
   CARDS=`aplay -l | grep card | cut -f 1 -d ':' | uniq | cut -f 2 -d ' '` 
   for card in $CARDS 
   do 
      CONTROLS=`amixer -c $card scontrols | cut -f 2 -d "'"` 
      for control in $CONTROLS 
      do 
         amixer -c $card sset "$control" unmute &>/dev/null 
         amixer -c $card sset "$control" 100% &>/dev/null 
      done 
   done 
   IFS=$SAVEIFS
} 

unmute_audio
alsactl -f /etc/asound.state store
exit 0
This will be included in the next iso, which I'm working on getting out soon. The nrpacks problem you noticed will be fixed too - not sure how that one slipped by me.

jonnyc
Posts: 6
Joined: Mon 16 Jan 2012, 16:27

thank you

#84 Post by jonnyc »

Hi Idolse and thank you very much for this hint. I just trying to get it on.

I'm so glad, it works! I waited half a year for this solution!!!

Next step is to try this installation procedure with mpdpup 0.9.1.
Since 0.9.2 I have problems with ACPI. After pressing the power button, nothing happens. I hoped that the problem doesn't appear in 0.9.3 anymore, but there is still the same thing... I will try to figure it out.

ldolse
Posts: 367
Joined: Fri 23 Oct 2009, 16:33

Re: thank you

#85 Post by ldolse »

jonnyc wrote:Hi Idolse and thank you very much for this hint. I just trying to get it on.

I'm so glad, it works! I waited half a year for this solution!!!

Next step is to try this installation procedure with mpdpup 0.9.1.
Since 0.9.2 I have problems with ACPI. After pressing the power button, nothing happens. I hoped that the problem doesn't appear in 0.9.3 anymore, but there is still the same thing... I will try to figure it out.
Glad to hear the istructions worked.

Regarding the power button, I wish I knew a good fix there myself - I think the reason 0.9.1 works well in that respect is because it's an old kernel with basically no ACPI support. 0.9.2 and 0.9.3 have proper kernel level support, but that means in order to get the power button to work with a single click you need an extra daemon to watch the power button for clicks. One of my goals is to keep extra processes/daemons to a minimum so I decided to live wtih the long press.

Maybe the trick would be to removing the ACPI kernel modules, will need to give that a try.

Dynobot
Posts: 44
Joined: Wed 05 Dec 2012, 12:04

#86 Post by Dynobot »

Just wanted to say great job with this...

Some suggestions you might consider

-cpufreq - change from ondemand to performance
-somehow be able to unbind devices from sharing the same interrupt
-increasing the priority of the audio threads
-if at all possible give MPD a CPU core to itself via affinity
-enable mmap in MPD

ldolse
Posts: 367
Joined: Fri 23 Oct 2009, 16:33

#87 Post by ldolse »

Dynobot wrote:Just wanted to say great job with this...

Some suggestions you might consider

-cpufreq - change from ondemand to performance
-somehow be able to unbind devices from sharing the same interrupt
-increasing the priority of the audio threads
-if at all possible give MPD a CPU core to itself via affinity
-enable mmap in MPD
Hi Dynobot, I saw you'd done some testing on audioasylum, I was wondering what tweaks you were referring to, so that helps. Was happy to see you had a good experience with it.
  • cpufreq - hadn't heard of that tweak and looks quite simple, will do
  • audio thread priority - my first attempt at this used nice and unfortunately it caused mpd to fail to start on some hardware. I'm looking to do this in the future with chrt, but need to spend some time trying to figure out the best way to build a minimal util-linux package - it's a bit of a clusterf#$!@ to try to build just one piece of it.
  • I'd actually just read about mmap about a week ago, this is on the list to get done soon
  • single core dedicated to MPD is interesting, will explore options there
  • IRQ sharing is the only one that I think will be difficult to tackle, as the behavior varies a lot from platform to platform.

Dynobot
Posts: 44
Joined: Wed 05 Dec 2012, 12:04

#88 Post by Dynobot »

ldolse wrote:
Dynobot wrote:Just wanted to say great job with this...

Some suggestions you might consider

-cpufreq - change from ondemand to performance
-somehow be able to unbind devices from sharing the same interrupt
-increasing the priority of the audio threads
-if at all possible give MPD a CPU core to itself via affinity
-enable mmap in MPD
Hi Dynobot, I saw you'd done some testing on audioasylum, I was wondering what tweaks you were referring to, so that helps. Was happy to see you had a good experience with it.
  • cpufreq - hadn't heard of that tweak and looks quite simple, will do
  • audio thread priority - my first attempt at this used nice and unfortunately it caused mpd to fail to start on some hardware. I'm looking to do this in the future with chrt, but need to spend some time trying to figure out the best way to build a minimal util-linux package - it's a bit of a clusterf#$!@ to try to build just one piece of it.
  • I'd actually just read about mmap about a week ago, this is on the list to get done soon
  • single core dedicated to MPD is interesting, will explore options there
  • IRQ sharing is the only one that I think will be difficult to tackle, as the behavior varies a lot from platform to platform.
Hi

I increased the thread priorites by adding a script in the my-applications/bin directory
#!/bin/bash
renice -10 3
renice -10 9
renice -10 13
renice -10 16

I tried higher values but settled on -10, -19 being the highest.
~~~~~~~~~~~~~~~

In etc/mpd.conf I added this after the alsa_period line to enable memory mapping

mmap_emulation "true"
~~~~~~~~~~~~~~~~~~~

It looks like the start_cpu_freq file located in /etc/init.d directory can be modified to use performance instead of ondemand. I did not try this yet.

~~~~~~~~~~~~~~~~

These are a few things I use for MPD in a normal setup. Unbinding is great but its really task intensive. Pretty much it just frees up the interrupts to handle a single device instead of having one interrupt having multiple devices on it. Normally I would use a tool called tree to find and then unbind USB ports [its kinda over the top] small reward.

I was not able to dedicate a single core to MPD like I normally do...this give pretty good results. Normally I use taskset -c -p 1 $(pidof mpd) but puppy does not recognize taskset.

Dynobot
Posts: 44
Joined: Wed 05 Dec 2012, 12:04

#89 Post by Dynobot »

Oh one other thing

Swappiness

swappiness can have a value of between 0 and 100

swappiness=0 tells the kernel to avoid swapping processes out of physical memory for as long as possible
swappiness=100 tells the kernel to aggressively swap processes out of physical memory and move them to swap cache

The default setting in Linux is swappiness=60. Reducing the default value of swappiness will probably improve overall performance for a typical desktop installation. A value of swappiness=10 is recommended, but feel free to experiment.

Copied and pasted from: http://linuxpoison.blogspot.com/2010/05 ... z2EEjzD9Ht

EDIT: I am not sure swappiness will do any good. But just an idea.

jonnyc
Posts: 6
Joined: Mon 16 Jan 2012, 16:27

Re: thank you

#90 Post by jonnyc »

ldolse wrote: Regarding the power button, I wish I knew a good fix there myself - I think the reason 0.9.1 works well in that respect is because it's an old kernel with basically no ACPI support. 0.9.2 and 0.9.3 have proper kernel level support, but that means in order to get the power button to work with a single click you need an extra daemon to watch the power button for clicks. One of my goals is to keep extra processes/daemons to a minimum so I decided to live wtih the long press.
Pressing the power botton for 3 sec. simply forces powerdown. After this, next time mpdpup starts it runs a fsck (it seems so).
Is there no risk to damage the ext2 partition, or is it only held in RAM?

regards
JonnyC

BTW: How about adding mpdpup to distrowatch? :roll:

ldolse
Posts: 367
Joined: Fri 23 Oct 2009, 16:33

#91 Post by ldolse »

@Dynobot, will swappiness matter if there is no swap file? I intentionally configured the iso so it doesn't create a swapfile. Thanks for the extra info - I'll bet taskset is also part of util-linux, so I'll add that when I add chrt.

@johnnyc, you can ignore the fsck when you power it down by holding the power button - it does run out of RAM and the fsck isn't required. Puppy Linux has that logic for non-RAM based Puppy installations to prevent kernel panics. mpdPup 0.9.1 was a remaster of a very old version of Puppy Linux which didn't have that safety feature. At some point I need to dig through the startup scripts and make it smarter so that it properly handles a RAM based pupmode and skips the fsck.

I hadn't really thought about putting it on Distro watch - I'm not sure I see the benefit due to the highly niche nature of the project.

Dynobot
Posts: 44
Joined: Wed 05 Dec 2012, 12:04

#92 Post by Dynobot »

Hi Idolse

No I don't think Swappiness will help...to be honest I can't tell even with HD versions of Linux... :shock:

Dynobot
Posts: 44
Joined: Wed 05 Dec 2012, 12:04

#93 Post by Dynobot »

Considering past notions about CPU power usage, it appears that a reduced CPU power is best.

In light of that it may seem counter intuitive but I think the cpu governor frequency should be set to powersave instead of performance.

Performance keeps the CPU at the highest possible frequency
Powersave keeps the CPU at the lowest possible frequency
Userspace exports the available frequency information to the user level (through the /sys file system) and permits user-space control of the CPU frequency
Ondemand scales the CPU frequencies according to the CPU usage (like does the userspace frequency scaling daemons, but in kernel)
Conservative acts like the ondemand but increases frequency step by step

The recent CPUs have a feature which let them scale their operating frequency (changing a voltage power supply input) according to the system/user needs.

http://idebian.wordpress.com/2008/06/22 ... -in-linux/

Or it may be best to just leave well enough alone, this may take some testing and confirmation.

ldolse
Posts: 367
Joined: Fri 23 Oct 2009, 16:33

#94 Post by ldolse »

Dynobot wrote:Considering past notions about CPU power usage, it appears that a reduced CPU power is best.

Or it may be best to just leave well enough alone, this may take some testing and confirmation.
What I would do once implemented is add this into the 'tweaks' section of the wizard so that a user could choose which profile they want. In my mind powersave would probably be best too, at least for users who are using bit perfect NOS. Looks like based on other searches whether this profile does anything is highly variable on the features built into the CPU. A more recent article would be helpful if you come across one. A 2009 article shows that one of the three underlying methods in the article - p4-clockmod - isn't really relevant anymore, the way the Linux kernel moves I wouldn't be surprised if there have been quite a few other changes since 2008 as well.

Dynobot
Posts: 44
Joined: Wed 05 Dec 2012, 12:04

#95 Post by Dynobot »

Hi Idolse,

Don't mean to put so much on your plate....but I have yet another suggestion.

How about having a toggle during setup that would allow the user to do automatic updating. Say each time they cycle their unit [power off and on] MPDPup will look on the server for a newer version, if found it will update and keep the users settings.

I'm kinda just coming up with these as just brain storming ideas so please take with a grain of salt.

jrling
Posts: 47
Joined: Wed 27 Jun 2012, 13:51

#96 Post by jrling »

ldolse wrote:
Dynobot wrote:Just wanted to say great job with this...

Some suggestions you might consider

-cpufreq - change from ondemand to performance
-somehow be able to unbind devices from sharing the same interrupt
-increasing the priority of the audio threads
-if at all possible give MPD a CPU core to itself via affinity
-enable mmap in MPD
Hi Dynobot, I saw you'd done some testing on audioasylum, I was wondering what tweaks you were referring to, so that helps. Was happy to see you had a good experience with it.
  • cpufreq - hadn't heard of that tweak and looks quite simple, will do
  • audio thread priority - my first attempt at this used nice and unfortunately it caused mpd to fail to start on some hardware. I'm looking to do this in the future with chrt, but need to spend some time trying to figure out the best way to build a minimal util-linux package - it's a bit of a clusterf#$!@ to try to build just one piece of it.
  • I'd actually just read about mmap about a week ago, this is on the list to get done soon
  • single core dedicated to MPD is interesting, will explore options there
  • IRQ sharing is the only one that I think will be difficult to tackle, as the behavior varies a lot from platform to platform.
Some great suggestions Dynobot. I have come from Windows CPlay et al which had me incessantly trying to reduce and optimise Windows to be a half-decent Music Transport. Ended up being a total nightmare.

mpdPup is a fantastic starting point for a dedicated Music Player. 66MB running in RAM is a great testament to Idolese.

However, I have found that tweaking mpdPup, which is really simple compared to 'Optimising' Windows, has already shown that it can be tweaked to give materially improved SQ. Thanks to wlowes and now Dynabot's suggestions.

I am sure that there are two types of users:
1. 'Out of the Box'
2. Tweakers

Idolese's approach in the wizard caters for both admirably. Thanks.

I am definitely a Tweaker. I looked at Dynabot's excellent website and its recommendations for tweaking MPD. Unfortunately, most, if not all of the Linux commands that he uses, like Synaptics Package Manager, apt-get, chkconfig, taskset, are not (apparently) part of mpdPup? I am sure that is purposeful in the design to keep the size of the ISO down to minimum.

I look forward to Idolese incorporating some of Dynabot's suggestion into the ISO, but in the meantime,is there any way that mpdPup users can achieve Dynabot's recommendations themselves - especially those without too much Linux experience?

Lastly, I am unclear whether mpdPup (0.9.3) has a Real Time Kernel, which many of Dynabot's tweaks involve?

Many thanks

Jonathan

Dynobot
Posts: 44
Joined: Wed 05 Dec 2012, 12:04

#97 Post by Dynobot »

Hi jrling

Thanks for the kind remarks. I have plenty more suggestions, some may be over the top others might not be worth the effort but I'd like to get them off my chest none the less.

Seeing the Puppy operates from RAM I'd like to see a 64bit version that is able to take advantage of greater amounts of RAM.

For those who link to their music via server IP address, making some tweaks to the Ethernet might improve performance.....see ethtool Linux tweaks to optimize Ethernet traffic.

Not sure if its already been brought up but some might like upsampling....so including Sox would be cool. Having multiple sample rates can be as easy as having multiple outputs...each with the same hw# but with different names and parameters for different sample rates. For example Dac XYZ rate 24/48, Dac XYZ rate 24/96 etc.

Dynobot
Posts: 44
Joined: Wed 05 Dec 2012, 12:04

#98 Post by Dynobot »

BTW, if I can help an any way please let me know.

I appreciate the efforts behind this and am willing to role my sleeves up as well...

jrling
Posts: 47
Joined: Wed 27 Jun 2012, 13:51

#99 Post by jrling »

Upsampling is included. 0.9.2 had Secret Rabbit Code built in and configurable in the audio-output section and Idolese has now included SOX upsampling in 0.9.3 with multiple audio-outputs for each SOX setting.

I find both excellent enhancements to 44.1/16 files, which is all I have.

Keep the ideas coming! mpdPup is an excellent tool and as you suggest I am sure any effort to make it even better, will be rewarded.

Jonathan

ldolse
Posts: 367
Joined: Fri 23 Oct 2009, 16:33

#100 Post by ldolse »

Keep the ideas coming, happy to hear them. Regarding auto-updating, this is something I've thought about quite a bit. It's pretty straightforward to build ad-hoc updates for packages/bug fixes for a particular release - and it's probably something I'll do in the relatively near future. Full-on upgrades is a bit more difficult - on top of more technical VCS challenges just to do it there are major challenges in terms of config migration and regression testing - I'd be opening myself up to a whole class of bugs that as a one man shop I'm not really up for keeping on top of.

As far as help goes, a lot of the work I have to do goes into the research required to follow up on various suggestions, extra detail or testing on specific tweaks on mpdPup itself is a huge help, particularlly when it includes docs on exactly what files need to be changed - this is how Sox was added in the last release as an example. Sometimes this might require installing the developer devx file, but a lot of times you just need to use the Puppy Package manager - util-linux for instance can be installed from there to give a user access to taskset and chrt.

@jrling, most if not all of Dynobot's suggestions can be tested with the current release, though they do require some level of comfort with hacking on Linux. If you have a system which supports XWindows you can use the Puppy Package manager to install util-linux. If your system doesn't support X it's a bit trickier, but still possible. I don't believe any of the suggestions require a real-time kernel.

Edit - added package installation instructions here.

Post Reply