New Linux OS aimed at computer audiophiles: Voyage MPD

[Jeff65]

Demian,

 

Thanks for the response.

 

Is there somewhere I can keep track of progress getting this driver into ALSA? I'm inclined to wait too, but I'll want to know if the effort stalls somewhere.

 

Cheers

[phofman]

Alsa-devel mailinglist

 

 

[alsa-devel] [PATCH v2] Add M2Tech hiFace USB-SPDIF driver

 

[alsa-devel] [PATCH v2] Add M2Tech hiFace USB-SPDIF driver

[DerekR]

DerekR - where did you get the VoyageMPD with 3.9 kernel?

 

Thank you,

Davor.

 

 

Davor - sorry but only just saw your post. If you haven't already solved it I believe the daily build of Voyage MPD includes the updated kernel.

[Maldur]

---

[jerico]

Guys - anyone have any advice on getting my Alix to hibernate? My (tubed) DAC follow the state of the machines they are attached to, so I'd like to be able to hibernate the Alix after a session (rather than unplugging the USB cable from the DAC).

 

I tried issuing a "pm-hibernate" command over SSH (after installing pm-utils on the Alix) but that doesn't seem to be working.

 

Thanks all

Justin

[1audio]

Guys - anyone have any advice on getting my Alix to hibernate? My (tubed) DAC follow the state of the machines they are attached to, so I'd like to be able to hibernate the Alix after a session (rather than unplugging the USB cable from the DAC).

 

I tried issuing a "pm-hibernate" command over SSH (after installing pm-utils on the Alix) but that doesn't seem to be working.

 

Thanks all

Justin

 

Check the details on the Alix you have at the PCEngines site. It may not support suspend or hibernate (they have specific technical names, S1 and S3 I think). The USB power may still be on in hibernate to enable a keyboard to wake the system up. That would all be in the BIOS. Some aspects won't be changeable.

[jerico]

Check the details on the Alix you have at the PCEngines site. It may not support suspend or hibernate (they have specific technical names, S1 and S3 I think). The USB power may still be on in hibernate to enable a keyboard to wake the system up. That would all be in the BIOS. Some aspects won't be changeable.

 

OK, thanks for the reply, Demian. If I come up with anything, I'll post more info!

[ingoh]

Guys - anyone have any advice on getting my Alix to hibernate? My (tubed) DAC follow the state of the machines they are attached to, so I'd like to be able to hibernate the Alix after a session (rather than unplugging the USB cable from the DAC).

 

I tried issuing a "pm-hibernate" command over SSH (after installing pm-utils on the Alix) but that doesn't seem to be working.

 

Thanks all

Justin

 

If your ALIX board uses the tiny bios there is no ACPI and so hibernation won't work. Maybe something like this could be possible.

[bluebeat]

Hi everybody,

 

This thread seems the right place for my first post on Computer Audiophile (I also posted the same question on Audio Circle), I could really use some help regarding the setup of my Voyage MPD starter kit.

 

I'm a total newbie regarding Linux, so maybe I shouldn't have tried MPD in the first place, but ... I still did, please be patient ;-)

 

My music files (flacs) are on a Synology ds213 (IP 192.168.0.107). NFS rights for MPD (IP 192.168.0.108) are contributed to the share, baptised 'muzieknas'.

 

Using Putty I tried to follow the steps in par. 4.1 of the Getting Started Guide that I got with my starter kit from Punky.

 

I managed to alter the fstab using vi, and added:

192.168.0.107:/volume1/muzieknas /mnt/muzieknas nfs rw,noatime 0 0

 

Then:

# mkdir /mnt/muzieknas

# mount -a

 

Then:

# ln -s /mnt/muzieknas/ /var/lib/mpd/music/muzieknas

 

Then:

# chmod -R ugo+r /mnt/muzieknas

 

After the last step, MPD stated:

chmod: changing permissions of `/mnt/muzieknas/': Operation not permitted

 

After that all the music files were found but with every file MPD stated:

chmod: changing permissions of `/mnt/muzieknas/King Crimson/Red/Starless.flac': Operation not permitted

 

What did I do wrong? What did I miss?

 

Can someone here help me?

 

Thanks for your time!

 

Greetings'

 

 

Marc

[ingoh]

Hi Marc,

 

looks like you don't have root permission to the nfs-share on your Voyage MPD. I don't know if you can set the option "no_root_squash" via Synologies GUI. If not you should be able to edit /etc/exports on your DS213 via putty.

 

Maybe a Google search for synologie and no_root_squash could help.

 

greetings,

Ingo

[bluebeat]

Hi Ingo,

 

Thanks, or rather: Vielen Dank! I'll check and report back!

 

Greetings,

 

Marc

[iago]

Then:

# chmod -R ugo+r /mnt/muzieknas

 

Check the file permissions on your NAS with

 

# ls -ln /mnt/muzieknas

 

Possibly you already have read permission on these files; it should look like this:

 

root@voyage:~# ls -ln /media/usb0/music/Quarterflash/Quarterflash/
total 247072
-rw-r--r-- 1 104 29 24272233 Nov 24  2012 01. Harden My Heart.flac
-rw-r--r-- 1 104 29 30027371 Nov 24  2012 02. Find Another Fool.flac
-rw-r--r-- 1 104 29 29488986 Nov 24  2012 03. Critical Times.flac
-rw-r--r-- 1 104 29 28540166 Nov 24  2012 04. Valerie.flac
-rw-r--r-- 1 104 29 22299502 Nov 24  2012 05. Try To Make It True.flac
-rw-r--r-- 1 104 29 25057569 Nov 24  2012 06. Right Kind Of Love.flac
-rw-r--r-- 1 104 29 26367086 Nov 24  2012 07. Crusin' With The Deuce.flac
-rw-r--r-- 1 104 29 15571530 Nov 24  2012 08. Love Should Be So Kind.flac
-rw-r--r-- 1 104 29 51058960 Nov 24  2012 09. Williams Avenue.flac

 

The user has write access, group and others read access to these files. You might mount your drive read-only (you do not need write access to it):

 

192.168.0.107:/volume1/muzieknas /mnt/muzieknas nfs ro,noatime 0 0

 

And just proceed with the setup (without the chmod part). If you don't have read permissions yet, you have to pass the user and group IDs of the client machine to mount; in my example that would be:

 

192.168.0.107:/volume1/muzieknas /mnt/muzieknas nfs ro,noatime,uid=104,gid=29 0 0

 

I never tried the last one, so you might have to fiddle a bit with it ;-)

[bluebeat]

I never tried the last one, so you might have to fiddle a bit with it ;-)

 

Thanks Iago - I'm shure I'll have to fiddle more than a bit, I'm a total noob. I'll report back later this week, no time now!

 

Regards'

Marc

[Krisbee]

Marc,

 

Did you get your MPD config working? There are quite a few pitfalls for those new to Linux. Unless you've added a normal user to VoyageMPD you will logon as “root”. You might think this means you have access to all directories and files without restriction, but this does no necessarily apply to remote dir/files that you have mounted on VoyageMPD.

 

 

chmod -R ugo+r /mnt/muzieknas

 

After the last step, MPD stated:

chmod: changing permissions of `/mnt/muzieknas/': Operation not permitted

 

After that all the music files were found but with every file MPD stated:

chmod: changing permissions of `/mnt/muzieknas/King Crimson/Red/Starless.flac': Operation not permitted

 

What did I do wrong? What did I miss?

 

Why does the chmod fail when it's excuted as root on VoyageMPD? As ingoh said “looks like you don't have root permission to the nfs-share on your Voyage MPD”. But that may not be the whole story, and we really need to see the contents of the /etc/exports file on your Synology DS213.

 

It may look something like this:

 

DS> cat /etc/exports

/volume1/muzieknas * (rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

 

The parameter list between the bracket determines whether the data is read-write or read-only and who/how it can be accessed. The default for NFS is “ro” and “root_squash”. You can't change permissions if its read-only, and if it was rw , the “root_squash” means that the “root” user on VoyageMPD is turned into an “anonymous” user with restricted permissions, and so again the “chmod” fails.

 

Simply using “no_root_squash” may allow your chmod to work, but really making changes like this from VoyageMPD is the wrong way round. I believe your should administer the data on your Synology DS213 via the Disk Station Manager ( What version do you have?). The NFS music share /volume1/muzieknas should be configured to allow client users to read its directory contents and files. Then you can export the music share /volume1/muzieknas as read-only and with “root_squash”.

 

Iago has shown how you might check that any user can read files in the mounted share, but if your share contains directories you need to check they have “drwxr-xr-x” permissions, or MPD will not be able to access them. This must be every directory in the path to the actual music files. This applies to /mnt and /mnt/muzieknas too

.

There's one point about which I think iago is mistaken. There are no uid gid NFS mount options.

 

One complication in this is that there seems to be a problem with NFS in later versions of Synology's DSM.

 

See here: Synology Inc. Online Community Forum • View topic - [4.3 official, XBMC OpenElec 3.1.6] Since 4.3 does not work

 

It's not clear if DSM have moved to NFS4 or not, in which case there may be more to think about.

 

A couple of background refs:

 

NFS Server (Network File System) - good on export options and mount

 

NFS: Overview and Gotchas - a lot more detail, good on user accees.

[bluebeat]

Hi Ingo, Iago and Chris,

 

Indeed, I got it working. Apart from you three I also got tips from Punky Tse, it was the easiest to implement, so I tried it first. He suggested to use # chmod -R ago+r /mnt/muzieknas instead of ugo+r. It did the trick ... not that I know what I did, really ;-)

 

However, I was thinking, using a Synology nas it should be possible to, instead of a NFS use a SAMBA server. It was suggested to me - over at Audiocircle - that it's a safer (maybe even more stable?) solution. I might try that.

 

First - music. I didn't do some serious listening yet, but it seems to me to deliver a cleaner sound and an blacker background, compared to my Sony Vaio laptop I used thus far with my Ayre qb-9. Great!

 

Thanks guys!

 

Marc

[Ipoci]

Has anyone had success with the Hiface1 drivers here:

 

Index of /dists/experimental/snd

 

I've tried several matching kernel / driver combos and can't get the driver to load. After installing the package, running insmod returns an error "Unknown symbol in module" or similar.

 

Thoughts?

 

I did a succesful test of VoyageMPD with M2Tech EVO ( same driver as Hiface1 ). I installed Voyage 0.9.1 then used the provided Debian package from here ... then:

 

dpkg -i <name of aforementioned .deb package >

depmod -a

... then reboot

 

Perfectly working but in any case overall audio quality was far away from cMP2 installation on the same hardware.

 

Cheers, Massimiliano

[evvivasms]

Good morning everyone. I am new to the forum. I installed linux voyage mpd 0.7. I have a problem when I load the music files. My music files are loaded onto a USB stick. As a client program using theremin or mpad on ipad. When I update the library just started the machine there are no problems. if I rip the usb stick, reconnect and update the library, the music files appear twice. If I repeat the operation the music files appear repeated. If you reboot the system the problem goes away, except unplug the usb stick and plug it in again. Can anyone tell me what could be the problem?

thanks

[Krisbee]

Good morning everyone. I am new to the forum. I installed linux voyage mpd 0.7. I have a problem when I load the music files. My music files are loaded onto a USB stick. As a client program using theremin or mpad on ipad. When I update the library just started the machine there are no problems. if I rip the usb stick, reconnect and update the library, the music files appear twice. If I repeat the operation the music files appear repeated. If you reboot the system the problem goes away, except unplug the usb stick and plug it in again. Can anyone tell me what could be the problem?

thanks

 

I'm not using Voaygae MPD at the moment, and 0.7 is an old version, but IIRC voyage mpd is configured to automatically detect a usb stick and an MPD update via a client will add audio files to the "music library". Voyage MPD uses an internal directory inside "/var/lib/mdp/music" called "usbmount" which points to the audio data on the usb stick. So, if you then copy the same audio data from your usb stick to another directory within "/var/lib/mdp/music" , the music files will naturally appear twice follwing another mpd update if the usb sitkc has not been unplugged. Unplug your usb sitck and do another mpd update and you will back to just one copy appearing in your mpd client.

 

Voyage MPD is working as designed. The "problem" is with the way you are using it. If you simply want to copy the audio from your usb stick. Do not do an mpd update until after the copy is complete and you have removed the usb stick.

[evvivasms]

Thanks Chris. I have tried to install newer versions of linux voyage mpd, but I had a problem I could not solve. After installing the operating system and after that I have configured mpd, everything works perfectly. After some time (I speak of hours) I lose the connection of the server with the client and I can not restore it. Using ssh I can run the server from the command line and send you to play mpd. This could be caused by what? This problem I had with most versions of linux voyage mpd, but not with 0.7.

[Krisbee]

After some time (I speak of hours) I lose the connection of the server with the client and I can not restore it.

 

When this happened, and you connected to the device running voyageMPD via ssh, had mpd stopped? Did you check the contents of /var/log/mpd/mpd.log for error messages?

[evvivasms]

No, I have not stopped mpd. I never check the contents of / var / log / mpd / mpd.log for error messages. The problem occurs even if I reboot the server. Now I have installed the version 0.7, but I can will install a recent version so I can make some tests. thanks

[cjf]

Hello,

 

I was curious to hear if anyone has played with these two MPD buffer settings below in RED found within the MPD.conf file and if you noticed any SQ improvements or losses in doing so?

 

# MPD Internal Buffering ######################################################

#

# This setting adjusts the size of internal decoded audio buffering. Changing

# this may have undesired effects. Don't change this if you don't know what you

# are doing.

#

audio_buffer_size "512"

#

# This setting controls the percentage of the buffer which is filled before

# beginning to play. Increasing this reduces the chance of audio file skipping,

# at the cost of increased time prior to audio playback.

#

#

buffer_before_play "5%"

#

 

 

I was bored today and performed a few network health checks mainly consisting of testing Ping times from a PC on the network that is connected to the same switch as my NAS server and Pinging my voyage music server which is connected to another switch in the basement.

 

While doing a standard ping using default pack sizes (32bytes) to the music server response time was 1ms max over a series of 10 pings using the -t switch.

 

Then for the heck of it I bumped up the packet size of each ping to the maximum allowed size of 65xxx bytes per packet and performed the above test again. Interestingly, the response time jumped up to 33ms per ping reply.

 

I then broke out my calculator and determined that even when using the largest packet size during the ping test this was still way smaller then what the default buffer setting is set to in the MPD.conf file (2048kb). My guesstimate would be a 60-70ms response time of the music server as it receives 2mb chunks of data at a time using the default settings in the MPD buffer.

 

So I decided to tweak the MPD buffer to what is shown in the example above. Using these new settings I was able to cut ping times down to 6ms when performing a final series of ping tests using a 25600 byte packet size per ping. This 25600 byte packet would be roughly 5% of the 512kb setting used in the above example.

 

I would be interested in hearing others experience who would be willing to give the above buffer settings a try to see how they compare to my own.

 

I think SQ has improved but I could be just hitting the bottle a little too hard.

 

Thanks for reading.

[Krisbee]

Well, I don't know what's going on in your network but there's no reason why ping response time between hosts should be influenced by mpd.conf settings. The ping command is interface specific and you're not testing the connection to a specific port on your mpd server. In any case, unless you are using MPD for network streaming, the network traffic between MPD server and client is confined to command data and sending audio file lists etc. which is not that time critical, although scrolling through very large music libraries could be slow. Use ssh to connect to your mpd server and turn mpd off ( /etc/init.d/mpd stop) and then repeat your ping exercise. Any difference?

 

You'd have to have a good understanding of the MPD code and ALSA's own buffer and memory management and USB controller frames etc. to decide if changing those particular MPD settings could influence SQ. I would pay heed to the developer's comments. Reducing buffers may simpler make your CPU work harder by servicing more frequent interrupts as the buffer empties more quickly than needed, and in the worse case you'd get under-runs.

[cjf]

the network traffic between MPD server and client is confined to command data and sending audio file lists etc. which is not that time critical, although scrolling through very large music libraries could be slow.

 

So are you saying that no Audio data/Media file data is being sent to the music server from the NAS? If so, then how is the media file finding its way to the DAC--Preamp--Amp--and out the Speakers? What am I missing?

 

Well, I don't know what's going on in your network but there's no reason why ping response time between hosts should be influenced by mpd.conf settings.

 

My thought is that the "buffer size setting" dictates the amount of data that needs to be sent to the server within a given period of time in order to maintain the size of the buffer at all times. So, for example, if you configure the buffer to be 512KB that means that the network needs to be able to deliver data at whatever rate is necessary in order to maintain that setting and buffer size.

 

If your DAC is requesting a packet size of 600 bytes per /ms, taken from the buffer above, then at bare minimum 600 bytes of data per/ms needs to be replenished back to the buffer in order to maintain the settings you have configured within the mpd.conf file.

 

Using the Ping command you can simulate how long it would take the network to send 600 bytes of data to the server. In doing so, at least on my network, if I use the -f command to tell Ping to not fragment the packet I now find out that the largest "unfragmented" packet that can be sent at one time is smaller then 600 bytes. This means that X 2 packets will need to be sent per transmission in order to complete the 600 byte handshake between my test computer and the music server. In my case, 512 bytes is the largest unfragmented packet that I can send at one time.

 

So we have the following:

 

Data is leaving the buffer at 600 bytes/ms

 

The buffer is 512KB or 524288 bytes in size

 

524288 bytes/600 bytes = 873.8 (ie..time in /ms till buffer is empty if not replenished) (ie...less than 1 sec)

 

So, the size of the buffer seems to have some bearing on the demand placed on the server. At the default size (2048) it would seem that the demand on the server would be higher as it tries to maintain the configured buffer size. If this value was decreased to something less then the default it would seem the demand would be less and the packets being sent to the server could probably be completed in X 1 transmission instead of X 2 because they could be smaller in size.

 

Use ssh to connect to your mpd server and turn mpd off ( /etc/init.d/mpd stop) and then repeat your ping exercise. Any difference?

 

I wouldn't expect there would be a difference doing this test as the MPD daemon in and of itself would not begin using the buffer above until it was playing a song.

 

You'd have to have a good understanding of the MPD code and ALSA's own buffer and memory management and USB controller frames etc. to decide if changing those particular MPD settings could influence SQ. I would pay heed to the developer's comments. Reducing buffers may simpler make your CPU work harder by servicing more frequent interrupts as the buffer empties more quickly than needed, and in the worse case you'd get under-runs.

 

Using the new settings and for what its worth, when I run "IPTRAF" within the shell I see that data is coming in over ETH0 at approx. 760 kilobits per sec or to keep things simple 97.28 bytes per/ms.

 

Running TOP when Redbook is playing MPD CPU Load never goes above 1%

Running TOP when 24_96 is playing MPD CPU Load never goes above 19%

 

It would certainly be a whole lot easier to just give the settings a try and let your ears be the judge then worry about why it does or doesn't work in a given system. So far, I'm liking what I hear!

[Krisbee]

So are you saying that no Audio data/Media file data is being sent to the music server from the NAS? If so, then how is the media file finding its way to the DAC--Preamp--Amp--and out the Speakers? What am I missing?

 

What was missing was any mention of the word "NAS" in your last post.

 

 

My thought is that the "buffer size setting" dictates the amount of data that needs to be sent to the server within a given period of time in order to maintain the size of the buffer at all times. So, for example, if you configure the buffer to be 512KB that means that the network needs to be able to deliver data at whatever rate is necessary in order to maintain that setting and buffer size

 

If your DAC is requesting a packet size of 600 bytes per /ms, taken from the buffer above, then at bare minimum 600 bytes of data per/ms needs to be replenished back to the buffer in order to maintain the settings you have configured within the mpd.conf file..

 

You speak of THE buffer, as if there may only be one involved in terms of the transmission of data form NAS to music server and music server to DAC, that seems too simplistic.

 

It would certainly be a whole lot easier to just give the settings a try and let your ears be the judge then worry about why it does or doesn't work in a given system. So far, I'm liking what I hear!

 

Of course anyone is free to try, but I don't use MPD much at the moment, and not with remote data.