phunge

Hmmm, not sure why you try to discredit him? Is it because he criticized your beloved and infallible apple? Surely Roon's CTO must understand the protocol having built Roon with the ability to stream to airplay devices. The protocol is no secret, it was reverse engineered only a few years after it's release. Even the private key used by apple's symmetric AES encryption to provide DRM has been leaked. I also think it's no secret that the protocol is 15 years old, was originally designed to handle audio only, and has been evolved since to add support for additional, non-audio features such as video, mirroring, etc. Anyway, the issue of Brian's understanding (or lack of) notwithstanding -- I don't think there is any dispute on apple's choice of clocking scheme within the original airplay protocol. As with S/PDIF or non-asynchronous USB, airplay dictates the clock comes from the source. The source pushes the audio to the DAC, and embeds the clock, in the same manner as S/PDIF. This requires the DAC to either synchronize it's clock to the source clock (phase locked loop & voltage controlled crystal oscillator), modify the audio stream to deal with buffer under/over runs (add or drop samples), or provide some form of Asynchronous Sample Rate Conversion (convert the data from the source freq to the DAC's frequency). In the early days of digital, the 'bits are bits' argument was ever present. If the same audio samples are being sent, unmolested, to the DAC, then things should sound the same. In S/PDIF, however, it is not just the audio samples that are being sent to the DAC, the clock is also embedded in the protocol. While it was possible for the DAC to recover and use the incoming clock, high-end DAC manufacturers started implementing reclocking. Incoming samples are placed in a buffer, and a phase locked loop was used to lock to the incoming clock. Rather than using the incoming clock directly, the DAC would generate it's own clock utilizing a voltage controlled crystal oscillator, adjusting it's frequency slightly to match the timing of the incoming clock to avoid any buffer under/over runs. Being that this is computer audiophile, most will likely be familiar with the advances of asynchronous USB audio pioneered by Gordon Rankin, Ayre and dCS. The idea with asynchronous USB is to put the DAC in charge of the clock. The clock can be physically located in close proximity with the DAC on the circuit board, or a high quality outboard clock can be included in the system. The DAC then pull's the data from the source at it's own rate. Most high-end DACS these days include some form of asynchronous USB implementation, and I think it is generally accepted that this design allows for a more stable, lower jitter clock which improves overall sounds quality. Letting the DAC control the clock would be difficult/complex with a stereo pair of devices, however. Drift in multi-room audio is less of an issue if kept fairly low (e.g. <1s), but even miniscule drift between stereo devices would be detrimental to sound quality. having a stereo pair of devices with independent clocks requires some form of clock synchronization to keep them in sync. I don't know how Apple has implemented this with the Airplay 2 protocol, but I would be interested to find out. If they have changed the clocking scheme, I would be pleasantly surprised. For the average apple customer interested in running two homepods as a stereo pair, this discussion is pointless -- most people just don't care. For the average computer audiophile participant, however, I suspect that these issues become an interesting aspect of the hobby. Those interested in the state of the art of digital audio streaming will likely want to look beyond apple's 15 year old airplay technology. Roon's RAAT protocol or OpenHome/UPNP are likely better choices but I would be interested to learn more technical details about what Airplay 2 brings to the table.

Great writeup from Brian of Roon Labs regarding some of the limitations of Airplay (contrasted with Roon's RAAT) here: https://community.roonlabs.com/t/whats-the-difference-raat-vs-airplay/6891/5 I wonder if Airplay 2 solves any of these issues? Especially the use case of streaming to a stereo pair of devices -- how do they handle clock variance between the two devices?

Indeed, I have seen much criticism against Microsoft for not including a native USB Class 2.0 audio driver when Linux and Max have supported this for so long. It's unrealistic to expect a boutique manufacturer of a high-end USB DAC to support the development and delivery of something as complex as a windows audio driver and keep it up to date for each new OS release. I have always been worried that I might one day get stranded with a very expensive piece of equipment that I cannot use because of not having a driver available. As a windows guy, I am happy to finally see Microsoft investing resources into building this into the OS directly. This also opens up additional possibilities, as Microsoft will support this driver on both ARM and Intel platforms. I dream of a day I could run a stripped down version of windows 10 (like the many Linux audio focused variants) as a Roon endpoint on lightweight arm based hardware (e.g. raspberry PI with windows 10 IOT). This gets me one step closer.

well... after more extensive testing I have to report that this driver is not yet ready for prime-time (which is fine, given that it's an early 'beta' release). I cannot get it to work properly in exclusive event-driven mode from Roon. It plays the first few seconds of a track, then stutters and quits. Hopefully Microsoft can get this driver polished in time for the next mainstream windows release!

I verified this today with my Esoteric K-01x -- I was able to switch from the esoteric supplied driver to the native Microsoft supplied windows USB 2.0 driver and it works perfectly. Finally!

https://blogs.msdn.microsoft.com/matthew_van_eerde/2016/09/15/installing-the-microsoft-class-drivers-for-usb-audio-devices/ Latest windows 10 preview release now has a native driver: Native support for USB Audio 2.0: We now have native support for USB Audio 2.0 devices with an inbox class driver! This is an early version of the driver that does not have all features enabled, for e.g.: only playback (render) is supported with this version. Recording (capture) support is scheduled to arrive in later iterations. We encourage you to play with the driver and let us know what you think (using the Feedback app). If you already have third party drivers for your USB Audio 2.0 device installed, follow instructions in this blog post to switch to using the inbox class driver. Read more at https://blogs.windows.com/windowsexperience/2016/09/21/announcing-windows-10-insider-preview-build-14931-for-pc/#mkVdxTDIXslv3rSD.99

I was holding out for the DAC8 too, but I found a used DAC7 for a really good price and couldn't resist. All of my music is ripped from CD, so hi-res is not important to me at this point. I figured that if I do eventually get into hi-res, I can buy the lynx card and connect via AES/XLR. I also like that the DAC7 has the black handles and black buttons to match my LS26 preamp.

Looks much like the DAC7, but with the newer aluminum buttons and additional LEDs to indicate sample rate.

Would like to hear a statement from Audio Research as to how long they intend to provide drivers. It's bad enough having my RME DIGI/96 relegated to the spare parts pile because of lack of Win7 drivers -- I would hate to see that happen with a $5k DAC when some new windows audio driver scheme gets introduced 5 years from now. Audio Research has a good history supporting their older equipment. (check http://www.audioresearch.com/SP3-update.html) Hopefully they will continue this tradition in the digital age. Having said that, writing device drivers for windows is not a trivial task, and ARC probably contracted that out since it's unlikely they would have or would want to develop that kind of expertise in-house.

Not sure if you'll be checking out any computer stuff, but I'm interested in the new Intel DH57JG 1156 mini-itx motherboard -- I think this will make the perfect HTPC platform.

Gordon,<br /> <br /> As far as I know the DAC7 is all solid-state and does not upsample. <br /> <br /> My interest in the DAC7 stems mainly from the fact that I own an ARC pre-amp (LS26) that I enjoy immensely.<br /> <br /> My interest in the QB-9 is primarily driven by the engineering principles that you and Charlie have put forth in the online community.<br /> <br /> I will definitely try before I buy, i'm just having fun gathering information at this point.<br /> <br /> thanks for your feedback!

Gordon, thanks for the reply. Who are Doug, Marc and Jeff? Jeff Fritz, the reviewer?<br /> <br /> I'm really torn between the Ayre QB-9 and the ARC DAC7. I find the lack of technical details from ARC frustrating, and really appreciate the Information you and Charles Hansen have made available. I'll be honest -- i'm a bit of a gear-head and the technology and engineering behind a product is as important to me as the sound quality.

According to this review:<br /> http://www.soundstagenetwork.com/ultraaudio.com/equipment/arc_dac7.htm<br /> <br /> <ol><cite><br /> ...ARC’s Dave Gordon told me that the DAC7 operates in "asynchronous mode"; i.e., a clock within the DAC controls the transfer rate of the digital signal. In a typical system, the timing of the digital-signal transfer rate is dictated by the computer, in what’s called adaptive mode. A USB connection via a computer is not ideal for this task, partly because of the number of functions a computer’s processor is required to simultaneously perform. When the processor in the computer is overtaxed, the digital stream ostensibly suffers, and the timing of the audio delivery won’t be perfect.<br /> <br /> From what Gordon told me, the benefit of an asynchronous-mode DAC is less digital jitter (i.e., fewer timing errors within the digital stream itself), which, on paper, should result in better sound. ARC goes this one better, however: Once the digital data are inside the DAC7, they’re buffered (stored in memory), then re-clocked by an ultra-accurate second clock, before being fed to the DAC itself....<br /> </cite></ol><br /> <br /> This suggests that it works in a manner similar to the Ayre and Wavelength products. Exciting!<br /> <br /> Chris, are you still going to review this DAC?

with regards to this DAC. I'd really like to know how the USB input was implemented.<br /> <br /> Right now i'm also interested in the new Ayre QB-9: http://www.positive-feedback.com/Issue41/ca_hansen.htm

Several years ago, I asked myself this very question before undertaking the task of ripping my existing CD library. After much research, I decided to rip all of my music to single-file .WAV with cuesheets (see here for a description: http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Cue_Sheets )<br /> <br /> My reasoning was:<br /> 1. Longevity<br /> .wav is a simple, well documented standard that basically just represents the raw audio samples as recorded on the CD. You can also use the cuesheet and .wav file to burn a replacement cd if required that will be an exact copy of the original making it the ideal archive format.<br /> <br /> 2. Simplicity<br /> Lossless compression adds a lot of complexity and overhead. Being a programmer, I never quite trusted the encryption and decryption routines, or liked having to rely on someone else's library<br /> <br /> 3. Accuracy (most important)<br /> One of the tenets of audiophilia is reproducing as closely as possible the sound of the original recording. For any serious computer-based playback system, in my opinion you have to start with accurately ripped source files.<br /> <br /> When splitting the CD into a separate file for each track, you have to decide how to handle the gaps. (see http://users.fulladsl.be/spb2267/gapscue/gapscue.htm) By ripping to a single file, you don't have to worry about the gaps, the cuesheet is used by the player to determine where you are. Playing back from a single file aslo avoids the problem of gapless playback http://en.wikipedia.org/wiki/Gapless_playback (though most software programs have now fixed this problem internally)<br /> <br /> Foobar2000 supports playing back these files, but I've never been a big fan, so I wrote my own media player program that exclusively plays back media files recorded as single-file .WAV + Cuesheet. Being an audiophile, my focus was on accuracy. The program mounts the single large .wav file, and reads ahead to fill a memory buffer with audio samples. A separate high-priority thread then takes the audio samples from memory and renders them to the audio device (Ideally to a high-quality external DAC via USB who's drivers bypass the dreaded Kmixer in WinXP). By writing my own software, I felt confident that the audio samples were being passed directly to the audio device without any modification of any kind. During playback, the software periodically polls the audio device to determine which sample is currently being played, and then does a look-up to the cuesheet to determine the exact location of playback. Because the file is not split, during playback of a pre-gap, it knows exactly which track is being played, and the fact that we are in the pre-gap is displayed by counting down from a negative position to the position of index 01. In my opinion, this most closely resembles not only how a CD player works, but also the experience of playing an album. I tend to think of my music collection as a collection of albums, not a loose collection of tracks. The player represents my library in this way I.E. I select an album to 'load' into the software transport (load the .cue sheet and open the .wav file for i/o). The player transitions seamlessly from track to track, because it's really just playing back one large track. Skipping is accomplished by determining the location of index 0, and seeking to that position in the file. Because of the memory buffering scheme, Disk I/O does not negatively affect playback. <br /> <br /> Simple and effective. As any anal (borderline OCD) audiophile would insist upon