Audio playback of high res (176/24 and beyond) [Resolved]

Just started happening. No change to hardware or software or network. Seems to only occur with anything above 24/96 quality. Happens on only one system in my network. Based on the error message I began trouble shooting upstream with my QNAP TS-251. But that seems to be OK. I’ve a few other Roon capable devices in my network. Two are microRendu and the one upstairs works fine. Just to be sure I swapped them and also made sure the software levels were the same. The upstair feeds an Audio Alchemy DDP-1 DAC while the downstair system feeds a Berkeley Alpha USB D-D converter (USB to AES/EBU) which in turn feeds a Berkeley DAC.

Here’s the layout of the problem system:

NAS - MacMini - Eero WiFi access point - microRendu are all wired into the switch Cisco SG200-08 unmanaged type. The microRendu plugs into the USB input of the Berkeley D-D converter which outputs AES/EBU to the DAC.

Running Roon Core 1.3 build 223 64 bit on a MacMini late 2014 2.8 Ghz 8 MB mem. Sierra level is 10.12.5
The NAS has two 4 TB WD Red drives. The only elements of my network that are not wired are the upstairs system and an iMac also running the Roon app for playing music through a LH Labs Geek Source plugged into one of its USB ports then to powered speakers. Both of the WiFi connected systems do not have any issue playing back 176/24 of 192/24 files. These are all ripped from disk to uncompressed FLAC and converted to AIF using Jriver Media Center 22.

Tried disabling the NAS in Roon and the plugging in a prior USB WD 5 TB drive with music files. Same result as with the NAS. So, that should put the NAS itself to be as a source of the problem.

Additionally, swapping microRendu devices takes that out of the picture as a source.

Given the error message I can only wonder if the problem is not upstream but downstream, pointing a finger at either the Berkeley D-D converter or worse the DAC.

My next likely step, unless you feel otherwise, is to see if I can eliminate the DAC as a problem by moving the Audio Alchemy DDP-1 downstairs in lieu of the Berkeley DAC. Once I verify that feeding the DDP-1 directly from the microRendu, I’ll put the Berkeley Alpha USB D-D before the DDP-1 to see if it is the culprit.

Hope I’ve provided sufficient details. I can also provide some microRendu info on what it sees relative to the Alpha USB and/or Roon Ready Diag. Info.

Screen shots:



Hi @stevebythebay ---- Thank you for the report and sharing your observations with us. The insight is very appreciated!

Moving forward, I would agree that the next step here should be moving the Audio Alchemy DDP-1 downstairs in lieu of the Berkeley DAC as you have already suggested :thumbsup: :clap: Furthermore, can you verify for me the make and model of Berkeley DAC you are making use of?

-Eric

The DAC is a Berkeley Alpha DAC Reference Series 2. Had a quick chat with them and they poo poo’ed the notion that it might be one of their products. They felt it was upstream. However, I recently had to have the Alpha USB in for repair when an internal fuse went out. That’s why I’m a tad suspicious of that unit. Wish I had a convenient way to verify the DAC itself w/o the presence of the converter. I can also verify that Roon isn’t to blame by installing Jriver on the Mac and testing high res via that software. And, assuming the Audio Alchemy works without a hitch, I can place the converter between the microRendu and Audio Alchemy to see if it’s the culprit. Beyond that, I’ve no means of figuring out how to track down the source of the problem.

Well on a lark I decided to enable WiFi on the MacMini and pull the Ethernet cable from the switch and guess what, I can play 192/24 files without problem. I’m glad it didn’t turn out to be the downstream Berkeley gear.

So, now I’m left to figure out how best to proceed in determining whether I’ve a hardware problem with the Ethernet connection (I can test this theory by using my Thunderbolt-Ethernet dongle) or if that doesn’t seem to “fix” the problem, how best to get a clean Ethernet software stack in place.

Any ideas would be greatly appreciated.

At first, I was going to recommend trying a different ethernet cable and although I do think that’s worthwhile I noticed the following when I re-read your original post.

This is a managed switch (layer 2) and I’ve had a couple of issues with the SG200 switches in the past.

Try logging into the admin interface on the switch and enabling flow control for the ports used by the micro rendu and the mac mini. There have been some odd issues that are similar to the one that you describe that pretty much boil down to the endpoint getting too much data too fast and not being able to tell the core to, “hold up a sec.”

Also, I encountered an issue a couple of years ago with the Ethernet chipset in the Mac Mini not being able to properly autonegotiate with the switch. The connection would come online, but throughput was awful. This was corrected by a combination of a firmware update in the switch and an OS update on the Mini. Since you’re at 10.12.x you’re good on the OS side, but you may need a firmware update on the switch.

So, to sum up…

  1. Try a different cable
  2. Enable flow control on the switch ports involved (or try swapping to a different switch if you have one).
  3. Update the firmware on the switch. Depending on what version you have this process ranges from simple to slightly painful.

Thanks Andrew. Apple provided little help other than to say things looked good. I did a factory reset of the switch earlier today and tried other cables all with the same result. Right now I’ve got all the cables plugged into ports 5-8 which do not offer PoE. Are these available for flow control?

The firmware is up to date based on my most recent checking. And I’ve tried another of my switches that are the same model. I may even dust off an old D-Link 5 port that may still work.

Flow control is set on a per-port basis (under Port Management -> Port Settings).

I’ve never run into this specific problem myself, but from a few quick searches it would appear that you want to enable flow control on the port connected to the Mac Mini.

If it works then don’t forget to hit “Save” in the Cisco web interface so that the change is persistent across reboots of the switch.

Thanks the flow control bit worked like a charm. Not clear what you mean by the “Save” in the interface. I only see the “Apply” button on each interface screen. Where’s the “web interface” Save? Whoops I now see it up at the top in red!

Still no clued how this problem came to pass. I’d never experienced the issue until yesterday, had not updated any software or hardware (macOS, or Roon, which updates on its own). Strange…

In the upper right part of the web interface you should see “Save” flashing with a red X next to it. Click on that and copy the “running configuration” to the “startup configuration.”

If you don’t follow this step then the change will be lost the next time the switch is power cycled.

Got it! Had to switch screens to see it. Always somethin’…

Saw over at CA that managed switches can be an issue with the mR. Recommended to turn off management features or use unmanaged switch.
But if using the flow control definitions worked, that`s great.