Hi Jean-Louis, playing back 100% from RAM is technically possible, but not particularly convenient today. The /tmp/ directory is essentially a RAM disk, anything copied to that directory will be stored in RAM but will never be saved to disk under any circumstances. One could configure MPD to follow symlinks from the music library. Then add a symlink to /tmp/music_location, and have MPD update the database for that directory. When it plays back that album it would do it from RAM.Jean-Louis P wrote:- is it possible with Mpdpup to use RAM as a local cache, feeding all music from the local or remote HDD to fast memory, as CMP does. If yes, how must the system be customized ?
- same question with an additional cache level with a small SDD ? It would not have to be so big : just the content of the current album.
In the second option, if would be quite straightforward for the ones like me who use an old laptop/netbook to replace former HDD with SDD as all the OS is on the CF card.
One of my somewhat higher priority goals for a future release is to make all the above automatic for USB sticks with albums on them. Basically the idea is to put your playlist for critical listening on the stick. There would then be a script triggered whenever USB storage was plugged in that would search for audio content to load into /tmp, automatically update MPD, and possibly even begin playback automatically.
MPD itself doesn't have any RAM disk logic natively, and using a large buffer is a bit of a hack that I'm not confident even works as everyone believes. The MPD core developers don't seem to have much interest in RAM playback, so solutions like the one above are probably the best for now.
A small SSD could also be used, the steps would need to be roughly the same to leverage it - basically include a symlink to the SSD music directory in the MPD music folder. The bonus with SSD is the audio data would persist across reboots. If you installed mpdPup to SSD this directory would just be under /mnt/home
It's very straightforward to install mpdPup directly to an SSD - you just need to use other Puppy Linux install/setup wizards to do a Frugal install to the SSD. I've put instructions up for other users on this topic, if you can't find those instructions let me know.
Hi Magellan, Glad you were able to get it to work. Various buffers can be changed using mpdwizard under the audio->Tweaks section. Not sure which specific buffer you want to tweak. They can all be tweaked manually as well of course.Magellan wrote:These commands didn´t work, or at least I couldn´t make them work I however borrowed a HiFace Evo the other day, and tried to figure out if it was possible to install the linux driver. Then to my great surprise and pleasure I realised the driver was already installed. Nice.
Another question. I am trying to fins out how to change the buffer. Is this possible?
Hi Andoval, Happy to hear it's working well for you thus far. ACPID should be installable using the Puppy Package Manager from the Debian repository. I don't include it by default because I don't really want a dedicated process for power control. You would also need to create an init script for it once installed. May I ask why you are looking for this?Andovai wrote:mpdPup is great...but i want acpid...Is it possible??
Hi Jean-Louis, I haven't looked at AP Linux personally, but based on the threads I've read about it seems to be more oriented as direct replacement for Mac/Windows, and it requires a 'head' (mouse/key/monitor). I believe it uses Deadbeef, which does get a lot of good marks for sound quality, but my primary interest is in headless/appliance-like systems. It uses Pulse Audio, which is a nice abstraction layer for desktop functions but can be problematic for dedicated audio. As Mark van de Pas noted, the feedback I've read on the audio quality has mostly been positive, but overall it seems like that project's goals are very different from mine.Jean-Louis P wrote:1) I have seen there is now an "audiophile linux" based on Linux Mint Debian. Seems very close to mpdpup, has someone tried ? Benefits / disadvantages for both systems ?
2) Has someone had mpdpup running on cheap appliances eg Pogoplug (sales now around 40$, still less $ than used laptop ).
Regarding ARM based appliances, there are a couple issues here - one is the vast majority of low-end arm solutions use USB ethernet, this is going to cause a lot of contention on the USB bus when combined with a USB DAC. There are a few exceptions, but they seem to be few and far between. The other issue is the build system for the OS - mpdPup leverages the Puppy Linux build system. The Puppy Team is just starting to explore Raspberry Pi support, but the Pi is one of the platforms that uses USB ethernet. Not sure how easily their work could be extended to one of the more capable ARM boards. Regardless the current state of things from both hardware and software perspective leaves this low on my priority list. I would suggest looking out for embedded x86 solutions - the Alix boards are the classic reference here, but there are other contenders coming out all the time.
Hi Mark, I've seen this criticism come up several times, I think some of it may have been from you on Audio Asylum, but I don't recall seeing specifics as to the issues encountered. Could you elaborate a little bit on the specific issues you ran into trying to use local storage? As jrling noted, support is there already. I know it's not perfect but in my experience I haven't had trouble. I do know a few users had trouble with booting from a USB stick and also using USB storage, as the device initialization can be odd on some systems.Mark van de Pas wrote:Unfortunately test-driving MPD-PUP from a usb-stick with no NAS connected is very hard. Idolse should really optimise this. It's much too difficult too test-drive MPD-PUP from usb stick only. MPD-PUP could have a huge share of followers if only they could easy test-drive it and experience the very high sound quality coming from MPD-PUP.
When you mean test from a USB stick only, do you mean test 100% from a USB stick with audio on the same stick?
For number 1, I don't think the mixer state is always stored correctly during the initial setup. I would suggest that after the 2nd reboot that you go back into alsamixer and re-mute the internal speaker. Exit, then type 'alsactl -f /etc/asound.state store', finally type 'save2flash' to commit the changes. Regarding number 2, you are probably running into the known issue mentioned above - USB stick boot device plus USB Music HD are a bad combination and I don't have an easy solution there, simplest solution for now is to install mpdPup to the laptop's internal storage.kocozze wrote:I started mpdpup 0.9.3 on sony vaio laptot and i have two problems:
1- the internal sound card of laptot start at every boot with the volume at maximum (the speaker put out an annoyng noise), and when i set volume to 0 in alsa mixer, i set the correct audio device (hiface) and reboot, it's all as before!
There's a way to disable completly and finally the internal sound card? In bios there's no way to do this.
2 - Although I set the correct path to music folder (an external hd usb), mpd says "failed to start directory....:no such file or directory" "failed to load database: failed to open database file....no such file or directory", "database: could'nt start parent directory of db file ... no such file or directory"
On another laptot (an acer aspire) all was right!
Hi Drew, If the Amanero support USB Class 2 audio in general it should be able to work with mpd 0.17 - the product page indicates it does.PET-240 wrote:Quick question, looking to use the Amanero as a USB output device, this is capable to pass DSD and am reading that the 0.17 can pass DSD over PCM, according to here anyways