Seeking Help from Bluesound Node2 Users

Audio Gear Talk BluOS: NAD & Bluesound
1

I am seeking help from anyone using a Bluesound Node2 as an endpoint for Roon. Mine have been having trouble resulting in freezing, hard crashes and reboots of the Bluesound Node, and degraded sound quality (I suspect).

I would greatly appreciate it if you have a Bluesound Node2 if you could look at the Bluesound log for dropout warnings. The log can be found in the BlueOS Desktop Control Application under:

PLAYER>CONFIGURE PLAYER>DIAGNOSTICS>MORE

I find it easiest to select all and copy the log into an application like Word for easier viewing and searching.

There are two things to check:

Dropout warning messages which will look like this:

Jul 5 16:00:33 (none) user.info dspout: [warning] dropout of 2048 samples at 56152 [2]

And the for any errors in your interface which will show near the top of the log in this section:

if
eth0      Link encap:Ethernet  HWaddr 90:56:82:3F:98:09  
          inet addr:192.168.1.42  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25566300 errors:0 dropped:0 overruns:0 frame:0
          TX packets:985612 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3550086732 (3.3 GiB)  TX bytes:73936617 (70.5 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:11522 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11522 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:1642266 (1.5 MiB)  TX bytes:1642266 (1.5 MiB)

wlan0     Link encap:Ethernet  HWaddr 44:C3:06:10:91:88  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

If you have dropouts, especially if your network interface shows no errors, I would like to hear from you. My attempts in working with support both Roon and Bluesound have not yielded a successful resolution. Thank you in advance.

My Configuration:
Synology 3615 XS+ running Roon Core on SSD, 16GB of Memory
3 Bluesound Node2 Endpoints – all physically wired to router – no Wireless connection

  1. Bluesound Node2 connected to DAC via Coax out
  2. Bluesound Node2 connected to headphone amp via RCA analog out
  3. Bluesound Node2 connected to powered speakers via RCA analog out

Control of playback from iPhone and iPads
Netgear Nighthawk R9000 Router (X10)
Current SW/FW on all systems
Music Library = ~6500 Albums / ~90K Tracks, Redbook FLAC, HiRez FLAC, DxD and DSD
Active Tidal subscription with some Tidal albums added to library (<100 Tidal Albums in library)

@support

2

Hi,

Just wondering where you got to with this? I too have the same pattern with a BS Flex (dropouts, no interface errors, reboots). Only happens with Roon and only when playing Hi Res. I assumed it was my network (Powerline adapters for all my audio devices) but given you have the same issue on wired ethernet perhaps not. Also it’s giving a minimum 50Mbps connection which I think really should be sufficient. Would certainly be interested in any further conclusions you drew. My next step would be to wire the Flex straight into the network switch and test.

3

Sadly, I can’t report that the issue has been resolved. Roon has been very helpful and has taken the back-and-forth with me on this off-line. I have been able to provide them simultaneous logs from the BS and Roon which show the crash/reboot problem. They have told me they agree that it isn’t a network issue and appears to be something in the BS device. They also told me that BS is using a slightly outdated version of the Roon SDK in their released code and that perhaps when they update there may be some improvement – however I would categorize that as speculative at best.

It is interesting to hear that you are seeing this in a Flex, which may have a different processor etc. than the Node2 – potentially indicating a software rather than hardware problem on the BS side. I would suggest you try to capture the logs from the BS, and the two Roon logs that all show the same event and provide to Roon. I suspect the more cases they see the more they might push BS to investigate and act.

While I’ve been pleased that Roon has been responsive and is working with BS, BS has been far less helpful – at least with me as an end customer. BS claims this is a Roon issue and I should work with Roon. Resolving the issue will likely require active involvement from BS as examining the BlueOS kernel is outside of what Roon is likely able to do.

Good luck!!

@brian

4

Thanks for the feedback - I think this has been a problem for sometime - the pattern of dropout behaviour is the same that caused me to quit after my Roon trial about 6 months ago. Returning to it now things are much more stable - previously I would see this when playing 44Khz/16bit. However, it would again put me off making the jump, as I also didn’t experience a willingness from BS to actively engage in a problem that only occurred when using Roon, and I’d like to see things stable with the Flex before pursuing room correction etc. on my main listening system (Node 2 + DAC etc.).

I’m currently testing with the Flex and Core on the same network switch (Netgear GS108Ev3) and will feed back if it manifests to @support - I’m seeing the dropout messages but no crash as yet.

Out of interest, is there anyone playing via Roon to BS Hardware @ 192Khz who isn’t seeing any dropout messages and/or crashes in the logs at all? Would be interesting to get a sense of the scale of the issue.

5

No issues whatsoever with powernode2. I’ve been using BS for several months.
Never had any dropouts and I upsample everything to 24/192.

6

No issues here with a Node 2, upsampling everything to 192 as well.

7

I will add one more observation, however, as it is somewhat subjective and I can not prove it, I have not reported it as an official bug/defect. I believe it to be a symptom of the same crashing issue.

If you look in the BS log (from the BS app) after playing Roon for a while, you will see entries that look like this:

Jul 1 02:55:05 (none) user.info dspout: [warning] dropout of 2048 samples at 51750 [2]

Sometimes just a few of these entries, sometimes quite a few. You will not see these log entries if you just play BS through the BS app.

If I play a recording that is 192/24 (or any resolution for that matter) from Roon and play the same file from BS, I do note that the BS version seems to sound better. It’s hard to put my finger on, however, it has been a frequent enough observation on my part and the part of guest listeners that I suspect there is something there.

8

I’m running a Node 2 (main set) and Pulse 2 (bedroom), both used daily for several hours per day. Out of curiosity, I put the Pulse on WiFi last a few weeks ago (there’s a network cable right next to it :-)). WiFi strength is rated as Fair/2 bars in BS diags – which sounds about right.

For me - no dropouts whatsoever. While I normally don’t upsample through Roon, I’ve been sending 192/24 for the last 2 nights – again, no dropouts. I have scanned the logs of both the Node and Pulse for ‘warning’ and ‘dropout’ – no trace of either one. Except for MQA files, no audible difference when playing from Roon or form the BS app. No freezes, crashes or reboots either.

I realise this does not help you much. Things I would test:

  • Taking the router out of the equation by connecting the Nodes and to NAS to a ‘dumb’ (not managed) simple switch;
  • Check/change all networking cabling between Core and Nodes;
  • Take the NAS out of the equation by running Roon Core temporary on a different system (laptop, whatever – I know your NAS is a beast as far as NAS’s go, but I still wouldn’t put blind faith in it).

It smells like network. Hardware failure of a Node is always a possibility I guess, but three at the same time seems a bit rich.

9

I’m curious - do those with no problems still see these dropout entries in the logs?

@c2c2c2 - interesting observation - I’ll try this on my Node 2 setup sometime, but it is going to be rather liable to a nocebo effect.

10

Yes very occasionaly these show up in the logs:

Sep 6 16:11:32 (none) user.info dspout: [warning] dropout of 2048 samples at 59074 [2]

No idea what those mean and it doesn’t affect playback for me

11

There does seem to be something rather odd going on here. Taking the advice of @RBM I put the Core, Flex and NAS on the same ‘dumb’ Gigabit switch with new cabling and still see dropouts in th elogs and also still experienced a crash, which seems consistent with findings from @c2c2c2 . Likewise, I have also never experienced this crashing through BS natively and there’s nothing else to indicate network errors. I guess it could still be a NAS problem, which I should try to rule out, but that seems unlikely since all it is being asked to do is serve up a comparatively small file. That said, I would expect other BS users to experience this if it was down to some sort of BS firmware bug.

I think I find myself in the same position as you, c2c2c2! I’m not so much worried about whether I can or can’t upsample to a Flex (which is probably largely pointless) but I am concerned about this indicating some underlying problems (whether BS, network or otherwise) that might trip me up if I were to invest in the whole ROCK/Roon experience for my listening room.

12

I generally upsample into a Vault 1 (@24bit 192Khz) using the RAAT protocol and i also occasionally see the “dropout” indication in the logs.
I cannot detect any audible anomalies though, it sounds very good!
From the Logs:

Sep 7 13:02:42 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (907) [1] 127.0.0.1: /Action?service=Raat¬ify=play&stream=0x13fa28&samplecapacity=1920000&streamsample=0&starttime=1504789362733020179
Sep 7 13:02:42 (none) user.info ./ms.pl: Controller::resumeRaat Controller.pm (1693) resumeRaat
Sep 7 13:02:42 (none) user.info dspout: Command(l=50): R789362933
Sep 7 13:02:42 (none) user.info dspout: [warning] dropout of 1920 samples at 101567 [2]
Sep 7 13:02:42 (none) user.info dspout: [warning] dropout of 1920 samples at 103487 [2]
Sep 7 13:02:42 (none) user.info dspout: [warning] dropout of 1920 samples at 105407 [2]

As you may see, i activated upsampling at the first post there and immediately got a few" dropout" indicators in the log.
But there are no further indicators of dropout while playing the first three songs of this album (Kraftwerk - Electric Café, in case you were wondering ;))
It seems to me you will se these when you change sample rates?

Let me also state that my Bluesound/Roon experience have been flawless and 100% stable woth one small exception, and that has happened when i have tranferred a queue from another zone to the Vault. Two times that has caused the Vault to play back the upsampled stream at what o would say was half/third speed! :slight_smile: Very peculiar!
Otherwise, no crashes, excellent source switching and damned good sound from the old Vault!

13

I quote and correct myself,
the dropouts occur when locking onto a stream i’d say. I dont see any while playing back an album with the same sample rates.

14

I have a Pulse 2 in nearly daily use that to my knowledge has never exhibited this behavior. I’ve run it both at 192kHz and bitperfect for long periods (months in each configuration).

I saw it once on a Node 2 after several days of careful setup/testing/continuous playback/monitoring. Multiple theories were tested and debunked–various flavors of network failure/performance problem, thermal issues, etc. I have been unable to make it happen again.

I agree, this needs to be debugged on a technical level at the Bluesound side, since there is really no interesting logging/information flying around at the time of the crash in either their logs or ours, and it’s very clear that something on the device is crashing, since the thing spontaneously reboots. We have no ability to log in, attach debuggers to the code to see what’s going on, etc, since it is their system.

The main thing I want to try to do here is get this issue reproducible within a fixed/known time window, so I can bring it to Bluesound as a tidy package. Given how much I went through to get it to happen just once…I’m not convinced that if I asked them to do the same thing they would get anywhere. Most people would have given up before getting to the point where it finally happened to me. I think I got lucky once, and didn’t necessarily do anything to directly trigger the problem.

@c2c2c2 can reproduce this in a short period of time (1-2hrs). We still don’t know what makes his situation different. He has seen it at 44.1kHz and 192kHz, his network is good, and his thermal situation is more than healthy. So I’m running short of ideas about what the unique factor might be based on his case.

15

Thanks for that feedback @brian. In terms of reproducing the error, if it helps at all, I’ve been running upsampled to 192Khz solidly for the past few days and see a crash roughly once a day. The log information around it varies greatly though - the last crash ended with the relevant portion of the Bluesound log (indeed, the entire day’s logs) being obliterated entirely but this is the first time that’s happend. I’ve just restarted with detailed logging to see if that gives any more info.

Oddly, and unlike c2c2c2, I’ve also started seeing some ‘dropped’ ‘errors’ in the logs (despite currently connecting directly to the switch) which never used to be the case even over Powerline - this may or may not be relevant or simply now be confusing things further!

I should also say thanks to those who identified no problems with their systems - it does seem to suggest there’s something about the environmental context that’s relevant here, if only we knew what.

16

I think these devices sometimes log benign “dropouts” around the start of a stream–these just represent an implementation detail of how the clock management works–basically, the music isn’t due to start until part-way into the first buffer, so silence is inserted just like a dropout. This uses the same code, so it produces the same log message, of course if it happens prior to music starting, it is not an actual problem.

I’m pretty good at tuning them out when reading the logs. If you can’t hear them, that is probably what they are.

17

So, I’ve no idea whether this relates to the problems experienced by the OP, but I contacted BS regarding the similar issues I was experiencing. They in turn advised that I feedback their observerations to @support thus:

"
We can see that from each of the log files that Roon is sending this line ; main::_logRaat ./cp.pl (4395) [bluos_ipc] [1] write_data/sendmsg: (null)

To our Players before it is crashing.

As such we recommend contacting Roon regarding this issue they would have a better idea as to why this message is being sent from the Roon software.

We are also seeing that the Player is reporting a buffer overrun. and discarding 10000 samples at from the orignal 1920000.
This is odd as there should be 192,000 samples not 1920,000."

I would obviously be grateful for any advice you can offer regarding this. As a slight aside (but perhaps more relevant to the OP), I should say that I have so far been unable to replicate this issue on my Node 2.

18

Just for reference, I do indeed see the dropouts in my logs. I’d never noticed before.

19

@brian asserts that dropouts in the BS logs are normal, however I am not sure that I agree. A dropout implies lost data, and this should not be the case as buffering etc. coupled with a stable wired connection should eliminate all dropouts under normal operating circumstances. Lost data = lost information = impact to audio signal. Additionally, I can track dropout errors to mid-track playback, not just start of a stream.

Secondly, logs need to be useful in the information they convey. If the product was designed to have a certain amount of data loss, then it should not be logged every time it occurs but rather only when exceeding a threshold deemed problematic by the designer. Logs full of errors are not useful or normal.

20

@brian,

Perhaps this information from BS as provided above by @dhusky could be the starting point of a conversation with BS on getting to the bottom of this?