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/■■ to tear down the connection and setup a new one.
I see these errors when Roon is set to send all content to the ■■ at the same resolution/depth regardless of the original sample.
I agree with you on this. For what it’s worth, I have been able to all but eliminate many variables outside of the ■■ implementation. Some of the things I’ve tested:
Moved Core to 56-core Xeon workstation with local storage – problem persists.
Played back to non-■■ 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 ■■ 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 ■■ 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 ■■ 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!
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 ■■.
@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.
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
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.