moschlegel

As of November 11, 2014 the latest Voyage MPD version is 0.9.5 Download | Voyage Linux

Another option are products like Aqvox's pass through usb power supply USB audio power supply that can apply power downstream of the shortblock

Actually Voyage MPD doesn't use 256MB, that's just the standard amount of RAM that the Alix 2d2 board come with onboard that lots of people tend to use (because the Alix is so stripped down of unnecessary hardware). The actual amount my Voyage MPD 0.9.1 host is using right now is about 31 MB (bolded below). This after an uptime of about 12 days Although it says it's using 251204 KB as used, nearly all that is caching and buffers that the kernel will always take advantage of when there's that much (256MB) available RAM. You could just as well jam Voyage Linux MPD on a board with 64MB (if you can find one) and it would probably run fine and just cache less.

I have this nice JDS Labs C5D headphone amp/DAC. It uses a microusb input that you'd usually feed (in my case using Linux) via something like Voyage MPD linux or a stream from youtube via pulseaudio or similar off your laptop. But what I want is a small portable music server with a display so I can plug in a USB key containing flac file, it would index those files and display a menu and have a microusb port so I could stream to the dac. Nearly everyone seems to use an IPhone but I didn't want to go that way. My current compromise is that I bought a cheap Dell Venue 7 android tablet which has a microsd slot and a microusb port. I will just use MPDroid or similar to serve the files to the C5D from the SD card. Tablets are nice because the display is right there and I plan to be using it mostly at work at my desk so the clumsiness of it not too bad. But I don't really like this solution since I wanted to use a normal USB key. Is there some kind of portable device that can stream WAV and FLAC files from a SD or usb key? Something like a Fiio X3 I think will only let you stream USB *into* it so its DAC can play the music. I want to find something like a Fiio that streams out to a dac. ps. I've built a MPD server for home use (Alix 2d2 using Voyage MPD), that would almost be doable but doesn't solve the music selection problem. I do not want to put a MPD server on the work network because it's not allowed by the IT people, I want the C5D and server to be completely isolated. Because of that the usual way to select music in MPD (using a web browser or mpd client like GMPC ) can't work.

First see if the newly installed module is actually being loaded: (note the vertical char before the 'grep' is a pipe symbol and not a small L "l" ) If that doesn't show your module as loaded then that's the problem. Frequently it's not enough to just install a module into the kernel tree, you have to also rebuild the module dependency tree so that the kernel knows to demand load the module. That's in the file called /lib/modules/3.8.13-voyage/modules.dep. I'm more familiar with RedHat / Fedora but I'm thinking Debian would be similar (I see that Voyage MPD has 'depmod' in it) (option on the grep is a dash small L ) I'm assuming your Voyage MPD is using that kernel (3.8.13), change that if it's something else. Basically that searches all the files of names starting with "modules." in that kernel directory and then reports any filename that has that string ( the -l option limits grep to just reporting the file ). So we're having it search for part of the name of the module (I'm figuring 'mytekusb' is enough to be uniquely matched) if you don't see any files in there having the name of your module, then run 'depmod -a', this has to write to the /lib/modules/3.8.13-voyage/modules.* files so make sure to remount your flash to read/write, do the depmod -a and set it back to readonly: You can reboot the machine or try: to force it to load now.

In my case, I have an older DAC that lacks galvanic isolation, it does seem to get SMPS noise or ground loop interference from the Alix music server I use. So my fix was to use a Olimex USB isolator https://www.olimex.com/Products/Modules/Interface/USB-ISO/ (which is okay since the dac I have only goes to 16bit/44k which avoids the fact that the olimex can't go fast enough for 24bit/96k or higher) When I put in the olimex there was a big decrease in buzzing.

JJJ: The main 'handwaving' explanation I've heard is that switching mode PS hash noise could come up the USB cable (either the power wires or the data wires) and interfere with the DAC buffer clock that makes asynchronous mode possible. The buffer clock has to have some kind of phase loop or feedback mechanism to work, so if noise gets in that loop, it might make the dac buffer clock more jittery. I just recently posted an idea http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/idea-isolation-usb-dac-computer-using-usb-bulk-mode-and-then-disconnecting-song-manner-15163/ I had about taking asynchronous mode to a logical extreme: have the DAC have a really large amount of RAM in it then pull the entire wav data for the song into the DAC, then disconnect the DAC from the USB card (XMOS usually) electrically (maybe a relay would work). Only at that point would the buffer be played. Since the usb stuff would then be completely isolated, the buffer clock would be nice and isolated. The USB bus doesn't like hardware constantly coming and going, so the XMOS card remaining on the bus would make the remote music server happy. You might think that would make for an annoying delay as you go from track to track but even USB is so fast that a rather long song would be slurped in fast enough. So this is sort of like a poor man's Memory player (for example Nova Physics makes one), which usually go to much more complexity and cost than my "buffer to full song" idea.

In the music server and dac forums I frequently read about the controversies about which USB cables sound better or how to stop switching mode noise or ground loops from the computer server to the USB dac from coming up the USB cable. It seems to me the only way one USB cable can sound different from another is: 1) actual digital bit errors on the cable (very unlikely, how often do you see wild data on your usb printer or data errors in documents you save to your usb hard drive?). That would mean the remote usb circuitry is presented with so much noise that it mistakes a 0 for a 1 , etc. 2) some kind of timing errors caused by noise coming up the USB P+/P- lines polluting the D+/D- lines. This might have something, the USB standards were mostly interested in the bytes getting to the destination correctly but not necessarily in arrival at some particular, exact time. Dumping a file to a hard drive isn't really time critical but streaming a synchronous audio stream to a DAC is. BUT we frequently use USB asynchronous mode now, so I would think that would fix this jitter issue. But now the handwaving is at the point where some are explaining that the USB signal line noise (maybe coming from the SMPS in the server) is messing with the USB DAC clock that feeds the stream data from the buffer and into the DAC. I then had an idea, instead of buying super expensive cables or galvanic isolating the dac, why not take asychronous USB to the extreme and simply get the entire FLAC song in one go, buffer it to a big section of RAM in the DAC, then disconnect the DAC from the USB hardware in the DAC (for example, disconnect to DAC from the XMOS board) and only then play the song? Since even USB 2 is so fast, slurping in entire songs would not take very long at all. Because the USB standard doesn't deal well with hardware coming and going frequently, I'd do this by leaving the XMOS card on the bus but simply disconnecting the data line from the XMOS to the DAC with some kind of relay leaving the XMOS always on the bus to keep the server happy. So this would kind of be like what's called a "memory player" ? I'm not really saying this a practical thing, but it would completely remove all the "noise" issues from the DAC as far as the music server/streamer is concerned.

@Chris(absorb): I'm not sure I follow you, you have a Aune T1 dac connected to the Alix. All you need to add music is to have access to the server. I assume you get the music files to the Alix from the server via NFS? To add music you'd just add the files under the NFS mounted directory on the server, you don't need to do anything to the Alix. Well, that's not totally true, after adding the new music, you need to use your MPD music client which should have an "Update" control that will tell the Alix to rescan the NFS mount to update it's list of music. But that won't require you to do anything directly on the Alix.

>you do realize that your computer is doing "tiny bit of extra work" >all the time >while playing music? even with the most minimal operating >system capable of usb audio, >your cpu and ram are shuffling back bytes >and doing all sorts of other things. Not in my case, I use an Alix, the only thing it tends to do is MPD, only the NAS (which is my main PC) does other things. What I'm saying is that these other people that say wav is better might have their entire chain on their main pc (the usb dac is plugged into their main PC) I don't see a valid reason for FLAC to be inferior sounding to WAV either, I'm just trying to come up with any kind of theory. I would think it would also be fine to do what Voyage MPD does and just decode a chunk for the file and send it to the dac, enough so that the buffer stays full

I was reading the almost religious wars in another thread about wav vs flac. Some are convinced FLAC doesn't sound as good as wav. One theory I had was that on some playback systems (non-asychronous aka 'adaptive usb'), the tiny bit of extra work the cpu has to do to uncompress the FLAC back to a wav stream causes a bit more jitter than if you played a wav. In the latter case, the cpu just needs to move the bytes. So my question is, does Voyage MPD take each entire FLAC file via NFS and decompress it to RAM in the ALIX and then play that WAV data to the DAC or not? I've never really noticed an intersong pause so this is probably so fast that it's not obvious. I would think if that's the case, then on Voyage MPD, there would be no wav vs flac difference because that cpu work is done before the song plays so FLAC and WAV would be in RAM exactly the same before being played.

What the OP probably means is that SB motherboards being newer by class are more likely to have no PCI slots but only PCI-Express slots. There's probably no architecture reason why the manufacturer can't tack a pci bus chipset on there but fewer will because it does has a cost and they're judging that someone buying a brand new sandy bridge is not likely to have pci cards.

I think I could see the 192/DSD on their European pages: Digital to Analog Converters see the top three product ids #1,2,3 (I got there by looking in the News tab on the main mytekdigital.com site. They have a "Mytek European Online Store" link there, then on that link click the "Digital to Analog Converters" in the Categories list in the upper left. )

That would be pretty impractical, first I don't really care that much about the 5 watts the alix uses. My tower box uses way more power (quad core Q6600, 8GB ram and two monitors that go to sleep when the tower suspends and a high end graphics card). It's really easy to suspend the desktop but it's not that handy to power the alix off and synchronize it. I'm just suggesting it would be a nice feature if Voyage MPD would try to mount the NFS if the mount is missing when a connect + play event occurs from the client.

I have my NFS server for my MPD flac files on my main office PC. I like to suspend this machine sometimes to save power. Unfortunately Voyage MPD doesn't handle that very well. I tried modifying the /etc/fstab to use the 'bg' option thinking voyage mpd would be more tolerant of the mount going away and coming back if I had the bg option set. But usually I have to ssh to the voyage alix and run "mount -a" to kick the NFS mount back up. Would it be hard to make Voyage MPD do the remount automatically if finds the mount is gone and the client is trying to play a song?