sandab

What can happen is you mute the internal speaker. Plug in the DAC, and it will be used as the system, muted. Then start A+ and coreaudiod will keep the DAC muted despite the internal audio having stopped using it and using the internal speakers - muted. Not sure where the bug is (my best guess is coreaudiod), but the following will fix it: * Quit A+ * option-click on the sound in the menu bar and select the DAC for system audio * Turn up the volume to max * Start A+ * Mute the internal system audio (now using the internal speaker) This assumes A+ is configured to have exclusive access to the DAC.

I use a Schiit Wyrd with the USB cable that came with the DAC and a PS Audio AC cable to a Furman PST8D power strip. Nice and clean, not a hint of jitter (master clock phase noise, actually) and no dropouts or other problems with the exact mode clock - which IMO the Vega earns its price tag. The computer is either a MacBook Pro or an Intel NUC core i5 with a 512GB SSD running Ubuntu and mpd. The USB cable to the computer is a 2m Ghent Audio U01.

Clean AC. I had occasional dropouts with a Wyrd and a Furman PST8D filtered power strip. With just a cheap power strip it would be unusable. And I have pretty clean power here to begin with. I since put the Vega and Wyrd on a Yulong P18 power filter and now I only get dropouts when the Vega is cold. It seems the sleep mode is inadequate, but it only takes a few minutes for it to warm up so at least I don't have to wait for an hour to reenable the exact clock. To warm up I just turn it on and leave it sitting for 5-10 min. I don't use any fancy USB cable, just a reasonably good looking one I think in fact came with the Vega. A Ghent Audio U01 USB cable (from a MacBook Pro r15 to the Wyrd). And yeah, exact mode is where this thing really shines, so well worth the trouble to get working reliably.

CD is still the most commonly available distribution format for PCM audio. Very little is available for purchase as downloadable PCM or DSD. So 1) buy CD (Amazon Prime 2 day shipping) with a 1-click, 2) insert into iTunes set to auto rip anything as lossless, 3) throw the CD in the giant box with all the other CDs.

He's just passing on the product description. He also has no way of verifying that it's really in a Teflon sheathing. Could be any PTFE and distinguishing between them would require spectrometry, not to mention destroying the product under test. But, it doesn't matter - because it's how the vendor describes the product. They could say it contains ground unicorn horns and he'd just pass that on, too. It's irrelevant, just like exactly how many nines of purity in the conductor is irrelevant. What matters is what it sounds like. And, yes, there are a lot of BS descriptions of products. In some cases by marketing people who lack an engineering background - or were mediocre engineers, leading them to find other jobs or shift over to management; in other cases by people who intentionally deceive and make sh*t up. This doesn't mean the product isn't any good and shouldn't be critically reviewed. The description of a product is a notoriously poor predictor of its quality or qualities. Controversy also helps; claim 3N and nobody lifts an eyebrow, claim 6N and people like you give them free publicity. It's also not just product descriptions, but as an EE I see lots of really crappy datasheets that are only marginally better than marketing collateral. They often claim things like "fast switching" but not how fast. When measured they're not fast at all. Another product which mentions high noise immunity might not reject certain bands, but man it's an amazingly fast switch. These characterizations are completely arbitrary, and the only way to find out is to test for yourself.

I'd be careful with batteries in this application. Because of their chemical nature batteries are noisy and produce HF ripple, which is anathema to generating a low-phase noise clock. The reservoir cap or battery in case of a direct connection needs to be decoupled, and the best way to determine the value is to scope the power lead under load with a high-impedance probe and try a bunch of different caps. It may require multiple caps to fully quiet it across the spectrum. The ripple size is inversely exponential with charge level. (As is the internal resistance.) So use a battery discharged to close to the cut-off capacity (not sure how that's determined for LiFe, but I assume voltage is a reliable indicator) to test under worst-case conditions. Still, given the sensitivity of a clock to ripple and the audibility of phase noise I'd personally build a quality low-ripple DC supply and use that. Just my $.02...

Correct me if I'm wrong, but isn't DoP limited by the 384kS/s PCM limit? The only way to support DSD256 is to not use DoP and instead play it natively. I wish A+ supported native DSD playback on my Auralic Vega... DoP is pretty flaky.

It's STILL having serious volume problems. Sometimes it plays at normal volume, at other times it's really low. When the latter happens it's also incapable of playing DSD over PCM, presumably because it erroneously applies an output volume control. It has been broken like this for at least the last four microreleases. Anyone have a workaround for this? Edit: looks like it's coreaudiod getting into a weird state and the following finally worked for me: 1 - stop A+ and unplug the USB DAC, 2 - kill coreaudiod (it will relaunch automatically), 3 - plug the USB DAC back in, 4 - restart A+ (reselecting the DAC as the audio device if it plays to the internal speakers). It may be A+ has no way to prevent it and it's simply due to an "active" (to coreaudiod) audio device not being present.

It might drop to 5.0V under 500mA (or 3A?) load. Always better to have a supply that's slightly high than low.

If you're in Sweden, there's always ELFA. When I lived in Stockholm I'd drive out to their store in Solna to pick up simple things like voltage regulators and anything else needed for prototyping. But that was over 20 years ago and I don't know if they even have a store these days.

I built a music server from: - Intel NUC i5-4250 - 8GB DRAM - 512GB mSATA SSD - Ethernet connection to an Airport Express - Schiit Wyrd for a USB filter - Furman 8-port strip with a digital noise injection filter - The stock power brick that came with the NUC - Ubuntu Server 14.04.1 LTS with only OpenSSH and mpd and its dependencies This is feeding an Auralic Vega DAC. The main problem I had was all my music is ALAC or DSD and the stock mpd installable by apt-get didn't support either. So I set up a VM on my MBP running the same OS (installed from the same ISO) with g++, gcc, emacs, and everything else needed to build and test mpd 0.19. Hooked up the Vega and assigned it to the VM for testing. Built an mpd with libav for ALAC and everything I could find related to DSD. Tested it and copied the executable over to the NUC, identified missing libraries and added those. Works like a charm! Cantata is a pretty nice OSX client. MPDDroid for Android... works. Sound quality is indistinguishable from the MBP. Without the Wyrd it's a little cleaner sounding (less treble distortion) than the MBP without the Wyrd. With the Wyrd the Vega plays nicely in exact clock mode, but without I get intermitted playback skips. The coarser clock settings don't sound as good as they're presumably PLLs and not a precision oscillator. Playing anything it stays at around 5-6% on a single core, so largely idle. The fan is inaudible unless I stick my ear to it, and then it's still quieter than the wall clock across the room. Playing music or at arm's length it might as well not exist. The low RF/EMI noise should be no surprise as it's all based on mobile componentry, so is low-power and individual cores can be powered down to preserve battery. The i5-4250 has the i5 and controller mezzanine chipset on a single carrier. Remaining loose ends: * Doesn't pick up DSF tags, might have to hack up a custom plugin for this * Occasionally drops audio when starting playback, need to experiment with buffer settings * Planning to build a custom kernel for it with as few drivers and as few modules as possible, with real-time scheduling policy support Of those, I'd only consider the first two important. Here are the parts I used. The NUC device itself is palm sized, slightly bigger than an AppleTV or Airport Express. http://www.amazon.com/Intel-D54250WYK-DisplayPort-Graphics-i5-4250U/dp/B00F3F38O2 (with cord) Amazon.com: Crucial 8GB Kit (4GBx2) DDR3 1600 MT/s (PC3 - 12800) CL11 SODIMM 204-Pin 1.35V/1.5V Notebook Memory Modules CT2CP51264BF160B: Computers & Accessories (8GB) http://www.amazon.com/Crucial-512GB-mSATA-Internal-CT512M550SSD3/dp/B00IRRDJ9C (512GB) Download Ubuntu Server | Download | Ubuntu (newest LTS) The ISO was put on a USB3 flash drive (PNY 256GB) and made bootable with unetbootin.app. UNetbootin - Homepage and Downloads Total price a little over $600 including prime shipping from Amazon. About 20 min to assemble, including unpackaging. About 4 hours to build mpd. (I can provide a binary for anyone interested to save you the trouble.) Another hour or so to get everything working correctly and trying different clients. Happy mpd hacking! Edit: I thought I might move it to an Akasa fanless, passively cooled case, but the fan is so quiet I see no reason other than purely appearance. So unless the bearings act up or it gets clogged with dust or something I'll probably just leave it as is. The NUC also comes bundled with a VESA adapter.

Sometime I should sit down and add a Null Audio Device to use for system audio while playing music. And, I really don't trust coreaudiod, as it's very prone to screw up lip sync for video, introduce pops and clicks for Bluetooth audio, and hang players on switching to/from DoP mode. The players will hang in a spinlock, and when coreaudiod is killed (relaunched) the hung process spindumps. Getting rid of coreaudiod from the playback chain and providing device drivers that permit unrestricted access to a DAC would fix so many problems. Coreaudiod could be completely killed and prevented from relaunching altogether. Or at least only ever handle system sounds to a null device.

I wasn't contradicting you; I was elaborating on what you said...

The problem is that a perfect rip is just that - perfect, and accurip guarantees it to cryptographical certainty. The claim is that two identical rips sound different depending on the power supply and drive, possibly cable, used during the ripping process. This is akin to claiming homeopathic water is different because it has a "memory" of something else that has been diluted out of existence, that diluting to a high certainty of not finding a single molecule of this something else, ever, leaves its "memory" without actually containing any of it. If two identical rips sound different it's because of some other reason, like a ton of AC, RF, EMI, and other noise and noise-induced jitter. They just happen to sound different because the pages are in different locations in memory and some addresses happen to cause more bus transceiver switching noise than others - or something else more or less random and indicative or poor isolation. Which brings up the matter of experimental rigor, control, and repeatability.

Is it possible to set the volume control to use a db scale instead of linear? Say 0db at max volume and -100db at minimum, then divide this into 200 steps of the volume control keys of 0.5db each? It's kind of silly to have half a turn equal -6db... Couldn't find anything in the settings that seems relevant.