Bluesound Node N132 Streamer review

[Rja4000]

I wonder how RME does it so well.

I suppose because
1. They know how to do it properly
2. They always measure
3. They use a hardware DSP chip... which, of course, has a cost

 

[Michael Kelly]

Have you done a jitter test of the digital outputs with the AP analyzer? This could tell us how well it does with an external DAC.

 

[VintageFlanker]

Already done, has been there a few days but has now been bumped down by the KEF & A80 reviews.

Missed that one, my bad.

 

[Rja4000]

Have you done a jitter test of the digital outputs with the AP analyzer? This could tell us how well it does with an external DAC.

I wish I had an AP analyzer.

I just have the APx500 flex software subscription. (expensive enough)

My hardware is mainly the RME, with some additions (E1DA APU -useless here-, Scaler, and an UFX III for low noise measurements -also useless in this case + some USB filter, a good DMM,...)

The below link explains what I'm able to measure

RME UFX III Audio Interface review

Unbelievable work! Awesome review and so much information. Thanks a ton for verifying what I've already known for many years. I'm a long time user of RME interfaces. I Have an original UFX in my studio, two Babyface Pro's, and one Babyface Pro FS for location recording and various other bits of...

www.audiosciencereview.com

As you may see, the RME alone is sufficient for the kind of performance we have here.

But for measuring digital jitter, I'd need something else.

What I've done, though, is measuring the analog jitter noise through an attached DAC.
I'll add this measurement to the main post.

 

[Rja4000]

Have you done a jitter test of the digital outputs with the AP analyzer? This could tell us how well it does with an external DAC.

I added the Jitter noise and SINAD measurement with an external DAC to the second post.

 

[pogo]

And, while they are at it, they could also implement a proper parametric EQ, with separate settings for line out and headphones...

Try this project: Link
You may also need to create your own if the ICON one is not loadable. Definitely better than any PEQ

 

[mdsimon2]

But they have a real computer CPU at hand, so why not to do this using floating point precision ?

While I agree that 64 bit floating seems pretty bullet proof, 32 bit floating point seems to require more effort to do well. When I tested CamillaDSP using 32 bit floating point it was the worst DSP I tested in terms of elevated low frequency noise -> https://www.audiosciencereview.com/...nts-and-rising-noise-floor.42383/post-1502569, summary table also shown below.

All DSPs in that table are floating point with the exception of the nanoDIGI (all are 32 bit with exception of CamillaDSP 64 bit) and there is a pretty wide range of performance.

@fabriceo gives some insight on the optimized approach he used when developing AVDSP for the XMOS XU216 in the Okto -> https://github.com/fabriceo/AVDSP_D...ec2aabc9e0e/documents/AVDSP for DAC8 v161.pdf. It is all a bit above my paygrade, but it seems like the basic idea is biquad calculations use 32 floating point with 28 bit mantissa instead of the typical 24 bit mantissa, the result is then stored in a 64 bit (56 bit mantissa) accumulator and passed on to the next step. As the XMOS is resource limited this seems like a good compromise between noise performance and processing power. He also references this paper -> https://ccrma.stanford.edu/~dattorro/HiFi.pdf which may be interesting to those with more knowledge than me!

Michael

 

[Rja4000]

While I agree that 64 bit floating seems pretty bullet proof, 32 bit floating point seems to require more effort to do well. When I tested CamillaDSP using 32 bit floating point it was the worst DSP I tested in terms of elevated low frequency noise -> https://www.audiosciencereview.com/...nts-and-rising-noise-floor.42383/post-1502569, summary table also shown below.

View attachment 432209

All DSPs in that table are floating point with the exception of the nanoDIGI (all are 32 bit with exception of CamillaDSP 64 bit) and there is a pretty wide range of performance.

@fabriceo gives some insight on the optimized approach he used when developing AVDSP for the XMOS XU216 in the Okto -> https://github.com/fabriceo/AVDSP_DAC8/blob/84db3a79f7b378f5789e2956ced9bec2aabc9e0e/documents/AVDSP for DAC8 v161.pdf. It is all a bit above my paygrade, but it seems like the basic idea is biquad calculations use 32 floating point with 28 bit mantissa instead of the typical 24 bit mantissa, the result is then stored in a 64 bit (56 bit mantissa) accumulator and passed on to the next step. As the XMOS is resource limited this seems like a good compromise between noise performance and processing power. He also references this paper -> https://ccrma.stanford.edu/~dattorro/HiFi.pdf which may be interesting to those with more knowledge than me!

Michael

So it seems the issue here is not just a bug.
Rather an initial choice of a weak software implementation method.
I adapted my wording in the measurement post above.

This would therefore require a deeper software change to improve.

With Dirac, they have to implement a more performant algorithm anyway.
So for Dirac-capable devices, it should not be that difficult to implement.

But I suppose they want to keep backward compatibility for the basic BluOS with the oldest devices - which I personally like.

 

[pogo]

But I suppose they want to keep backward compatibility for the basic BluOS with the oldest devices

This should not be a problem, as the firmware can be rolled out on a device-specific basis.

Example:
BluOS 4.8.19
Released February 5, 2025
• Updated Dirac Live support for the M66.
• Performance improvements and feature enhancements.
• This release applies to the NAD M66 only.

 

[Rja4000]

I just added an analysis of the Subwoofer mode

 

[JeremyFife]

Is the node still the only streamer capable of passing bitperfect audio from Amazon Music to a DAC?

Still the cornerstone of my system for this reason - can watch the bitrate adjust accordingly on the ADI2 DAC

WiiM plays nice with Amazon (bit perfect), from the mini up.

 

[Sokel]

I just added an analysis of the Subwoofer mode

15dB higher output, what kind of use case that would fit to?

It also seems dangerous to me to the unsuspected user.

 

[Rja4000]

15dB higher output, what kind of use case that would fit to?

It also seems dangerous to me to the unsuspected user.

It might be that I missed something... (?)
But that's what I measured.

 

[Rja4000]

For those interested, I just created a new Thread with some measurements of the very first Node generation with an external DAC attached.

 

[elmoe420]

WiiM plays nice with Amazon (bit perfect), from the mini up.

The Bluesound devices also have no proper Alexa integration unlike the WiiM which is why we abandoned the former for the latter. I was hoping Bluesound would have fixed this by now but looks like the awful Alexa skill is still your only option.

 

[GXAlan]

The Bluesound devices also have no proper Alexa integration unlike the WiiM which is why we abandoned the former for the latter. I was hoping Bluesound would have fixed this by now but looks like the awful Alexa skill is still your only option.

What is the difference between WiiM and BluOS integration of Alexa?

CONTROL AND ENJOY MUSIC WITH VOICE

With support for the most popular voice assistants, you can use voice commands to play saved playlists, select your favorite radio station, adjust volume levels, or even group Players together and play your music in perfect sync throughout the house.

www.bluesound.com

 

[elmoe420]

What is the difference between WiiM and BluOS integration of Alexa?

CONTROL AND ENJOY MUSIC WITH VOICE

With support for the most popular voice assistants, you can use voice commands to play saved playlists, select your favorite radio station, adjust volume levels, or even group Players together and play your music in perfect sync throughout the house.

www.bluesound.com

Bluesound uses the skill interface. So every time you have to say "Alexa, ask Bluesound, <skill specific command>".

WiiM properly integrated with the Alexa MRM SDK so their devices show up as an "Echo Speaker", just an audio sink essentially. This means you can set them as the default speaker for either multimedia or all Alexa audio, throw them into multiroom media groups with other Echo speakers etc. Most importantly, they can be used with the native Alexa multimedia VUI e.g. "Alexa play music" etc.

 

[HenrikEnquist]

While I agree that 64 bit floating seems pretty bullet proof, 32 bit floating point seems to require more effort to do well. When I tested CamillaDSP using 32 bit floating point it was the worst DSP I tested in terms of elevated low frequency noise

I have looked into this a bit, and the short version is that pure 32-bit float calculations are not enough for low frequency IIR filtering. There are various fancy solutions that are more or less efficient, but they have in common that they require that some calculation steps are done with higher precision than normal 32-bit float, and then keeping track of how much error is introduced by rounding to 32-bit, for doing some form of error feedback. DSP chips have specialized hardware to help with this. For CamillaDSP the equivalent would be to let a 32-bit build do some steps with 64-bit precision and implement the feedback. I think the vast majority of CamillaDSP users run the default 64-bit that doesn't have any issue, so it doesn't feel worthwhile to implement this. It would also slow things down significantly on the weak chips the 32-bit build is useful for.

 

[mdsimon2]

I have looked into this a bit, and the short version is that pure 32-bit float calculations are not enough for low frequency IIR filtering. There are various fancy solutions that are more or less efficient, but they have in common that they require that some calculation steps are done with higher precision than normal 32-bit float, and then keeping track of how much error is introduced by rounding to 32-bit, for doing some form of error feedback. DSP chips have specialized hardware to help with this. For CamillaDSP the equivalent would be to let a 32-bit build do some steps with 64-bit precision and implement the feedback. I think the vast majority of CamillaDSP users run the default 64-bit that doesn't have any issue, so it doesn't feel worthwhile to implement this. It would also slow things down significantly on the weak chips the 32-bit build is useful for.

Very good points!

To be clear I wasn't implying CamillaDSP needed improvement. I agree that almost everyone is using 64 bit CamillaDSP and it is important to note that 64 bit CamillaDSP beats all DSP solutions I tested. Just wanted to give an example of the challenges of 32 bit.

Michael

 

[Rja4000]

Just added a list of all successive Node models at the end of post #3
I'm not 100% sure of those info, so don't hesitate to comment if there is a mistake