AUDIO over IP - REDNET 3 & 16 Review. AES67 Sets A New Standard for Computer Audio
Sep 1, 2016 at 2:48 PM Post #1,711 of 3,694
 
​I can go either way. I have SFP PCIe cards in both my Audio PC and Control PC so I can use fiber or CAT . When I want to go fiber I use single mode and when I use CAT I'm using a blue jeans 5e. I find I switch up.

 
Have you updated your D16 to the new software and firmware yet?
 
Sep 1, 2016 at 10:10 PM Post #1,712 of 3,694
   
Have you updated your D16 to the new software and firmware yet?


​Yes, thanks to the folks on the Forum I updated as soon as I knew about it. Works fine. However, I still need to change the Antelope liveclock rate manually. Not a big burden. I grew up listening to LP's and having to change sides every 15-20 minutes. One manual mouse click is not bad at all. In a weird way, I kind of like the extra engagement.
 
Sep 2, 2016 at 2:45 AM Post #1,713 of 3,694
I just finished up the upgrading process of the rednet control and firmware. Using foobar, the sampling rate automatically changed and working smoothly. Thanks for the info on the new firmware, this forum is very useful.
 
Sep 2, 2016 at 7:46 AM Post #1,714 of 3,694
 
​Yes, thanks to the folks on the Forum I updated as soon as I knew about it. Works fine. However, I still need to change the Antelope liveclock rate manually. Not a big burden. I grew up listening to LP's and having to change sides every 15-20 minutes. One manual mouse click is not bad at all. In a weird way, I kind of like the extra engagement.

 
Boy. I forgot about my Antelope!  I have pretty much the same setup as you but I kept my Antelope at 192K. The odd thing is that I have seen my Yggy change sample rate as I move to different pieces at different rates. Go figure!
 
I will need to do a bit of experimentation.
 
Sep 2, 2016 at 10:55 AM Post #1,715 of 3,694
Are you saying the antelope changes sampling rate automatically too? Or is it jus clocking suboptimally...
 
Sep 2, 2016 at 2:35 PM Post #1,716 of 3,694
Are you saying the antelope changes sampling rate automatically too? Or is it jus clocking suboptimally...


I think it will the last. It will have clocked the signal with the wrong word clock.
 
Sep 2, 2016 at 2:55 PM Post #1,717 of 3,694
I think it will the last. It will have clocked the signal with the wrong word clock.

 
Boy. Not sure how I missed this. So much for "on the fly" rate changing. I often switch between tracks on albums and seldom listen to a whole album straight through so I will probably not be jumping up to toggle the Antelope to match the current sample rate. Makes me long for a high quality "no hold barred" single chassis AOIP solution...
 
The good news is that everything sounds wonderful with just setting it all to 192K even though RedBook 44.1K should probably be overclocked at a multiple such as 176K.
 
...And still much better than USB.
 
Sep 2, 2016 at 3:59 PM Post #1,718 of 3,694
Ok. One more mystery that came with the upgrade. Previously I had 176K as a choice from the dropdown box in Rednet Control.
 
Now it is gone.
 
I know that the RN3 did not support 176K but my D16 did previously.
 
If you have a D16 and upgraded do you see 176K as a choice in Rednet Control?
 
Sep 2, 2016 at 4:12 PM Post #1,719 of 3,694
Word back from Focusrite about the SR Follow issue on Mac.
 
It seems that the mac version of DVS has an issue of some sort WRT working properly on Mac in Media Center.
 
This issue has/will be passed along to Audante for evaluation etc.
I also hope that this can lead to the correction of other minor but frustrating issues I'm seeing as well.
 
Ah, the trails and tribulations of being an early adopter… 
atsmile.gif

 
JJ
 
Sep 2, 2016 at 10:33 PM Post #1,720 of 3,694
Boy. Not sure how I missed this. So much for "on the fly" rate changing. I often switch between tracks on albums and seldom listen to a whole album straight through so I will probably not be jumping up to toggle the Antelope to match the current sample rate. Makes me long for a high quality "no hold barred" single chassis AOIP solution...

The good news is that everything sounds wonderful with just setting it all to 192K even though RedBook 44.1K should probably be overclocked at a multiple such as 176K.

...And still much better than USB.


This is probably the key reason I'm waiting on the ref10. I'm hoping it does the sampling rate change.

[COLOR=1F497D]Ok. One more mystery that came with the upgrade. Previously I had 176K as a choice from the dropdown box in Rednet Control.[/COLOR]

[COLOR=1F497D]Now it is gone.[/COLOR]

[COLOR=1F497D]I know that the RN3 did not support 176K but my D16 did previously.[/COLOR]

[COLOR=1F497D]If you have a D16 and upgraded do you see 176K as a choice in Rednet Control?[/COLOR]


Wow. Seems the RN3 is really the likely better buy for most, then...
 
Sep 2, 2016 at 10:34 PM Post #1,721 of 3,694
Well, I spend a some time trying to wrap my head around how this equipment now hangs together. I have Rednet D16 to Mutec MC3+ USB to DAC. An Antelope LiveClock connects to both the D16 and the Mutec to provide external wordclock. The Mutec re-samples whatever is sent to it.
 
For some reason it never crossed my mind that the Antelope provided one rate at a time and did not change as the output rate of the music server changed. Since it is pro gear I guess that this makes sense as they probably choose one rate for a session and keep everything at that rate. What this means to me however is that even with the D16 now able to change rates then as JRiver sends different rate the Antelope must be manually changed to match. Compounding this problem is he discovery that for some reason 176K was dropped after applying the update. The only reason this really matters to me is that I found that upsampling from 44.1 to 176K sounded really great. I could do this manually however it is sort of a pain and needs to be done by using RDP to access the server which then causes Rednet Control to close.
 
I have to admit that I am now a bit at a loss to see how to conveniently let JRiver determine the rate that the DAC finally sees. As I said before the good news is that if I set everything to 192K the sound is still wonderful.
 
Any ideas, tips, or educational input will be gratefully received...
 
Sep 2, 2016 at 11:54 PM Post #1,722 of 3,694
I just set everything to 24/96 as my music is about 70% 24/96... no reclock or liveclock. Foobar 24/96 and hit play - enjoy. I also just set the 24/96 because it's all my system can handle at the moment until I get on a 5th or 6th gen i5/i7 boat. Until then I'll save the frustration for when my computer is capable and just enjoy the Rednet 3 by itself to the dac.
wink_face.gif

 
Sep 3, 2016 at 12:33 AM Post #1,723 of 3,694
  Well, I spend a some time trying to wrap my head around how this equipment now hangs together. I have Rednet D16 to Mutec MC3+ USB to DAC. An Antelope LiveClock connects to both the D16 and the Mutec to provide external wordclock. The Mutec re-samples whatever is sent to it.
 
For some reason it never crossed my mind that the Antelope provided one rate at a time and did not change as the output rate of the music server changed. Since it is pro gear I guess that this makes sense as they probably choose one rate for a session and keep everything at that rate. What this means to me however is that even with the D16 now able to change rates then as JRiver sends different rate the Antelope must be manually changed to match. Compounding this problem is he discovery that for some reason 176K was dropped after applying the update. The only reason this really matters to me is that I found that upsampling from 44.1 to 176K sounded really great. I could do this manually however it is sort of a pain and needs to be done by using RDP to access the server which then causes Rednet Control to close.
 
I have to admit that I am now a bit at a loss to see how to conveniently let JRiver determine the rate that the DAC finally sees. As I said before the good news is that if I set everything to 192K the sound is still wonderful.
 
Any ideas, tips, or educational input will be gratefully received...

 
 
My mind is kind of fuzzy but I could have sworn a few months ago (well before this update but not sure what version it was) not seeing 176K in my RedNet Control app (and beginning to panic) but instead seeing it and being able to set it in the Dante Controller instead.
 
As far as the Antelope is concerned, not a big deal for me but I can see how it could confuse people because you will get playback whether you manually reset the sample rate or not. As you mentioned, most Pro studios likely set one rate per session and do not switch things  track by track. Perils of using Pro  gear.
 
I know several people set Jriver to 192K and upsample everything. I tried that for a while but switched back and actually prefer using native sample rate with the Yggy.  Does upsampling everything bypass the Schiit Mega-Burrito Filter?
 
Sep 3, 2016 at 2:13 AM Post #1,724 of 3,694
In researching my latency issue, I came across the following from the AES67 Config section of Audinate's Dante Controller Users Guide:
 
For supported devices (Brooklyn II v3.9.x devices and up), the Device View also includes an AES67 Config tab. The AES67 Config tab allows the selection of AES67 mode for the device.
AES67 is a standard for audio over IP interoperability.
Devices in AES67 mode are able to transmit and receive AES67 multicast flows to/from non-Dante AES67- enabled devices.
Between Dante devices, Dante's native audio transport protocol is used instead (even when AES67 is enabled for both devices).
 
Based on this information, I concluded the following:
  • The RedNet 3, being a Brooklyn I type device, does not support AES67.
  • Dante's native audio transport protocol (not AES67) is used for AoIP communication between the DVS and the RN3.
 
Can someone correct me, if I've misstated anything?
 
Sep 3, 2016 at 2:37 AM Post #1,725 of 3,694
  In researching my latency issue, I came across the following from the AES67 Config section of Audinate's Dante Controller Users Guide:
 
For supported devices (Brooklyn II v3.9.x devices and up), the Device View also includes an AES67 Config tab. The AES67 Config tab allows the selection of AES67 mode for the device.
AES67 is a standard for audio over IP interoperability.
Devices in AES67 mode are able to transmit and receive AES67 multicast flows to/from non-Dante AES67- enabled devices.
Between Dante devices, Dante's native audio transport protocol is used instead (even when AES67 is enabled for both devices).
 
Based on this information, I concluded the following:
  • The RedNet 3, being a Brooklyn I type device, does not support AES67.
  • Dante's native audio transport protocol (not AES67) is used for AoIP communication between the DVS and the RN3.
 
Can someone correct me, if I've misstated anything?


​Correct. My understanding is your point #2 is also true for those with Brooklyn II (D16). The default setting is the Dante  transport protocol. However, for those with Brooklyn II they can switch to AES67 if they have a need (environment with mixed Ravenna and Dante gear for example)
 

Users who are viewing this thread

Back
Top