I believe DLNA/RAOP will allow lossless audio to be transmitted across the network

True. Compared to some other streaming protocols and proprietary devices that might be considered impressive, but by MPD standards that's no big deal! The built-in HTTP streaming of MPD allows any valid audio format. In this regard, MPD's built-in streaming should be considered native ie. the same standard as the source audio files.

This has ramifications for high-resolution audio files: MPD will happily stream them, but your network might not cope with the data rate, especially over wifi!!
For example I anticipate obtaining at least some of my music in the future as 192kHz/24bit flac files. These might be difficult to stream over wifi, and it might be necessary to have some form of wrapper script which will automatically activate LADSPA to down-sample high-resolution files in streaming output situations.

Yes, any greater than 24/48 on wifi is probably not going to be pretty When more users get to that point I guess we'll need to ask for some down-sampling features - probably doable already if you create dedicated outputs, but it would be nice to allow dynamic sample rate switching up to a certain value and stopping there.

Hi
First of all, congratulations for the good work. I have often wished there were such a project, and now I am trying to test whether it will suit me completely.

I am using an old HP laptop with WinXP on it, booting from a CD. It didn't work for me "out-of-the-box", but I have some experience with linux and mpd and hope to get it going finally, maybe with a little help.

Currently I am at a stage where mpd refuses to start because it can't find files under /mnt/home/mpd. I guess this is where the filesystem created at install time on the XP NTFS C:\ should be mounted, but it is not. Instead the actual NTFS drive is visible at /mnt/home, together with the .2fs and .sfs files created at 'installation' time. I might have done something wrong - but what?

I know from experience that in cases like that it is usually best to start over. I guess for this I have to delete the two files created and boot the CD again. I'll try this soon. Is there another/better way to start all over again?

One more note. In my case I have the music on the laptop's hard drive and I plan to use the NTFS drive (D:, /dev/sda2) as a music directory. I hope that won't be difficult to setup, but it would be nice to have this option in the configuration wizard - actually it seems to me the more natural scenario to have the HDD with your music attached to the always-on audio server, instead of having another machine always on and rely on the network.

And finally - or should I have started with it - is this still the best place to discuss mpdPup?

Hi, Thanks for giving things a shot with this. The 'out of the box' experience only works if you follow the instructions using a USB stick or some sort of bootable flash drive. /mnt/home/mpd is automatically created in that situation.

Doing what you've done from CD is possible, but you need to create an mpd directory on your actual filesystem manually, and I haven't tested extensively how this directory will show up to Puppy Linux in this scenario - based on your description it sounds like it worked as I would expect - you say you're seeing your C drive files under /mnt/home, correct? If this is the case just create an mpd folder and an mpd/playlists folder in the root of your C drive.

The logic behind all this btw is that the files Puppy Linux creates are all read-only - the actual MPD database lives outside the file system in read-write land - if we can get it working it would be on your C drive, which sounds like it should work fine.

You'll also need a couple tweaks to handle the music all on your D: drive - at the moment mpdPup is hard-coded to expect the files will be on a network share - another item on my to-do list is get local storage working with the setup wizards. I think you'll need to add /dev/sda2 to your /etc/fstab file so it's automatically mounted when your system boots up. - if you have this automount to /mnt/music it would basically work with the wizards and you probably won't need to edit mpd.conf manually. Let me know if you need more help with editing the fstab file.

May I ask what you actually did to get mpdPup installed on your C drive? Did you go through the Puppy Linux frugal install process and you're getting some sort of GRUB/Lilo boot manager now? It's actually been on my to-do list to document how a user would go about doing exactly what you've just done, and possibly update the frugal install scripts to automatically create /mnt/home/mpd in that case.

Manually creating the mpd directories on the /dev/sda1 NTFS partition worked and now mpd starts OK. Still I believe it should somehow get into the pup_save filesystem and not 'polute' the windows volume.

I also added /dev/sda2 mounting at /mnt/music to fstab, deleting the wizard-created line, and it also works.

I'll continue playing and testing and will come back here if necessary. Two questions pop up immediately:
-- would it be possible to have some web-based mpd client running on the same box in order to make it a complete solution requiring only a web browser to control
-- is there some possibility for suspend/hibernate to be able to turn off the device with quicker resume

I didn't install mpdPup on the hard drive, I am booting from a CD. I am only keeping the .sfs and .2fs files on the hard drive, in the NTFS partition. I am testing and evaluating for now, I might actually try to install it later on.

I knew nothing about Puppy Linux, so I had to do some reading. The architecture seems to be very elegant when it works, but harder to debug when not. It seems to me there is a general problem in my scenario as the PUPMODE is 13, while according to what I read it should be 12. Or maybe I have to do some more reading...

Manually creating the mpd directories on the /dev/sda1 NTFS partition worked and now mpd starts OK. Still I believe it should somehow get into the pup_save filesystem and not 'polute' the windows volume. With the read-only fiileystem design it's not generally possible to avoid polluting the save file drive (unless you have a very static music library that you only update rarely). Putting your save file on a USB flash drive would put /mnt/home on the flash drive, so that would be one option I can think of.

I also added /dev/sda2 mounting at /mnt/music to fstab, deleting the wizard-created line, and it also works.

Excellent, glad to hear it's working! Regarding polluting the C drive, that's basically required because of the read-only file system design mpdPup is using - anything which needs to be dynamically written to needs to be outside the Puppy filesystem. If your music library is basically static it would be possible to move the MPD folder into the filesystem under /root/, but any updates to the DB would need to be manually sync'd to the save file on disk. Another option would be to put the save file on a USB flash drive - /mnt/home will then map to the flash drive instead of the C drive.

emilt wrote:

-- would it be possible to have some web-based mpd client running on the same box in order to make it a complete solution requiring only a web browser to control

It's completely possible, but most of the existing web GUIs require PHP to be installed - I haven't gotten around to building that for mpdPup/Lighttpd, but it's on my to-do list over the next couple months. If you wanted it more urgently I imagine there is probably a .pet somewhere on these forums you could hack to get working.

emilt wrote:

-- is there some possibility for suspend/hibernate to be able to turn off the device with quicker resume

I dabbled with this a while back and never had much luck - I think the older kernel that this build is using may not have great support for it. Bootup is pretty quick if you're booting from a hard disk or flash, so it hasn't been too much of an issue for me, but it's something I'm also planning to dig into - the build I'm working on now uses the 2.6.39 kernel, so it may be more doable.

emilt wrote:

I didn't install mpdPup on the hard drive, I am booting from a CD. I am only keeping the .sfs and .2fs files on the hard drive, in the NTFS partition. I am testing and evaluating for now, I might actually try to install it later on.

I knew nothing about Puppy Linux, so I had to do some reading. The architecture seems to be very elegant when it works, but harder to debug when not. It seems to me there is a general problem in my scenario as the PUPMODE is 13, while according to what I read it should be 12. Or maybe I have to do some more reading...

Ah, ok - just booting off the CD makes more sense then. The reason for forcing PupMode 13 is to guarantee the filesystem is read only, this way you don't need to worry about graceful shutdowns - treat the system just like any other piece of stereo gear. It also makes the whole system run completely from RAM, which is good if you're trying to take local disk access out of the equation during playback. Puppy Linux takes a bit of getting used to because of the whole layered filesystem concept, but once you understand that things start making more sense. Pupmode 12 makes the save file read/write, which then requires proper 'safe' shutdowns to avoid the risk of kernel panics from corrupted filesystems.

Obviously the filesystem is not completely read-only now, because then I wouldn't be able to save and keep my changes to /etc/fstab.

If I understand right, you are somehow (how?) forcing PUPMODE 13 in a situation where it would default to 12, and this is in order to avoid corrupting the filesystem when not properly shut down.

Am I right to suppose that if the PUPMODE were 12, then the savefile's filesystem would have been mounted at /mnt/home instead of the host drive? And the system would work fine as long as it is always shut down properly and the savefile is re-written to disk?

I am not sure if I have the time, but I would like to start looking at some things in more detail(php, power management, configuration). Would you be interested in sharing your working build so that I or anyone else could help with testing and maybe more?

The filesystem is actually read/write all the time, but any changes you make are only sitting in RAM unless you manually save them to the save file. Changes made in top level RAM layer of the file system are only committed to disk when you run the 'save2flash' command - this syncs any changed files in RAM to the actual savefile on your C drive (or wherever it's stored). Save2flash is run at the end of the mpdPup setup wizard and also when you do a graceful shutdown using the shutdown/reboot commands. The current version queries you whether you want to save the changes, but I think I'm going to go back to automatically saving the changes any time someone actually shuts down/restarts from the CLI.

The desktop oriented versions of Puppy Linux make the above automatic - generally by mounting the save file at the top layer of the file system instead of RAM (Pupmode 12), or periodically syncing the savefile (default desktop oriented PUPMODE 13). I've made mpdPup a little different in the attempt to make it more like an appliance and also more audiophile oriented.

As you correctly inferred, I do force PUPMODE 13 during the boot process,. This is not a trivial thing to change for the livecd (though not terribly difficult to change on your system once you understand the process, I can dig up a link with instructions if need be)

Even in PUPMODE 12 the save file needs to sit somewhere outside the original Puppy filesystem (the .sfs file), as that's a squashfs file and is truly read only - the .2fs file is just an ext2 filesystem in a file that is read/write. That's why you have the two files on your C drive - the .sfs was optional, but the wizard prompted you to copy it there to speed reboots - you could safely delete this file and the system would go back to fully using the CD to boot. The .2fs file can't be removed though as that's where all your changes/config are stored.

I've preferred this approach over systems where you need to manually mount/remount the filesystem in read/write mode - e.g. Voyage linux, since it takes most of the burden of understanding filesystem handling off the end user.

If you really want the C drive to be clean I strongly recommend taking a USB flash stick and dedicating it to this until you're ready for a more complete installation - the first post provides the install instructions using unetbootin. This way everything stays on the flash drive and all you need to do is make sure your BIOS gives USB boot priority - if USB boot isn't supported you can still keep all the files on the USB flash instead of the C drive.

I'm happy to share the in progress build - I've done a lot of work with that build to make it easier for others to hack on. I'll upload it later today and PM you the link - it's nearly ready for release, real life has just gotten in the way of my hobbies the last month or so - need to finish a couple init scripts. I'm also thinking about getting a repository uploaded so others can build their own system from scratch and contribute changes back - still a lot on the to-do list.

after several days of trying to get Voyage Linux to Work, I was very happy to find your solution. It took half an hour to get mpdpup to run. Actually I'm running it on three ITX devices to stream music in each room.

By configuring the mpd build-in http-stream, I have something about 500ms difference between the boxes. Do also know the problem? Is there a way to fix this by adjusting the buffer size? Or is there a different way to synchronise multiple mpd devices. With running Sonos there is no hearable delay between the devices.

Glad to hear it's working for you. It might help if you described what you're trying to do in a bit more detail - are you saying that one of your boxes is actually an mpd server, and the other systems are consuming the http output of the first as a radio station?

This is the only discussion on synchronizing outputs that I've seen, which indicates it's an acknowledged issue, but more along the lines of a feature request:
http://musicpd.org/mantis/view.php?id=2503

If you're using HTTP as described I would think that might help work around those issues, but it's possible network latency is causing more difficulty.

Several other system settings can be changed from the setup wizard such as date/time, etc.

Config files are automatically modified for any advertised feature

Other Changes

mpd 0.16.6

libmdpclient 2.6

Latest secure version of SSHd

nano is built in so you don't need to learn vi if you're editing from the CLI

Many others I've forgotten

Right now empcd, lcdproc, and the wizards are set up to work with Soundgraph iMon LCD/Remotes which are popular with a lot of OEM case manufacturers, but all the infrastructure is there for supporting any LCD or event input device. Let me know other ways of using these functions that would potentially apply to other users and I can update the wizards/config files to accommodate those use cases.

I patched empcd to handle the multimedia keys that are in use on the iMon remote control and other multimedia devices. My changes are posted on Github here, as I haven't received any replies from the original empcd author.

Its not a big deal, because usually you put different boxes in different rooms. So even on a party situation it should work fine.

From other people, which use the Sonos system I've learned that there is no hearable latancy between two boxes. And Sonos uses a special way of wifi.
I thought that if I use mutliple mpd devices that are connected to a wired lan, they should also work synchonous.

btw: I also have an USB Headset configured as a second output device. There is also a small latancy between the audio jack and the usb device...

Its not a big deal, because usually you put different boxes in different rooms. So even on a party situation it should work fine.

From other people, which use the Sonos system I've learned that there is no hearable latancy between two boxes. And Sonos uses a special way of wifi.
I thought that if I use mutliple mpd devices that are connected to a wired lan, they should also work synchonous.

btw: I also have an USB Headset configured as a second output device. There is also a small latancy between the audio jack and the usb device...

Ok - sounds like you have it configured as good as it's going to get for now. I think you'll need to petition the actual mpd development team for any further improvements, they tend to watch the mailing list and the bug tracker most closely. I'm guessing the Sonos systems must use NTP to keep their clocks synchronized and then include some timing data about when to play what in the streams themselves, and mpd doesn't have any of that today.
Glad it's working for you overall.

Thanks in advance_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Enginesor use DogPile

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