(old)Puppy Linux Discussion Forum

Dynobot wrote:

bonalux wrote:
Forgive my ignorance, but, I cannot find the init.d file you were talking, in the init.d directory can't find the file to define the priorities, can you please give me the path?

Thank you.

look in the /etc directory you will see another directory called init.d, within it you will se a file with mpd in the name, open it and on line 30 uncomment the line for nice

Hi, being on an Alix Board and unable to use startX/XWindow I´d like to hopefully get confirmation, I´m doing this right:

Via Putty I followed Idolse´s instructions in an earlier post (in the old Mpdpup thread) to get to the line for nice:

".....for some reason some hardware doesn't like 'nice' which I've been using to give MPD higher system priority. If this is the case type this command at the CLI:

Code:
nano /etc/init.d/20.mpd

Find the line that says:

Code:
nice -n 15 mpd..." (I found this by typing "Ctrl + V" to get to the next page of the file).

- I uncommented by deleting the "#" in the beginning of the line
- deleted "15" and replaced with "-1"
- ending up with a "nice" line saying: nice -n -1 mpd
(saving and exiting Nano by typing "ctrl-X to exit" and 'Y' to save the change)

Is this correct?

On a sidenote, do any of the Alix and/or usb-powered Dac users use optimized power-supplies replacing wall-wart/usb-power (regulated or battery power)?

Finally thanks to Idolse and the contributors of this thread. MpdPup is for me the best sounding, most versatile and (after initial reading and trial/error) trouble free Pc-based music player (not to mention free too!)

regards, Finn

Hi Idolse,

I have found the issue with empty folders in Mpad.

The fault is in the meta data of the files.
When you put the albums in separate folders and use the " group by directory" setting, it displays the albums by folder.
But when the album tag in one folder is not the same for all music files mpad will create a separate folder for the file with the differing name, but the file itself resides in te other album. This creates empty albums in mpad.

I once again would like to thank you for a very nice player! I am intrueged by the nice settings discussion above and will try it myself.

Regards,

I understand that Puppy Linux does not have a security/limits.conf file.

However the limits can be seen using the ulimit -a command.

They can be set to new values with the ulimit command as well, bad thing is I can't figure out which file to add the command in to set it at boot.

I would like someone to try these two ulimit commands, listen for awhile and post back and difference in sound.

ulimit -l unlimited
ulimit -s unlimited


http://www.linuxhowtos.org/Tips%20and%2 ... ulimit.htm

Fin
You have made the correct change. You can go back in with nano and see what you now have. You can alternatively use the command less instead of nano to simply list the contents of the file.
I always save in nano by using cntrl O then confirm the file then exit. I did not realize you can just exit and get prompted to save. thanks

Dynobot wrote:...
I would like someone to try these two ulimit commands, listen for awhile and post back and difference in sound.

ulimit -l unlimited
ulimit -s unlimited

http://www.linuxhowtos.org/Tips%20and%2 ... ulimit.htm

I have listened to a few of my favorite test songs, and have toggled back and forth on both these settings.

The effect is there, but very subtle. Default on my machine for -l was 64. When set to unlimited there is a change and I'd say for the better. In my case it takes away a bit of ringing and harshness on the highest registers.

Default on my machine for -s was 8192. Unlimited had a smaller effect that -l but it is there. Perhaps a little more ring removed or more likely a softened edge to all transients. Not sure if I like it. Have toggled a fair bit and then tried going to 4096. Liked that less. then back to 8192, better. Tried 16384. Maybe the best. It has more detail than unlimited, but less edge/ring than 8192.

For the record, I run the audio_buffer_size setting in MPD.CONF at 320 and buffer_before_play 12%. This is about the lowest I can go without dropouts. As I go lower, I believe I get better detail and transperancy at the expense of a tendency to inject ringing on highest hz. These limits seem to be a good buffer against that tendency.
Walter

wlowes wrote:Fin
You have made the correct change. You can go back in with nano and see what you now have. You can alternatively use the command less instead of nano to simply list the contents of the file.
I always save in nano by using cntrl O then confirm the file then exit. I did not realize you can just exit and get prompted to save. thanks

wlowes, thanks and you´re welcome

willemoes wrote:

On a sidenote, do any of the Alix and/or usb-powered Dac users use optimized power-supplies replacing wall-wart/usb-power (regulated or battery power)?


regards, Finn

I have upgraded the power supply for the alix board to a linear supply. I did build my own (http://www.amb.org/audio/sigma11/) and the improvement is significant.
But it was even better when I moved from an and alix3 to an alix1 board and there I use an SOTM pci USB card which is powered by a second linear power supply. USB goes into a dcs debussy.

There appears to be no free lunch regarding noise supression ...

wlowes wrote:

Dynobot wrote:...
I would like someone to try these two ulimit commands, listen for awhile and post back and difference in sound.

ulimit -l unlimited
ulimit -s unlimited

http://www.linuxhowtos.org/Tips%20and%2 ... ulimit.htm

I have listened to a few of my favorite test songs, and have toggled back and forth on both these settings.

The effect is there, but very subtle. Default on my machine for -l was 64. When set to unlimited there is a change and I'd say for the better. In my case it takes away a bit of ringing and harshness on the highest registers.

Default on my machine for -s was 8192. Unlimited had a smaller effect that -l but it is there. Perhaps a little more ring removed or more likely a softened edge to all transients. Not sure if I like it. Have toggled a fair bit and then tried going to 4096. Liked that less. then back to 8192, better. Tried 16384. Maybe the best. It has more detail than unlimited, but less edge/ring than 8192.

For the record, I run the audio_buffer_size setting in MPD.CONF at 320 and buffer_before_play 12%. This is about the lowest I can go without dropouts. As I go lower, I believe I get better detail and transperancy at the expense of a tendency to inject ringing on highest hz. These limits seem to be a good buffer against that tendency.
Walter

@Walter

Thank you for the information and test results.

Maybe Idolse can give some insight on how to make the changes permanent between boots. I think everyone will probably like a slightly different number [tuning] although there might be a 'golden ratio' of values.

At this point its a fine balancing act.

Dynobot wrote:
@Walter

Thank you for the information and test results.


At this point its a fine balancing act.

My pleasure
How do my perceived results compare with your own? I am sure is is system specific to some extent.

wlowes wrote:

Dynobot wrote:
@Walter

Thank you for the information and test results.


At this point its a fine balancing act.

My pleasure
How do my perceived results compare with your own? I am sure is is system specific to some extent.

My perception is when in apply both ulimit -s and -l as unlimited the sound becomes a bit more coherent without any sense of edginess that you mentioned. Before there was just a very slight bit.


FWIW, I also removed some processes that were started in the init.d folder that I do not need in my setup.
15.avahi
37.client175
slmodem
start_cpu_freq
25.lcd
40.mpdscribble

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am going through all the processes one by one and removing everything that is not needed to 1) run puppy linux and 2) run mpd.

Notice process 27 for swap....although this OS does not swap. If the OS does not swap then the process must go. Guessing that the udevd daemon is associated with the hard drive polling. Thats 6 daemons that should be stopped....somehow.

# ps -e
PID TTY TIME CMD
1 ? 00:00:01 busybox
2 ? 00:00:00 kthreadd
3 ? 00:00:00 ksoftirqd/0
6 ? 00:00:00 migration/0
7 ? 00:00:00 migration/1
9 ? 00:00:00 ksoftirqd/1
10 ? 00:00:00 kworker/0:1
11 ? 00:00:00 migration/2
12 ? 00:00:00 kworker/2:0
13 ? 00:00:00 ksoftirqd/2
14 ? 00:00:00 migration/3
15 ? 00:00:00 kworker/3:0
16 ? 00:00:00 ksoftirqd/3
17 ? 00:00:00 cpuset
18 ? 00:00:00 khelper
19 ? 00:00:00 sync_supers <-------
20 ? 00:00:00 bdi-default
21 ? 00:00:00 kblockd
22 ? 00:00:00 ata_sff <------IDE hard drive support
23 ? 00:00:00 khubd
24 ? 00:00:00 kworker/1:1
25 ? 00:00:00 kworker/2:1
27 ? 00:00:00 kswapd0
28 ? 00:00:00 ksmd
29 ? 00:00:00 khugepaged
30 ? 00:00:00 fsnotify_mark
31 ? 00:00:00 xfs_mru_cache
32 ? 00:00:00 xfslogd
33 ? 00:00:00 xfsdatad
34 ? 00:00:00 xfsconvertd
35 ? 00:00:00 scsi_eh_0 <------Polling for disk drives
36 ? 00:00:00 scsi_eh_1 <---------polling for disk drives
37 ? 00:00:00 kworker/u:1
38 ? 00:00:00 kworker/u:2
42 ? 00:00:00 kpsmoused
228 ? 00:00:00 scsi_eh_4 <--------polling for disk drives
229 ? 00:00:00 usb-storage
514 ? 00:00:00 loop1
613 ? 00:00:00 loop0
844 ? 00:00:00 udevd
900 ? 00:00:00 kworker/3:2
2994 ? 00:00:00 kworker/1:4
3160 ? 00:00:00 hd-audio0 <--------for internal mb sound card
3463 ? 00:00:00 avahi-daemon
3464 ? 00:00:00 avahi-daemon
3474 ? 00:00:00 sshd
3501 tty1 00:00:00 sh
3502 tty2 00:00:00 getty
3503 ttyS0 00:00:00 getty
3605 ? 00:00:00 udevd
3750 ? 00:00:00 dhcpcd
3766 ? 00:00:04 cifsd
3777 ? 00:34:25 mpd
3788 ? 00:00:00 lighttpd
3805 ? 00:00:00 udevd
3855 ? 00:00:00 kworker/0:0
3863 ? 00:00:00 flush-8:0
3970 ? 00:00:00 sshd
3975 pts/0 00:00:00 sh
4056 pts/0 00:00:00 ps-FULL

Dynobot, wlowes
I both made the change to nice and tried your suggested ulimit settings. Wow, I think that quite some edginess has gone. The change of the -l setting made a quite audible difference.
Thnks, great stuff!

Would be great to know how to make this permanent.

Dynobot wrote: FWIW, I also removed some processes that were started in the init.d folder that I do not need in my setup.
15.avahi
37.client175
slmodem
start_cpu_freq
25.lcd
40.mpdscribble

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I am going through all the processes one by one and removing everything that is not needed to 1) run puppy linux and 2) run mpd.

Notice process 27 for swap....although this OS does not swap. If the OS does not swap then the process must go. Guessing that the udevd daemon is associated with the hard drive polling. Thats 6 daemons that should be stopped....somehow.

I have removed a bunch of stuff from init.d in the past, and added a startup script I named walter_startup that had a bunch of module deletions from earlier recommendations.

Getting rid of 15.avahi was easy as I could just rm the file. ;BTW, I rebooted and the impact was great. Expanded sound stage and very musical.

I still have
37.client175, and
40.mpdscribble

to kill. I cannot for the life of me remember how to insert and remove these files or how I put in my startup script.?? tried update-rc .. no such command. Can you remind me how this is done in puppy?

Put your scripts path in /etc/rc.d/rc.local

Make sure its executable

to kill init.d processes just put the path of the process including the process followed by stop

ok - took the next steps and removed the above items from init.d.
Also killed off Albumbler. I do not use it.

Sound is very good. I updated my startup script which is in init.d to renice kpmoused to 10 and mpd to -19. This now works on startup. I added the
ulimit -l unlimited command to this script. Not successful. Perhaps it is executed too early in the startup. So we are still searching for a way to make this permanent.

deleted

willemoes wrote: On a sidenote, do any of the Alix and/or usb-powered Dac users use optimized power-supplies replacing wall-wart/usb-power (regulated or battery power)?

I've upgraded from cheap PSU and usb powered WaveIO to self powered Alix and Wave and the difference in S.Q. is very noticeable, highly recommended this upgrade.

Regarding renice, i've done the same as you but didn't got the time to listen well this changes.

Regards.

lugili, bonalux

Thanks; I´m comtemplating on battery and/or regulated power suplies for Alix and usb-Dac QNKTC AB-1.2 USB DAC (highly recommended!)

(first try will probably be 12V battery supply for the Alix)

regards, Finn

Thread has been busy - didn't see all these updates til the other day.

@Mark Van de Pas, your post about improvements is appreciated and thoughtful. Regarding Tiny Core Linux, I haven't checked it out. Not that I'm opposed to it and similar Linux variants, but when I originally looked for distributions to optimize Puppy Linux was the one that hit all the right notes:

• Read only file system that's fairly transparent to users
• Lots of remastering/building tools allowing contributors to spin their own variants (with an active community supporting this)
• Minimal OS footprint to start with
• Minimal X GUI for users averse to the CLI

There are a variety of other distributions that perform better at various pieces of this puzzle, and Tiny Core definitely hits all the right notes on the minimal part, but I'm not sure how well it meets the other requirements. And because it starts from a completely different premise it's hard to know which parts of it's configuration would be worth translating over to Puppy.

@Dynobot, wlowes - regarding nice in the mpd startup script, I see now I forgot to add a dash in front of the 15 in the init file, but is there a specific reason to choose -1 vs. -15 or higher?

About ulimit - this one is pretty interesting, and one I hadn't read about before. This seems like it should be straightforward to add to rc.local or a similar location.

Regarding the startup scripts in /etc/init.d - I'd like to point out that most of those are disabled by default - Puppy linux only starts init scripts which are marked executable, and most are not marked that way. Any that you do want to disable you can just run chmod -x instead of deleting them.

Regarding the various processes to kill, I'd like to understand what causes them to be started in the first place rather than just kill them after the fact - anything swap related can definitely go (problem is I don't know what starts it). udev related processes probably need to stay, but can be reniced. Avahi-daemon is included quite intentionally for user friendliness (and was compiled for bare minimum footprint), but also can be reniced.

@everyone else providing info on processes to renice - all the tips are appreciated and will be noted. I'm thinking of an init script which will re-nice a laundry list of processes after everything has been started.

@supersurfer, thanks for the update regarding mPad, I'll have to see if I can fix my own albums by fixing the tags.

@Idolse

I trired putting the ulimit command inside every place I could imagine. But non of them 'seemed' to work. I say seemed because when I change the ulimit via a shell and do a ulimit -a to see the change it shows....however if I close the shell, then reopen and do a ulimit -a the default values show up.

Also I did install util-Linux and was able to set cpu affinity.

As far as the init files I agree the best way is not to delete them but to do a -x, or even better open X and use PuppyLinux's own tools to configure which processes in the init file will be executed.

I installed a fresh copy on MPDPup and tried to do things cleaner and tested the 'tweaks' with more of a methodological approach. One at a time instead of on top of one another and adjusted nice values and listened for a change. To be honest most changes are barely noticeable if at all...

I too have been reading and experimenting where to put ulimit command at startup.

I tried at the end of my startup script which is last in the init.d list. No luck.
Then I tried in the 20.mpd startup right after the renice. Also no luck.

The thing that surprises me most is I leave my system on 7x24. Every evening when I come to listen, ulimit -s & -l are back to the default. I set them to unlimited and the next day they are back to the default.

I can't imagine I get a power failure everyday. Is it possible that logging on to root via ssh or connecting to mpd via a client somehow involkes a script that sets the default?