Arcam rBlink Bluetooth D/A processor Measurements

Sidebar 2: Measurements

The rBlink is a small, surprisingly heavy, black-finished box made, like all of Arcam's current products, in China. On one end is the jack for the supplied wall-wart power supply, the Bluetooth antenna, and a pushbutton to pair the rBlink with a source; on the other end are two RCA jacks for analog output and a single jack for the S/PDIF digital output.

I tested the rBlink (serial no. EBL 04114) mostly with Stereophile's loan sample of the top-of-the-line Audio Precision SYS2722 system (see the January 2008 "As We See It" and www.ap.com); for some tests, I also used my vintage Audio Precision System One Dual Domain. I used as data sources my iPhone 3GS and iPad 2 (AAC at 256kbps) and MacBook Pro (aptX codec; all MacBooks with OS 10.6.5 or later have aptX), each with its volume control set to the maximum.

I have measured two other Bluetooth DACs: the Chord Chordette Gem and the Musical Fidelity M6DAC. Much of the rBlink's measured performance didn't differ significantly from those two products, being dominated by the Bluetooth codec in use. I ran a complete set of tests from the rBlink's analog outputs; I also repeated many of the tests performing digital-domain analysis on the S/PDIF datastream. In general, the two sets of test results closely aligned.

The S/PDIF output's source impedance was impressively close to the target of 75 ohms, at 74.5 ohms. This will help keep jitter low, provided a digital datalink with a true 75 ohm characteristic impedance is used.

The rBlink operated at sample rates up to 48kHz. Its maximum analog output level at 1kHz was to specification, at 2.11V, and the output preserved absolute polarity (ie, was non-inverting). The output impedance was a fairly low 464 ohms at 20Hz and 1kHz, dropping slightly to 455 ohms at 20kHz. The frequency response with 44.1kHz data was flat from 20Hz to 20kHz, with the two channels matching to within 0.05dB (fig.1). The channel separation at 1kHz was an okay 73.5dB.

1213Ablinkfig01.jpg

Fig.1 Arcam rBlink, frequency response at 44.1kHz (left channel blue, right red, 0.25dB/vertical div.).

The blue and cyan traces in fig.2 show a wideband spectral analysis of the rBlink's analog output while it decoded aptX-encoded, 44.1kHz-sampled data representing white noise. The signal rolls off rapidly above 21kHz, and the series of low-level ultrasonic peaks very closely resembles those published in TI's datasheet for the PCM5102 DAC chip. The red and magenta traces in fig.2 show the rBlink's analog output spectrum with an aptX-encoded full-scale tone at 19.1kHz. The aliasing image of the tone at 25kHz is suppressed by 54dB, and the third harmonics of the tone can be seen at –66dB. The ultrasonic noise floor is higher than it is with white-noise data, the lower-frequency audioband noise floor lies at –70dB, and there is a rise in the noise floor to either side of the 19.1kHz tone.

One thing that has been puzzling me since this review was published in the magazine is that the first null in the reconstruction filter's stop-band lies at 24kHz rather than at 22.05kHz (indicated by the vertical green line in the graph below), which is where it should by rights occur with 44.1kHz data. I re-performed this measurement, making sure that the MacBook Pro's AudioMIDI utility was correctly set to transmit 44.1kHz data to the rBlink. The result was the same as before, however.

1213Ablinkfig02A.jpg

Fig.2 Arcam rBlink, wideband spectrum of white noise at –4dBFS (left channel blue, right cyan) and 19.1kHz tone at 0dBFS (left red, right magenta), with data sampled at 44.1kHz and sourced from MacBook Pro running aptX (10dB/vertical div.).

Sending, from my iPad to the rBlink, AAC-encoded data representing a dithered 16-bit tone at –90dBFS gave the spectrum shown in fig.3. It is significantly cleaner than the spectrum of the Musical Fidelity M6DAC's output decoding the same data (fig.8 at the link above), and the spike that represents the 1kHz tone peaks at exactly –90dBFS, implying excellent DAC linearity. Repeating the analysis with aptX-encoded data gave the spectrum in fig.4. The 1kHz tone is missing, and all the graph actually shows is the rBlink's analog noise floor. That the aptX codec becomes deaf to very low-level signals is graphically shown in fig.5, which plots the linearity error with aptX data against absolute level. When the low-level information is accompanied by high-level data, plotting the linearity error with aptX indicates that, below –80dBFS, the signal is transformed into random noise (fig.6).

1213Ablinkfig03.jpg

Fig.3 Arcam rBlink, spectrum with noise and spuriae of dithered 1kHz tone at –90dBFS with 16-bit data sourced from iPad 2 running AAC (left channel blue, right red) (10dB/vertical div.).

1213Ablinkfig04.jpg

Fig.4 Arcam rBlink, spectrum with noise and spuriae of dithered 1kHz tone at –90dBFS with 16-bit data sourced from MacBook Pro running aptX (left channel blue, right red) (10dB/vertical div.).

1213Ablinkfig05.jpg

Fig.5 Arcam rBlink, 500Hz test signal, DAC linearity error at 500Hz with 16-bit data sourced from MacBook Pro running aptX (left channel blue, right red) (5dB/vertical div.).

1213Ablinkfig06.jpg

Fig.6 Arcam rBlink, 500Hz plus 19kHz at 0dBFS test signal, DAC linearity error at 500Hz with 16-bit data sourced from MacBook Pro running aptX (left channel blue, right red) (5dB/vertical div.).

Turning to high-level signals, fig.7 shows the rBlink's analog output spectrum with an aptX-encoded 50Hz tone at 0dBFS into 100k ohms. The components of the noise floor lie at around –115dB, which implies resolution between 13 and 14 bits; and though the third harmonic is the highest in level, it is still at a very low –93dB (0.0025%). Dropping the load impedance to 600 ohms drove the rBlink into clipping, meaning that it should be used with preamplifiers having an input impedance of at least 5k ohms. Changing to an aptX-encoded tone at 1kHz gave the spectrum in fig.8. The rise in the noise floor is almost 20dB higher than with the low-frequency tone, the aptX codec's limited bit budget becoming more of a problem with the higher-frequency signal. Lowering the signal level by 20dB dropped the noise floor by the same 20dB (fig.9)—but with data streamed from my iPad (fig.10), while the noise floor lies at the 16-bit level, there is a significant amount of spectra spreading of the spike that represents the 1kHz tone, as well as a "skirt" of spurious tones above the frequency of the tone. The spectral spreading suggests some uncertainty in the frequency of the decoded tone; when I listened to the tone, its level was not quite steady.

1213Ablinkfig07.jpg

Fig.7 Arcam rBlink, spectrum of 50Hz sinewave, DC–1kHz, at 0dBFS into 100k ohms, data sourced from MacBook Pro running aptX (left channel blue, right red; linear frequency scale).

1213Ablinkfig08.jpg

Fig.8 Arcam rBlink, spectrum of 1kHz sinewave, DC–10kHz, at 0dBFS into 100k ohms, data sourced from MacBook Pro running aptX (left channel blue, right red; linear frequency scale).

1213Ablinkfig09.jpg

Fig.9 Arcam rBlink, spectrum of 1kHz sinewave, DC–10kHz, at –20dBFS into 100k ohms, data sourced from MacBook Pro running aptX (left channel blue, right red; linear frequency scale).

1213Ablinkfig10.jpg

Fig.10 Arcam rBlink, spectrum of 1kHz sinewave, DC–10kHz, at –20dBFS into 100k ohms, data sourced from iPad 2 running AAC (left channel blue, right red; linear frequency scale).

This is not necessarily jitter. In fact, with the aptX codec, sending 16-bit Miller-Dunn J-Test data to the rBlink gave a narrow spectral spike at 11.025kHz, but with a noise floor around the 10-bit level (fig.11).

1213Ablinkfig11.jpg

Fig.11 Arcam rBlink, high-resolution jitter spectrum of analog output signal, 11.025kHz at –6dBFS, sampled at 44.1kHz with LSB toggled at 229Hz: 16-bit data sourced from MacBook Pro running aptX (left channel blue, right red). Center frequency of trace, 11.025kHz; frequency range, ±3.5kHz.

As I explained in my 2008 article on lossy codecs, it is most revealing to test the codec with a signal that simulates music. The spectrum of this signal, played back from CD and analyzed in the digital domain, is shown in fig.12. The signal comprises groups of tones spaced 500Hz apart, with clear gaps in the spectrum. Across the bottom of the graph, the background noise is uniformly spread out across the audioband. This noise results from the 16-bit Linear Pulse Code Modulation (LPCM) encoding used by the CD medium. Each frequency component of the noise lies around 132dB below peak level; if these are added mathematically, they give the familiar 96dB signal/noise ratio that you see in CD-player specifications.

1213Ablinkfig12.jpg

Fig.12 Digital-domain spectrum of 16-bit multitone test signal at –10dBFS with frequency gaps (linear frequency scale, 10dB/vertical div.).

Fig.13 shows what happened when I streamed this signal to the rBlink from my MacBook Pro using aptX. Peculiarly, the levels of the 500Hz-spaced tones have increased slightly. Below 5kHz, the noise floor drops to –100dBFS, implying 11-bit resolution, but is 30dB higher in the top octave, where the ear is less sensitive. With data streamed from my iPad (fig.14), again the levels of the individual tones are all a little higher than in fig.12, but the noise floor drops to the 16-bit level in the gaps between the tone clusters. This is so even in the top octaves, where preserving absolute resolution is not as important, given human hearing's lack of sensitivity in this region.

1213Ablinkfig13.jpg

Fig.13 Arcam rBlink, spectrum of 16-bit multitone signal, data sourced from MacBook Pro running aptX (left channel blue, right red; linear frequency scale, 10dB/vertical div.).

1213Ablinkfig14.jpg

Fig.14 Arcam rBlink, spectrum of 16-bit multitone signal, data sourced from iPad 2 running AAC (left channel blue, right red; linear frequency scale, 10dB/vertical div.).

These measurements suggest that the rBlink's sound quality will very much depend on the codec used to stream audio data to it. The AAC codec appears to attempt to preserve resolution at the expense of noise-floor modulation and the introduction of enharmonic spuriae (though it is fair to point out that the latter might be masked by the music). By contrast, aptX throws away absolute resolution in favor of preserving a random noise floor, presumably because this will be less annoying with music. But the true test of a lossy codec is to listen to it.—John Atkinson

COMPANY INFO
Arcam
US distributor: American Audio & Video
4325 Executive Drive, Suite 300
Southaven, MS 38672
(866) 965-6050
ARTICLE CONTENTS

COMMENTS
deckeda's picture

John, I'd be interested to see Stereophile spill a little ink on Bluetooth solutions that handle AAC directly. The potential advantage is that the player can (and will) stream the file--unfettered--to the other end and the "Bluetoothness" aspect becomes irrelevant for those who buy music from the world's largest online music seller, or make the effort to choose AAC over some other lossy format before putting songs on their phone, regardless of brand or OS.

Azteca X's picture

Deckeda, that sounds cool but I'm not familiar with that possibility.  Can you link to some products that do so, or any technical writings or forum posts that point to this possibility?

On another note, though I am duly impressed with the rBlink, glad there is a Bluetooth receiver that has proper measurements and a digital out, etc. the elephant in the room is the Apple TV.  Using Airplay, you can use your wifi network (no pesky 25-foot rule - don't have to be on the same floor) and stream losslessly.  How do ya like them apples?  The obvious limitation is that you have to be using Apple devices, excluding a few workarounds.  But if you're using an iPhone/iPod touch, a Macbook Air or Pro or iMac or what have you, Airplay is there and it does 16/44.1 and 16/48 losslessly.  The Apple TV has an optical out and no analog out, so it's only for the DAC crowd, but it works great and has Ethernet and Wi-Fi.  It's also notable that is is only $99 new rather than $249.

Mr. Tellig, it appears you use an iPhone, so I'd love to see you try out an Apple TV.  Return it if you are not pleased!

All that said, I have a dead simple Bluetooth radio in my bedroom that I use plenty for listening to podcast while I clean up or send audio from JRiver to it using JRemote.  Choice is a beautiful thing.

deckeda's picture

I'm sorry but I don't know where I read it. This review got me researching aptX because I'd read the earlier hosanas about it here. That's when I learned all aptX transmissions require the transcode through the "aptX codec".

Somewhere in there is when I also read that AAC gets sent as-is (assuming an AAC file source) and decoded at the Bluetooth reciever.

I'm sure the devil's in the details and especially so with cheap transmitters and recievers.

**********

In my experience, AirPlaying music over to an AppleTV is a recipe for despair. All of them necessarily resample to 16/48 and likely, not terriby well. But 16/48 is ideal for most video sources, so there's that. More to the point, it's never sounded good to me for music, and not by a little bit. Could also be an issue with what happens when the audio gets sent out of the HDMI or TosLINK since ATVs lack their own DAC.

AirPlaying over to my Marantz receiver (built-in AirPlay) is just dandy, as is any AirPort Express, which keeps everything at 16/44.1 bit perfect. And by the way these comparisons were done on the same stereo system.

But I'm with you. If your source is 16/44.1 via either iTunes on a computer or iOS device, an AirPort Express is, and has remained for 10 years, the defacto no-brainer streaming solution for both ease of use and sound quality.

Azteca X's picture

Wow, thanks for the tip.  I had no idea.  Makes perfect sense for video but not good for audio.

Here is some objective verification (yes, measurements included) and details about the current Airport Express for you, Tellig, Atkinson or anyone else!  The SRC will downsample up to 24/96 to 16/44.1 - seems fair enough to me.  In my case I'm using an Oppo (and later a dedicated DAC) for DLNA with JRiver so this would be more for myself or my GF being able to play Spotify, podcasts, internet radio etc. quickly and easily without any extra fuss, sending the optical out to a DAC.

http://www.computeraudiophile.com/content/465-new-apple-airport-express-bit-perfect-still-limited/

http://www.computeraudiophile.com/content/466-measurements-first-and-second-generation-apple-airport-express/

The summary:

 

  • 16 bit / 44.1 kHz music -> Bit Perfect
  • 16 bit / 48, 88.2, 96, 176.4, 192 kHz -> Not Bit Perfect but does play through the AE at 16/44.1.
  • 24 bit / 44.1, 48, 88.2, 96, 176.4, 192 kHz -> Not Bit Perfect but does play through the AE at 16/44.1.
deckeda's picture

Howver, it's nothing new. The original AirPort Express, and 2nd gen (updated to 802.11n) behaved similarly: take most any PCM and give you 16/44.

Chris at Computer Audiophile noted why this is, despite the new AE having a 24/192 DAC. It's the AirPlay standard that limits audio to 16/44. Nothing higher ever leaves the sending computer or iDevice. Doesn't matter how you setup a computer. AirPlay stipulates a transcode on the fly to Apple Lossless 16/44 regardless of the file you're playing back.

You can get the original AE used, from eBay for $40 or less and it'll be just as good as the new one for audio. Windows users might be OK as-is. Mac users would need an OS no newer than 10.7 to configure it, or a script that lets later versions of OS X run AirPort Utility 5.6.1 (The second gen AE, also likely inexpensive now, can I think still be configured with AirPort Utility 6.3)

skris88's picture

Just avoid Bluetooth if you want to pick on it's limitations. 

You cannot make a silk purse out of a sow's ear.

It's like putting wings on a car and saying it doesn't fly very well!

 

X