Let's address the aptX HD in our xDSD. In short, this was a typo, xDSD
doesn't do aptX HD. If anyone feels betrayed, offended, displeased, enraged, apologies to all such individuals for this situation, but...
Let's talk Bluetooth!
Some comments on X-Series Bluetooth. First, Bluetooth implementations vary widely. Just looking at BT revision level or codec support is not useful to understand sound quality potential of a given Bluetooth device.
Yes, Sub Band Codec (SBC) is seriously hobbled and should not be used for music. A very extensive comparison of Bluetooth codecs (sadly excluding AAC) is found here:
With aptX/aptX HD and AAC, optional codecs are available that perform better than SBC, however codec support is a fairly small issue.
By default, most certified Bluetooth modules only offer analogue outputs, directly from the System On a Chip aka. SOC (CSR/Qualcomm in the upper end devices, others in the rest). To get a digital output for SOCs with that option available, a firmware needs to be changed (which is not trivial) and - because is changed in the process - any agency certification needs to be applied yet again, which costs a nice stack of cash.
So most Bluetooth products
rely on a DAC in a chip, to:
- save money for an extra DAC
- save money for firmware changes
- save money for recertification process
The problem is that a DAC/headphone amplifier inside Bluetooth chipsets is usually worse than DAC/headphone amps used in most headphones. For example, let's compare top rated CSR chipset's specs to audio test results of last iPhone with a headphone jack or Apple's lightning to 3.5mm adapter.
With only 96dB dynamic range, aptX HD is wasted in such devices as these only support 16 bit audio on a DAC level and both objective and subjective audio performance from the SOC DAC/headphone amplifier is poor.
To move on, in order to have higher quality Bluetooth audio, we need to bite the bullet and pay developers to enable digital outputs and THEN pay for the recertification of the module according to CE/EMC (European Union) FCC (USA), Giteki (JP) and KCC (Korea) etc. Now we can add an external DAC chip of higher grade.
But hold it, we have another problem.
Clocks. The typical Bluetooth SOC chip creates all clocks (those for audio as well) from a single 26MHz crystal via multiple PLLs of 'adequate' quality. The datasheet for the current 'Top of the Line' CSR chip (the only one that supports aptX HD) lists audio clock jitter as a maximum of 21,000pS in 'high quality' mode (more in power saving)!
In order to deliver 16 bit audio without degradation, jitter must be below
243pS!
So the jitter in the audio clocks actually precludes even 16 bit performance by being almost 100 times as large as the 16 bit limit as long as an external DAC (not the one in a Bluetooth chipset) includes means to clean up this jitter. The real performance will be degraded to only around 10 bit worth of actual audio performance.
If a 'high end' version of a given system produces 100x the jitter permissible for 16 bit audio, effectively limits audio to 10 bit and barely manages 16 bit equivalent SNR with volume control maxed out (even where external higher grade DAC's are used, then Bluetooth associated with poor audio quality is a reputation well deserved.
Noise and jitter levels in standard Bluetooth SOCs are comparable to the worst and darkest day of early digital audio, time when the understanding of what caused 'digital/artificial sound' was poor. The best external DAC will not solve this without extra effort spent on clocks.
Let's get real now:
the extra bits from aptX HD over aptX are not going help here, even aptX and AAC are probably mostly a wasted effort.
In the xDSD we have the ultimate jitter fighting weapon on-board, in addition to our high quality DAC and a headphone amp, a super precise clock and memory buffer already applied to wired connections.
All in all, squeezing the last drop of quality out of Bluetooth is not hard. After dealing with the wireless side, we simply take digital data from a system associated with it in the same way we treat USB and S/PDIF. And finally we get to a point where we can tell the different codecs apart (and aptX wins).
In the xCAN it was more challenging to get a subsystem to get excellent sound from Bluetooth. We naturally can't fit a full xDSD level circuitry and that's why we cherry-picked ESS Sabre instead of Burr-Brown.
We feel that using the ESS Time Domain Jitter Eliminator to kill the jitter from the Bluetooth SOC is decisive in getting excellent sound quality. The reference clock for the ESS DAC is produced from a discrete oscillator with its own low noise power regulator.
Swap in Burr-Brown (as excellent as it is in our xDSD), run it on Bluetooth clocks and the sound quality suffers severely.
The result of these efforts is a level of sound quality from Bluetooth for both xDSD and xCAN that is not comparable to the majority of Bluetooth products.
And yes, adding aptX HD and even LDAC more than aptX HD (as the extra bits of aptX HD are not very useful whereas the 96kHz maximum supported sample rate of LDAC is) would make sense for xDSD and xCAN. However, it requires a substantial R&D time and was not possible for this year's release cycle.
And lastly, slides used in this post were extracted from the Tokyo Headphone Festival presentation by iFi audio, already published by headpie.net at:
If I understood correctly, the xCAN also does a digital-to-analogue conversion, but only for BT through the dedicated Sabre chip, is that right?
