Seeking Help from Bluesound Node2 Users

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.

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.

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

@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.

@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?

Is the change from track1 to track 2 on the same album a new stream? Perhaps, I wouldn’t think that advancing to the next item in the playback queue would necessitate Roon/BS to tear down the connection and setup a new one.

I see these errors when Roon is set to send all content to the BS at the same resolution/depth regardless of the original sample.

@dhusky

I agree with you on this. For what it’s worth, I have been able to all but eliminate many variables outside of the BS implementation. Some of the things I’ve tested:

  • Moved Core to 56-core Xeon workstation with local storage – problem persists.
  • Played back to non-BS device, no issues.
  • Run continuous network ping testing across network connection – no issues.
  • Used TDR equipment to verify electrical integrity of 6a network wiring – no issues.
  • Changed routers from top-of-the-line Netgear to a Cisco – problem persists.
  • Various experiments with differing content – problem persists.
  • Plus a few more things…

Having gone through all of this, I am of the strong opinion that the issue is in the BS unit itself. Perhaps in its network stack or the Roon implementation within the device.

Thanks @c2c2c2 - you’ve clearly been looking into this a lot more thoroughly than I’ve been able to and with a greater depth of network knowledge. What’s perhaps odd, though, is I only see this behaviour on my Flex and not my Node 2, when both are connected to the same switch and other parts of the the system. In fact, the two seem to exhibit quite different behaviours, with the Flex experiencing frequent tear down and re-establishing of connections between tracks (albeit with no audible consequence to this) and the Node apparently carrying on seamlessly. I have no idea why they should act differently.

As to dropouts, I agree the log information is confusing. Certainly, I see higher dropouts (both in the log, and in the initial ifcfg dump) with poorer network connection - this was evident when moving from Powerline adapters to a direct Cat6 connection. A flood of dropouts (for no obvious networking reason) has also sometimes been logged as a precursor to a BS crash. However, as everyone is beginning to agree, they also present in what appears to be a benign way.

I’m obviously happy to share logs or other information with @support if that’s helpful, although (as I’ve said to BS) it feels a bit odd to be sharing feedback back from BS, rather than this all happening directly between them and Roon behind the scenes. I should say my BS experience outside of Roon has been pretty flawless (aside from attempts at using it over Wifi) so I’m really just keen to replicate this stability within the Roon ecosystem (and the many advantages that brings).

It doesn’t matter-- we don’t consider customers to be the target audience for logs, and I’m sure BS doesn’t either. They are for the benefit of the engineers on both sides–people who understand the code.

I never implied that all dropout messages on BS devices are to be considered normal. The thing I said about dropouts before is true: a dropout message that pertains to the period of time just before the music starts playing is benign. Dropouts mid-stream are not benign. The dropout message comes from a low level place that doesn’t have enough information to distinguish these two situations–so it doesn’t attempt to. It’s up to the engineer reading the logs to make the distinction.

To be clear: there is sometimes a dropout message just ahead of a crash. I think that’s a symptom of the system going down, and not the cause of the crash, so it’s not too interesting. There are also dropouts around stream start, which I believe are benign. Also not too interesting. What would be interesting is to know the cause of the crash.

More broadly, I’m not really interested in arguing about the content of log messages or how useful it is for “benign” situations to record something in the log. This is as much a social problem as an engineering problem when you have two companies collaborating to integrate components like this.

Hi John, based on my experiments i’d say either an album or any other queue of tracks with similar sample rates would be considered one (contious?) stream.
@brian suggests the same, that the dropout-mesages in the log likely are benign and does not affect audio. I interpret this as there is some handshaking goin on before the stream can be established.
But, this is highly speculative on my part.

The crashes are a whole different matter though, and i sincerely hope you get this corrected soon!

Thank you, me too.

My apology @brian, I did not mean to imply you said all dropouts were normal - you certainly did not.
.
I also agree that logs should be read by those that understand them. As a customer, I would not have ever thought to start looking at logs were there not problems with the systems crashing.

I am hopeful this will be resolved at some point between Roon and BS.

@support - was the feedback provided by BS of any help in trying to identify this issue? Whilst it’s not going to put me off the move to Roon on ROCK, I’d like to pin it down (and clearly for @c2c2c2 the problem, whether related or otherwise, is more serious). These niggles, along with the timeframe of MQA pasthrough implementation for BS with Roon, do just make me a little hesitant about the combination, however good the products are in their own right.

We passed on a long, detailed analysis of this issue to them. It’s been acknowledged by their support + engineering teams, but we don’t have an update to share yet.

Thanks very much for the time on this and the update - good to hear it’s being followed up.

Hey guys, I am new, Dutch😊, and wonder? Why upsampling the whole bunch to 192 kHz?
Do you only play DVD audio files?
Because PCM 44,1 kHz should always be upsampled to a factor 2 (see menu in de DSP engine) to get a computable correct result. 192kHz is only a result for DVD audio (96 kHz by 2). Why creating an whole lot of jitter en ditter in de RAAT?
Regards

Good question @Theo_Foekens. I would not recommend this for others. I sample everything to 192/24 because I go digital out on BS to a DAC and the DAC makes a rather loud switching sound in the signal when changing sample rates. To avoid this, I want to feed the DAC always with the same sampling rate. As my music collection is mixed in resolution, I chose to sample everything to 192/24 versus other choices. I don’t want to down sample my 192/24 content.

Hello John,
I do understand the motivation to use the same samplerate for you content. But did you ever wonder or asked yourself the main question: Why upsampling at all?
A DAC with a click i.m.h.o. is a DAC for EBAY😊. I use the DAC of the BS and I am very content by the results. Rather more because I clearly distinguish the difference between upsampling and the native samplerate. Upsampling causes jitter, no doubt about it. To eliminate this problem you have to use very expensive technology, if its there. Some say, some don’t. Upsampling sample rates causes major electronic problems in the DSP. To solve these problems you have to use very complicated digital filters (Chord, Fourier analyses), which causes problems of their own. A DAC who processes the original signal is always preferable above the one who needs, or only can upsample to a specific samplerate.
My advice: Lose the DAC, play the Bluesound only, and enjoy the music without a click or jitter. Benefits: Less steps in the signalpath (Shannon); The possibility to hear the real MQA-format, without distortion; And the full control of ROON with RAAT for the total digital highway in your system, including the digital clockworks in your DAC!
Kind regards,
Theo

@Theo_Foekens

I agree with your thoughts about sending my DAC to eBay and I am working on that. For this system (I have a couple), I was waiting for a few more choices on the market for a good network renderer integrated into the DAC before pulling the trigger. It seems to me that many of the fine DACs out there are a bit behind with a USB interface and not an RJ45 – I think most are working on it as putting a computer next to your DAC to output to USB doesn’t really make sense in most configurations in my view. I’m considering MSB Analog DAC, Bricasti, etc.

I have tried using the BS DAC as a method of avoiding the interstitial sound when switching sample rates. Unfortunately, the BS doesn’t begin to stand up in sound quality to my existing DAC. If it were even close, I would switch and use the BS. With luck, my to-be-selected next DAC will give me all the benefits of Roon Ready.

I would love Lindemann to make their Musicbook MQA and Roon Ready.