Free to all audiophiles
The good people at KORG have decided to release the latest version of their music player/converter AudioGate free of charge. You can download here.
Now you can play DSD files with the KORG AudioGate player/converter. Audiogate can also play other formats such as WAV, AIFF and many others, and can convert DSD to/from PCM files. Converting a DSD file into a 24bit/192KHz file resulted in almost double the size of the original DSD file.
When playing DSD tracks, AudioGate converts DSD into PCM on the fly and outputs at the highest resolution possible. In my setup, I used the maximum resolution of the Musiland MINI interface which is 24bit/192KHz. So even though you cannot output DSD straight to the DAC (you will probably need megabuck equipment to do so), the player makes DSD compatible with PCM-based consumer hardware.
Activation and use with twitter
There is only one requirement for using this free player: you must link a twitter account to the player. The player requires that you send a twitt when you first use the player and every time you convert a file. Normal playing does not require twitting. I suppose this could be a good market indicator of DSD track usage for KORG and partners.
Playing my first DSD file in the computer
I downloaded my first DSD track from 2L. At 24/192K output through the Musiland Interface and into the Buffalo II DAC, the quality is astonishing, with unmatched clarity and dynamics. Even at this high sample rate, I was able to set the DPLL setting in the DAC to “lowest”.
A free player, a $60 USB-SPDIF interface and a $250 state-of-the-art DAC… Ultra HIGH END has never been so affordable.
Setting Sample Rate
AudioGate supports DirecSound and ASIO. (I did not see support for WASAPI). When using ASIO, one sets the sample rate of the hardware and all tracks are played at that sample rate regardless of the source file native sample rate. This is OK when playing DSD files, but the lack of automatic sample rate change, makes it inconvenient to use as a general purpose music player. In this department, XMplay in WASAPI exclusive mode has the advantage because it can automatically use the sample rate of the source file. One solution is to convert DSD to 24/192K and then use XMPlay as the hires player.
One of the drawbacks of iTunes (at least in Windows) is that all tracks are played at the sample rate set in Quicktime. If you have a high res file, you have to change the sample rate first in Quicktime. And if you have a collection of high res files at different sample rate, then you’ll have a real good time switching sample rate on a per track basis.
I came accross a minimalist music player called XMPlay. It is a real small download and it requires no installation. It plays AIFF format straight out of the box as well as WAV.
You also download the WASAPI plug-in so that the player can work in Exclusive mode. Since the player requires no installation, you just put all the files you download in the same folder.
Enable Exclusive mode and set “Use Source Resolution” as shown in the following two screen captures.
Since I am using the Musiland USB interface, in order to allow automatic sample rate change (even though in Windows Vista/7 the Auto SR option is not available) you set it to 192KHz as shown below
That’s it. When you play a song, the sample rate will automatically switch to match the source sample rate. How do I know? If it weren’t for the Sample Rate display of the Buffalo II DAC, It would had been very difficult to figure that out…
You can even put the player and a collection of tracks in an SD card and play out of it!
NOTE: iTunes can also play through WASAPI but it cannot operate in exclusive mode, only in shared mode
Now that I’m familiar with the Sabre datasheet and developed some code, I took a closer look at the long Sabre DAC thread at diyaudio. (over 1700 posts).
Before I had no idea about what they were talking about . I have summarized some datasheet-relevant information here for my own benefit and for those who are thinking of programming the DAC
- Pin 8: Reset: 125
- Pin wiring to support Stereo and DSD-I2S-SPDIF: 145, 153
- Pin wiring to support I2S: 147
- Register 0-8, volume: 113
- Register 8, 18 Switching input format on the fly: 125
- Register 10 Jitter ON/OFF: 492
- Register 11 DPLL bandwidth: 575, 821
- Register 12, notch delay: 497, 758, 1315
- Register 14 DAC source: 153
- Register 14 true/pseudo diff (bit 3): 1683
- Register 14 IIR filter: 229, 2?
- Register 15 quantizer 35 and here
- Register 16 Automute: 159
- Register 17 Oversample bypass: 1279
- Register 37-45: Programmable filters: 1289
- Output impdeance, each output pin: 114
- Change Input Format (SPDIF-I2S-DSD) on the fly: 125
- Choice of clock frequency: 127
- External oversampling: 241
- Jitter Eliminator corner frequency: 320
- Jitter performance (vs other DACs): 385
- DPLL bandwidth compared 9018 vs 9008: 1256
- DAC design priorities: 388
- Digital Volume Control: 456
- Filter passband ripple: 496
- Input levels and switching frequency: 574
- I2S bitclock requirement: 1578
- DAC SNR and THD Spec: 1532
- Built-in FIR filter characteristics: 241, 1295
- Volume Control is done before Oversampling Filter: 113, 456
- Oversample Filter -> Noise Shaper -> Jitter Reduction: 258
- Inputs to DACs 3, 4, 7, 8 can be tied to inputs to DACs 1, 2, 5, 6 respectively: 153
- DAC internal data path (ES9008): 254
- DPLL uses (locks to) bit-clock: 1626
- Data reclocking: 319
INTELLECTUAL PROPERTY (PATENTS)
- Asynchronous sample rate correction by time domain interpolation
- System and method for digital volume control
- Device and method for signal processing
- Asynchronous Sample Rate Converter
- Low Noise Digital to Analog Converter with Audio Applications
- Low noise digital to signal interval converter with audio applications
As you may know, the implementation of the Sabre32 DAC I am using is the Buffalo II DAC. However, I believe these observations apply to the Sabre32 DAC chip in general as there are other reports indicating similar behavior but with different implementation.
OPUS/WM8804 SPDIF RECEIVER
I rebuilt my trusty OPUS receiver board and LCDPS supply. The OPUS receiver board is based on the Wolfson WM 8804 SPDIF transceiver chip. It boasts 50 ps period intrinsic jitter (In the photo, it is the module in the middle on the white wood stripe). In fact some implementations use the WM 8804 as a signal conditioner (and jitter reducer) for spdif signals.
I connected the spdif output of the Musiland 01 MINI to the receiver board and the I2S output of the receiver board to Buffalo II. I wanted to test the different DPLL bandwidth settings on this source. Specifically I wanted to know if Buffalo could lock onto an incoming I2S signal with the DPLL bandwidth set to “lowest”.
The behavior of the DPLL setting with the OPUS/WM8804 receiver board is exactly the same as with the Musiland 01 MINI board.
Just like with the Musiland board, I was able to eliminate most of the dropouts by setting the DPLL bandwidth to “Medium-Low”.
Additionally, like when using the Musiland board, , the dropouts are much worse, when the DAC is first powered on. As the DAC “warms up”, the number of dropouts becomes smaller until reaching a steady state (about 15 minutes).
PCM2707 USB INTERFACE
I also have a PCM2707 based USB board. This is the “workhorse” of the Audio USB interfaces and it is implemented in many, many different designs. The downside is the 48KHz limit.
This device has been getting a bad rap lately with the introduction of “asynchronous” USB devices that can handle sample rates higher than 48KHz. Even though in the beginning it was praised, some measurements have put the jitter in the thousands of pico-seconds. Oddly, Stereophile measured the jitter of the Apple Airport Express at 258 ps which was likely based on the PCM270x devices (Newer versions are based on different spdif devices which may or may not improve jitter -likely not improve)
The datasheet says that it “employs SpAct™ architecture, TI’s unique system that recovers the audio clock from USB packet data. On-chip analog PLLs with SpAct enable playback with low clock jitter”. SpAct refers to a method of capturing the data from the usb isochronous (bursty) transfer in such a way that data is always ready to be transmitted in real time through the i2s or spdif interface. This means that SpAct prevents data transfer hiccups at the USB side and the PLL generates the clock for the SPDIF/I2S side. Thus the jitter of this device is determined by the quality of the (analog) PLL.
The implementation I used was the gamma1 board from AMB, populated just for the USB to I2S functionality and bus powered. This is as minimalist as you can get for a USB to I2S interface.
One surprising result is that this is the only interface (of the 3 I’ve tested) with an exact clock frequency of 44100 Hz
Surprisingly, after the “warm-up” period of the DAC, this interface behaves the same as the other interfaces: just like with the Musiland and OPUS boards, I was able to eliminate most of the dropouts by setting the DPLL bandwidth to “Medium-Low”. “Eliminating most” doesn’t mean completely eliminating. Like the other boards, once in while you will experience a dropout; and like the other boards, setting the DPLL bandwidth to “best” solved the drop-out problem.
NOTE: I didn’t spend enough time time listening with this board to determine exactly if it was “exactly” as the other boards, but within the time spend listening to this board, it seems the infrequent unlocks (with DPLL BW set to “Mid-Low”) was “a bit worse” than with the other boards. Maybe if I spend more time I would determine if it is worse than the other two interface boards, but for now I would say that it is “the same” as the other two boards.
I would say that without some good A/B comparison, the three interfaces sound pretty much the same with the PCM2707 seemingly the worse of the three and the Musiland I2S seemingly the best (Can’t really tell for sure but that would take some serious A/B listening and have not done that yet). For now I will use Musiland SPDIF output primarily because I can set the DPLL bandwidth to “lowest” which in theory rejects the most jitter.
Based on these testing, the information that has been shared in the diyaudio boards and the fact that there exist a 128x setting for the DPLL bandwidth, tt seems that the low settings in the DPLL bandwidth were not meant for real life applications.
The SPDIF can easily lock into a signal perhaps because it is locking to the preamble (the preamble tells you the start of a data block) as the Cirrus receivers have started to do.
In any case, in order to get the most out of the Sabre32 DAC one has to set the optimal DPLL bandwidth depending on the type of the incoming signal: “lowest” for spdif, “best” for i2s/dsd. This can be automatically done by detecting the type of signal in the status register. I’ve done exactly that in my code. And having a manual mode will allow additional optimization depending on the source.
And if you are hearing night and day difference after your latest upgrade, perhaps you should check this out
This new version supports both SPDIF and I2S/DSD input (in accordance to Buffalo II input wiring)
- At power-on, the controller defaults to SPDIF input. You can select the default mode by changing a variable in the code
- Manual selection of SPDIF or I2S/DSD
- When selecting SPDIF, the DPLL bandwidth defaults to “lowest”
- When selecting I2S, the DPLL bandwidth defaults to “best”
- These settings have been empirically determined to be the best for each interface. They can be also manually changed.
- NLCK indicates that there is no input signal or the DAC cannot lock into the signal
- When there is no input signal, the input selection (left arrow) is displayed: SPDIF or I2S/DSD. The left arrow indicates input selection, not the actual signal
- SR is the incoming sample rate; it displays zero when there is no input signal
- Fi is the PCM filter setting: Sharp roll off or Slow roll off
- Jt indicates whether the jitter eliminator is engaged or not
- PL indicates the DPLL bandwidth setting
- “LOCK” indicates that there is a signal and the DAC is locked into that signal
- When there is a valid signal, the type of input signal is displayed: I2S, SPDIF or DSD (no left arrow indicates the actual signal type)
- The sample rate is calculated to the 1 Hz resolution and displays correctly whether the signal is I2S or Spdif
- In display mode, only the volume can be changed. Volume can be adjusted from -99 dB to 00 dB and can be independently changed with the knob or the remote control
- Pushing down on the rotary encoder (the knob) will engage “select mode”. A side bar is displayed to the left of the screen to indicate that you have entered “select mode”
- Every push of the knob will move down the arrow to indicate the parameter that can be changed
- IN: input selection. The user can select SPDIF or I2S/DSD
- Fi: PCM filter selection. The user can select fast roll-off or slow roll-off
- Jt: Jitter eliminator switch. The user can select ON or OFF
- Pl: DPLL bandwidth selection. The user can select “Be” (best), “<L” (lowest), “L” (low), … all the way to “>H” (highest)
- If there is no selection activity for a few seconds, the controller reverts to DISPLAY mode. This time out can be adjusted in the code
- Up button (1) increases the volume 1 db at a time. Holding the button down will continuously increase the volume
- Down button (3) decreases the volume 1 db at a time. Holding the button down will continuously decrease the volume
- The rest of the buttons are not currently mapped to any function, but there is support in the code to read all the buttons
- Reliable sources indicate that the 5v to 3.3v conversion is not necessary as the input of the Sabre32 chip is 5v tolerant. Since I already built it for the Wolfson WM8741 DAC (which is not 5v tolerant), there was no harm using it. You can omit it, build your own, buy a converter or even use an isolator
- The red PCB I purchased from NKC. I already used it in my previous project and reused it here as a bread board. You can use any other method for the connections, but it makes it easier to add components. If you wish to use a PCB, I would recommend this one for $4
- Eventually, I’ll move the controller to a nicer box
- I adjust the brightness of the LCD by controlling the current delivered to the LCD’s backlight. I connect the GND line of the LCD’s backlight to a transistor (I am using a jfet, since I’ve got a ton of it). The current through the jfet is controlled by the voltage applied to the gate of the jfet. I vary the voltage with an analog pin in the Arduino
My favorite device to recycle parts is the old VCR. These are the last devices that came with linear power supplies. The transformers are very high quality E-core types often made-in-Japan (where can you find those nowadays). These have multiple secondaries and typically there are at least two high current 7-8V AC secondaries. You can easily figure out the secodaries with a voltmeter by measuring the resistance of the wires and by looking at the thickness of the wires.
The high-end ones such as the Super-VHS Hi-Fi are obviously the best. You can find lost of connectors, cables, diodes, switches, pots, voltage regulators, buttons, heatsinks, etc, and name-brand capacitors such as Nichicon and Rubycon. There are also knobs, IR receivers, mains EMI filters, fuses, fuse-holders, inductors, and tons of screws.
Yeah, you migh say, “but the capacitors are old”. Yes, but I’ve measured many of them and they are around 70-80% of the value printed in the cases.
When you are in the middle of a project and Digikey is several days away, just pick up your voltmeter and look up that critical resistor you need
Most of the devices are discrete. The devices can be easily removed because they used the regular leaded solder. These things were made prior to RoHS. Make sure to use common sense and avoid lead exposure (ventilate the areas, wash hands, etc). Most diy kits use leaded solder anyways, so nothing new here…
I picked up a JVC Super-VHS Hi-Fi for 5 bucks at the local thrift/charity shop. The Japanese model was listed at 178,000 yen in 1987 (Almost US$500!). I tested it first to see if it worked. Luckily it didn’t…
Update: Apparently this device is part of “video history“:
VHS had much improved, and with the introduction of ‘Super-VHS’ (S-VHS) which again used higher-quality tape and produced remarkable sharp pictures for a domestic device, the system was able to offer extremely good quality (though most people stuck to plain VHS). JVC’s HR-S5000 (left) was one of the first of this type and included NICAM reception; subsequent models introduced digital video noise reduction, making a marked further improvement in the quality and taking tape recording about as far as it could go.
NICAM is an encoding scheme. “Audio is encoded using 14 bit PCM at a sampling rate of 32 Khz”
No wonder modern DACs support 32K sampling rates.
NOTE: Although this post reads like there is a problem with the DAC, what I am doing here is reporting a particular behavior of the DAC with certain (the most picky, I would say) settings are made in the registers. Choosing the right settings will allow the DAC to perform flawlessly (as you can see in the comments). Also I am particularly NOT saying that the Buffalo II implementation of the Sabre DAC is causing this behavior but that is the DAC I am currently using.
I spent quite a bit of time investigating the locking issue with the I2S interface of the Buffalo II (v1.0) DAC. Keep in mind that we want to use I2S because “conventional wisdom” says that I2S is better than SPDIF and in particular “it has less jitter”. Keep also in mind that the SPDIF interface in Buffalo works flawlessly with the DPLL setting at “Lowest” and that increasing the DPLL bandwidth will allow more jitter to pass through.
The “problem” is that the DAC (when using the I2S interface) will loose signal-lock which results in dropouts lasting a fraction of a second each. The severity of the problem depends on the DPLL bandwidth setting and the time since power-on of the DAC.
In my system, feeding the DAC with a Musiland Monitor USB interface, I was able to eliminate most of the dropouts by setting the DPLL bandwidth to “Medium-Low”. This setting is UP two notches from “Lowest” setting, which is the lowest bandwidth of a total of 7 possible settings (there is an 8th setting with zero bandwidth that prevents locking into the signal)
Additionally, when the DAC is first powered on, the dropouts are much worse, and even setting the DPLL bandwidth to “Highest” would NOT solve the problem. However, as the DAC “warms up”, the number of dropouts becomes smaller until reaching a steady state.
In my system, steady state is reached about ~15 minutes after power-on. At this time, setting the DPLL bandwidth to “Lowest” or “Low” would result in several dropouts within each song. Setting the DPLL bandwidth to “Medium-Low” would result in a dropout every few/many songs.
I did not test whether higher bandwidth would completely eliminate the dropouts but one report (see my previous post) indicate that even at this setting, the problem is not completely eliminated. However, setting the DPLL bandwidth to “Highest” may completely obliterate the advantages of using the I2S interface since the SPDIF interface works perfectly with the DPLL bandwidth set to “Lowest”
I can report that I2S at “medium-low” DPLL BW sounds no worse than SPDIF at “lowest” DPLL BW. In fact is seems to sound better, the music with “more sparkle”. One reader of this blog has indicated that the I2S interface sounds better for him (see previous post).
In any case, at least there is a quest to achieve “lowest” DPLL setting with I2S interface which is something that makes this hobby fun. I can see this happening through:
- More tweaking of the registers in the Sabre32 DAC
- More tweaking of the Musiland Board to lower the input jitter
- ESSTech tweaking the chip to figure out/fix why SPDIF can lock with “lowest” setting and I2S cannot
Also, I have improved the code to support I2S and enable more settings. I will publish that shortly after I clean it up. See my previous post on this subject to understand this issue some more.
Update 1/4/11: This material was posted previously but updated here with the latest information
Reports of having problems with I2S/DSD interface into Sabre32 DAC (the Sabre32 DAC implemented in different products, not just the Buffalo II DAC. So the “problem” is associated with the DAC chip)
To reiterate, the “problem” means using I2S and setting the DPLL bandwidth to “lowest”
- Hiface Evo [Link]
- TPA USB board based on the PCM2707 chip feeding Buffalo II DAC [Link]
- Musiland MINI, based on Spartan FPGA feeding Buffalo II DAC [This post]
- Teralink-X2 based on TENOR TE7022L and 1ppm TCXO feeding Buffalo II DAC [Link]
- AudioGD ESS-based DAC NFB-7 fed from Audio GD sources [Link]. Audio GD has discontinued the product right after launch
- “Manufacturer X” converting I2S into SPDIF before feeding the DAC [Link]
- SDTrans192 [Link] feeding modified Buffalo II DAC with better clocks and other mods. A good summary here [link]
- ElectrArt USB Interface and SACD players feeding Buffalo II DAC and Fidelix CAPRICE DAC : best DPLL bandwidth is medium-low [Link]
- SDTrans192 feeding a diy, highly customized implementation of Sabre32 DAC. This was previously reported as having no lock problem with lowest DPLL setting [Link]
- NeoY2K DAC [Link]
- XMOS USB 2.0 reference board (Link)
- exaU2I (Link). This basically proves that with the default setting at power on, the DPLL is using “best” and thus, no hiccups.
Reports of NOT having problems with I2S interface into Sabre DAC