OLD: mpdPup - Simplified MPD Music Server/Jukebox - v0.9.2

For talk and support relating specifically to Puppy derivatives
Message
Author
bestiabugblatta
Posts: 6
Joined: Fri 30 Sep 2011, 09:01

#31 Post by bestiabugblatta »

I definitely found the cause: it is the Alix board.....I moved the Juli@ on my desktop PC, booted from a live CD (ubuntu), and it works.....

I still don't know if it is my board defective, or the Alix board itself is not compatible with Juli@.

I will try to find out...

Thanks for your support!!!

Ciao
Bruno

bestiabugblatta
Posts: 6
Joined: Fri 30 Sep 2011, 09:01

#32 Post by bestiabugblatta »

Quick update: Juli@ mounted on Alix board works well if connected via S/PDIF to an external DAC. No sound through analogue outputs....

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

#33 Post by ldolse »

Odd, but glad to hear you were able to find some way to make it work. Maybe you should see if you can force the card to a different IRQ.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#34 Post by tempestuous »

ldolse,
I just want to applaud your efforts to provide a full out-of-the-box solution for a Linux MPD server.

In early 2008 I set up a small music server based on Intel mini-ITX, running MPD under Puppy Linux 3.0, outputting the audio locally through a Chaintech AV-710 sound card. This budget sound card was claimed to have audiophile credentials when configured so that its Envy 24HT-S chip redirected the main (front) audio outputs to the rear output circuitry, which then took advantage of a the sound card's well-regarded Wolfson D/A converter.
With high expectations I eventually connected this system to a friend's uber-expensive hifi system, but I was disappointed to find how far short the audio quality was compared to their high-end CD transport and DAC.
I now realise I was expecting too much from a budget sound card.

Almost 3 years later, I note with interest that you're using the ESI Juli@ sound card, which the hifi forums seem to constantly recommend these days.
My next foray into computer audio will involve MPD on a server running some form of embedded OS, with a yet-to-be-decided high end USB DAC providing the audio output.

J.Allen wrote:I'm a bit surprised there isn't a queue of frustrated audio enthusiasts, Linux wannabes, much like myself standing in line to shake your hand.
I'm not surprised - this application appeals to audio enthusiasts/hifi enthusiasts, and such people are not necessarily conversant with Linux.
On the other hand, the average Linux enthusiast is not necessarily an audio enthusiast, and their music requirements are likely to be satisfied by a less complicated and more mainstream music player application.

So we're talking about two minority groups; audio enthusiasts and Linux users, and this application (MPD) is generally known to the rare group of people who overlap those two minority groups!

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#35 Post by tempestuous »

For visitors to this forum thread confused by what all the hype about Music Player Daemon is about, let me try to explain:

MPD is a music client/server playback system. The main MPD application is the server, which includes a proper database.
Separate client applications, of which there are many available, connect to the server, and control playback.
In the most basic configuration, you can run both the server and a client on the same computer. In this setup, MPD appears little different to any other music player. But things start to get interesting once you separate out the server from the client;

- The configuration that most users seem to employ is with a second "livingroom-friendly" computer used as the client, connecting over the LAN to the MPD server somewhere else in the house. Here the server sends an audio stream to the client, as requested by the client. The client computer acts as both the controller and the audio output device. This can be particularly useful if the client computer is a portable device such as a tablet.

- The second common configuration, my personal preference, is where the the MPD server outputs audio, itself, and the client computer is just a controller. You could use a small tablet computer (any operating system) as the client device, which will effectively then be a "glorified remote control".
The MPD server must have some form of audio card (or external USB DAC) which is connected directly your hifi equipment. Since hifi equipment is typically in a fixed position, portable audio output has no real benefit ...
but it's useful to be able to have the controller portable, particularly if your livingroom listening area opens onto different areas of the house such as the Out house, for example.

- from there you can start to get really complex with configuration - a third computer can be set up on the LAN purely for audio output. Commercial vendors are starting to refer to this type of device as the "media renderer". This output device is the destination point of your audio output, but the server remains centralised, and the controller (client) also remains separate.

And from there, any number of clients and output devices can all connect to the same server!
Not many people would require this level of complexity, but it shows how powerful the MPD system is.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#36 Post by tempestuous »

Functionality and Hifi.

There are two particular appealing factors of the MPD system: it provides very useful functionality, both in terms of playback configuration and music management, and it's also a good foundation upon which to base a high-fidelity computer-based music system.
So the appeal of MPD is not limited to hifi buffs, but the system appeals particularly to hifi buffs.

For audiophiles who wish to optimise their Linux MPD configuration for audio quality, a major element is to ensure bit-perfect digital output to the sound card or DAC, as such:
i) ensure that MPD will not use its software mixer. In your MPD configuration file, /etc/mpd.conf
make sure that this line is commented out -

Code: Select all

mixer_type                      "software"
and ii) the "dmix" function of the ALSA audio system should be disabled. Create a new document in Geany with this -

Code: Select all

pcm.MYSOUNDCARD {
   type hw
   card 0
}
and save it as /etc/asound.conf

aragon
Posts: 1698
Joined: Mon 15 Oct 2007, 12:18
Location: Germany

#37 Post by aragon »

One thing i've allways loved about mpd was the simpleness?!? of configuring and controlling an shoutcast output. I've used this setup for parties as an example, where the controller streams to a number of receiver (In this setup audiophile quality is not the main argument).

aragon

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#38 Post by tempestuous »

Yes, two of the configurations I explained above involve streaming over the LAN, but I used the built-in HTTP streaming
option of MPD, not the ShoutCast streaming option.
I confess that I don't know the relative benefits of each.

aragon
Posts: 1698
Joined: Mon 15 Oct 2007, 12:18
Location: Germany

#39 Post by aragon »

I tested both, inbuild and shoutcast, both worked, but as i allways used shoutcast ...

Aragon

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

Appreciate the votes of confidence

#40 Post by ldolse »

Hi Aragon, Tempestuous,

Appreciate the votes of confidence/feedback, along with the background on Music Player Daemon for the uninitiated. My initial target audience was people looking to hook this server up to their stereo directly and control it remotely - my favorite remote control is mPad on the iPad, but this project has forced me to learn about many other clients and I must admit I have some new special purpose faves. The setup wizards built into mpdPup follow the best practices Tempestuous mentions regarding disabling dmix, etc and outputting bit-perfect output via whatever audio interface the user chooses.

That said, shoutcast/http out support is compiled in as well. Right now the wizards I've written don't provide a simplified setup for that, but it's simple enough to enable for anyone comfortable with editing mpd.conf. A longer term goal is to expand the wizards to allow different types of outputs. I've also seen hints that some of the mpd devs are working on DLNA and RAOP support, which would provide an exciting addition for higher quality network broadcasting than the current shoutcast/http functionality.

Regarding the take-up, I'm probably also a bit late to the game with mpdPup - as Tempestuous notes, this is probably of interest to a relatively small cross-section of users, and many of those users are using Voyage Linux. I'd actually started on this project a couple years back, but when a Voyage variant dedicated to mpd came out I put things on the back burner. It was only much later when I'd tried Voyage and decided it was still too technical for a typical Windows/Mac user that I came back to this project, since many of Puppy's goals around ease of use coincide with my goals for this derivative.

I've been busy working on the next release, and am quite excited about where it's going. It's using the 2.6.39.4 kernel, which now includes remote control support. So the next update will have out of the box support for any Soundgraph iMon remote control/LCD, and other remote controls will work with minimal effort. I'm also adding two new clients, albumbler and mpd-sima. These are all working quite well to provide automatic DJ/smart shuffle capabilities, especially when combined with the new remote control function - I've already got this all working, just need to fine tune my init and remaster build scripts.

My stretch goal is to add a radio station index. I've found an index which provides access to several thousand stations, I just need to write some scripts to parse the index files to allow users to browse the selection, add them to MPD's playlist folder, and assign them to remote control hot-keys.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#41 Post by tempestuous »

ldolse wrote:I've also seen hints that some of the mpd devs are working on DLNA and RAOP support, which would provide an exciting addition for higher quality network broadcasting than the current shoutcast/http functionality.
That's interesting. In the past I have asked associates of mine with more technical knowledge than I about how and why certain streaming protocols can be "better" than others. I remain dubious about whether some of these protocols are necessarily "better" in a technical sense, though they may be better in the way they include metadata.

I just did a Google search for "Music Player Daemon DLNA" and I get these two MPD developer links -
http://comments.gmane.org/gmane.comp.au ... devel/2050
http://comments.gmane.org/gmane.comp.au ... devel/2048
It appears to me that the MPD patch under discussion doesn't add DLNA-streaming per se, but rather it adds header information to the standard HTTP stream so that a particular brand/model of UPnP media renderer (Naim UnitiQute) will accept the stream.
The Naim UnitiQute, by the way, is over $2000!

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

#42 Post by ldolse »

I may be wrong, but I believe DLNA/RAOP will allow lossless audio to be transmitted across the network vs. the compressed options that I believe are all that's supported today. LPCM is the DLNA 'standard' for home devices, though other codecs are allowed and I'm not sure how it will be implemented in mpd for now.

There are a lot of DLNA renderers that are more inexpensive than NAIM (built into many new TVs and other media center devices), so hopefully however the patch finally gets implemented it will be vendor agnostic. Anyway it's progress.


DLNA formats:
http://www.dlna.org/industry/why_dlna/key_components/media_format/

I believe RAOP only allows Apple lossless or PCM:
http://git.zx2c4.com/Airtunes2/about/#audio-packet


The thread you linked was the same one I recently read on DLNA. Here's the one on RAOP:
http://sourceforge.net/mailarchive/message.php?msg_id=28146118

aragon
Posts: 1698
Joined: Mon 15 Oct 2007, 12:18
Location: Germany

#43 Post by aragon »

as stream directory

http://dir.xiph.org/index.php

might be good (as used with streamtuner for example).

aragon

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#44 Post by tempestuous »

ldolse wrote: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.

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

#45 Post by ldolse »

aragon wrote:as stream directory

http://dir.xiph.org/index.php

might be good (as used with streamtuner for example).

aragon
Thanks for the hint on Streamtuner - I wasn't aware of what that particular app did, though I'd seen it in several puplets. Streamtuner isn't sufficient for my needs as it's unmaintained and doesn't have a cli version, but that led me to a newer project called Streamtuner2. It can be used either from the GUI or the Console, so that meets the requirements for any apps I bundle into this livecd. It doesn't seem to have explicit support for mpd, but that should be simple enough to rectify. Saves me from completely re-inventing the wheel.

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

#46 Post by ldolse »

tempestuous wrote:
ldolse wrote: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.

emilt
Posts: 3
Joined: Thu 29 Dec 2011, 08:01

#47 Post by emilt »

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?

Regards
Emil

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

#48 Post by ldolse »

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.

And this is the best place for support queries at the moment, yes.

emilt
Posts: 3
Joined: Thu 29 Dec 2011, 08:01

#49 Post by emilt »

Thanks for the help!

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

Regards
Emil

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

#50 Post by ldolse »

emilt wrote: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.

Check out the How Puppy Works article for some good background info.

Post Reply