mpdPup - Simplified MPD Music Server/Jukebox - v0.9.3
Unetbootin and dd
hi there,
a stucked a little bit with my cuty little pcs. they all hava ide flash drives with 256 mb.
i downloaded mpdpup 0.9.3 and tried to copy it with unetbootin using ubuntu 12.04. after creating a fat32 partition with gparted, i had no chance to install mpdpup on it. there was simply no option within unetbootin. so i tried the same with windows xp on this machine. also no option for this internal drive.
(i was able to mount it, and also windows showed me the drive, but unetbootin wasn't able).
next try was using dd. first i wrecked my partition table on this drive by using:
dd if=/home/user/downloads/mpdpup-0.9.3.iso of=/dev/sdb
after this, the drive couldn't be mounted at all. so i created a new partition table, also with gparted and tried to write directly to the fat32 partition with:
dd if=/home/user/downloads/mpdpup-0.9.3.iso of=/dev/sdb1
this time it worked better. the device is mountable and it also shows its data. but yet i'm not able to boor from this drive.
any further ideas? thank a lot.
a stucked a little bit with my cuty little pcs. they all hava ide flash drives with 256 mb.
i downloaded mpdpup 0.9.3 and tried to copy it with unetbootin using ubuntu 12.04. after creating a fat32 partition with gparted, i had no chance to install mpdpup on it. there was simply no option within unetbootin. so i tried the same with windows xp on this machine. also no option for this internal drive.
(i was able to mount it, and also windows showed me the drive, but unetbootin wasn't able).
next try was using dd. first i wrecked my partition table on this drive by using:
dd if=/home/user/downloads/mpdpup-0.9.3.iso of=/dev/sdb
after this, the drive couldn't be mounted at all. so i created a new partition table, also with gparted and tried to write directly to the fat32 partition with:
dd if=/home/user/downloads/mpdpup-0.9.3.iso of=/dev/sdb1
this time it worked better. the device is mountable and it also shows its data. but yet i'm not able to boor from this drive.
any further ideas? thank a lot.
Re: Unetbootin and dd
Hi jonnyc, Unetbootin doesn't work with internal drives, it only works with USB drives.
Just install to a USB stick as per the instructions in the first post. Once you've booted off the USB stick you can use the Puppy Linux installers to install to the internal drive. I've written some other posts on how to use the installers, not sure exactly where they are as I write this, either earlier in this thread or in the 0.9.2 thread.
Just install to a USB stick as per the instructions in the first post. Once you've booted off the USB stick you can use the Puppy Linux installers to install to the internal drive. I've written some other posts on how to use the installers, not sure exactly where they are as I write this, either earlier in this thread or in the 0.9.2 thread.
@jrling, 176/192Khz doesn't work automatically with some sound cards, it's some low level ALSA issue that I haven't gotten to the bottom of. Simplest fix in most cases is to unplug the sound device and re-plug it in - this only needs to be done once each time you boot the system. For whatever reason re-initializing the hardware that way resolves it, at least on my hardware. Other users have reported no problems whatsoever with these higher sample rates.
Hi Idolse and waveio users. In version 92 the unmute file of the previous thread works with my waveio. In version 93 is unmuted at start. Even when i restart mpd, remains that way. Don't know if it's the configuration of waveio i have or something else. I use independent power supply (not the usb supply), cutted the 5 v wire of the cable from pc to waveio pin usb input and non isolated I2S to DAC with all U.fl grounds connected. Firmware not updated. Any thoughts?
Regards
Regards
Idolese
Thanks for the clarification.
I am using the dreaded WaveIO USB/SPDIF board which has caused you so much heartache with Unmute.
Have any other WaveIO users found the same issue as I have?
I don't keep my system on all the time and so having to do what you suggest every time I boot up would be irritating.I will post up the issue on the DIYAudio WaveIO thread to see if there is any fix.
Thanks for the clarification.
I am using the dreaded WaveIO USB/SPDIF board which has caused you so much heartache with Unmute.
Have any other WaveIO users found the same issue as I have?
I don't keep my system on all the time and so having to do what you suggest every time I boot up would be irritating.I will post up the issue on the DIYAudio WaveIO thread to see if there is any fix.
Almost all WaveIo users have the same problem as you (included me), but is easily solved with the procedure previously posted by Idolse
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.
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.Type the followingat the command line:
Then paste the following into the editor:Code: Select all
nano /etc/init.d/unmute
press ctrl-x to exit, then y to save the script.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
Lastly type this command:Then run "alsamixer", unmute the card, exit and type:Code: Select all
chmod +x /etc/init.d/unmute
before using 'save2flash' or a full reboot.Code: Select all
alsactl -f /etc/asound.state store
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.
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.
Installation on a Harddrive / IDE Flash Device
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...
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...
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:
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.
@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
thank you
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.
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.
Re: thank you
Glad to hear the istructions worked.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.
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.
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
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.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
- 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.
Hildolse wrote: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.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
- 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.
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.
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.
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.
Re: thank you
Pressing the power botton for 3 sec. simply forces powerdown. After this, next time mpdpup starts it runs a fsck (it seems so).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.
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?
@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.
@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.
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.
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.
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 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.
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.
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.