@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.

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.

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?

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.

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.

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

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...

@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.

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?

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.

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 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.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum