Focusrite REDNet

[Serge_S]

So? I don't understand the point you are making?

 

EEE reduces responsiveness of the switch required for the Real Time AOIP.

 

My point was that Audinate does not recommend using EEE. If you go back to Mattias’s post, if I understood him correctly, he still had latency issues after using EEE adopter. I should’ve replied to him rather than to Joel. My bad.

[Superdad]

Hi Alex

 

W.r.t the Merging Virtual Sound Card, the Merging website states the existence (and actually allows download of) their software.

 

 

It has (as of yet) limitations that would prevent wide-spread use, (such as support for 44 & 48 kHz only, but there exists a Premium version for use with the Merging HORUS and HAPI, so who knows what can be negotiated). But I can find only the OSX version, though IIUC there should also be a Windows version in existence and Linux version under development.

 

Comparisson of Standard vs Premium version of Merging Sound Card software:

 

 

I would also consider this a giant leap if their software would become generally available or licenseable for other parties with AES67 products.

 

I hope to hear more from dbrulhart about the Merging SOund Card s.w

 

Hi Aleg: Thanks for pointing that out. Of course OS X only and 44/48 only won't yet attract other DAC manufacturers, but perhaps Merging will eventually go further. I am just not sure why they would give away their software IP, seeing as they are the ones who developed it and will have to keep it up to date through OS evolutions.

 

I really think that the AES67/Ravenna consortium of companies would see far greater adoption of it if they put some money in a pot to lobby Microsoft and Apple to incorporate virtual sound card drivers/APIs into Windows and OS X.

 

As mentioned, Microsoft does not include UAC2 for USB audio (which is a royal pain for users). So why have async-USB audio interfaces thrived? Because XMOS enlisted Thesycon to write and keep current Windows drivers for their chips--and the license to them comes free to OEMs (and Thesycon makes extra money licensing a premium version to those who desire it). XMOS did the smart thing as evidenced by its USB dominance over others such as CMedia and VIA, who have struggled to keep their own drivers current, to the detriment and distress of the OEM DAC makers. And those DAC makers who have decided to write their own drivers for--their own (often FPGA chips) DAC--have had a tough road as well, often lagging at each OS change or simply not providing drivers for some platforms (exaSound to Linux users: "sorry").

 

In the end, every interface--be it audio, data, or otherwise--lives or dies based on the software and driver support. So to will it be with audio over IP.

 

Someone said they though Merging or other industry players might be reading this thread. Although my message is a very obvious one, I do hope someone is listening so that we can all look forward to a thriving future market of usable Ethernet-input DACs.

[mourip]

Someone said they though Merging or other industry players might be reading this thread. Although my message is a very obvious one, I do hope someone is listening so that we can all look forward to a thriving future market of usable Ethernet-input DACs.

 

When I started this thread it was for two reasons. First, the thread on Head-Fi that got the ball rolling for many of us had been temporarily shut down due to some "over-spirited interchange" (sound familiar?) and second because I was so thrilled with the improvement in my own system over USB that I wanted to give back to CA for all of the useful learning I had gained here.

 

Let's expand this thread to the broader topic of AOIP in general and I also hope that manufacturers will weigh in.

 

This is a chance for us all to gain...

[tranz]

Hi Alex - I remember that conversation like it was yesterday. You were one of the only people at CES in 2008 who actually got computer audio and had an idea where it was headed. Plus, you were one of the only people who would talk to me at the show. The other manufacturers all "knew" this computer audio crap was just a fad and that computer based sources could never sound better that the existing disc spinners. It sounds laughable now, but that was the case back then.

 

Anyway, I want to back Alex's comments that he has been researching audio over ip for years and wasn't trying to offend anyone. When I saw the Ethernet port on his DAC in 2008 it was only a dream of how one would get audio out of the Ethernet port on a computer and into this DAC. I remember talking to Alex about how to get iTunes to send audio over Ethernet. My how things have changed.

 

Slim Devices had products on the market for years before that. I was enjoying streaming over LAN and wifi using the Squeezebox more than 10 years ago. They had the audiophile Transporter back in 2006. Way ahead of the times they were. I am just glad it is coming back around.

[Aleg]

Hi Aleg: Thanks for pointing that out. Of course OS X only and 44/48 only won't yet attract other DAC manufacturers, but perhaps Merging will eventually go further. I am just not sure why they would give away their software IP, seeing as they are the ones who developed it and will have to keep it up to date through OS evolutions.

 

.....

 

My feeling is that Merging, being one of the first partners the designers of Ravenna turned to, is probably the one party among all partners, that is best suitable to develop and maintain this kind of software.

 

They may have 'donated' a scaled down version to help along the adoption of the Ravenna protocol, that critically depends on the availability Virtual Sound Card software. They (the Ravenna consortium) have to develop and generally release/license software that allows access to all the features and high-end capabilities (352/384 & DSD), otherwise they will not create enough of a difference to get alongside Dante.

 

They promote Ravenna by emphasising these capabilities over the current limit of 192kHz in Dante (though I believe that 192kHz limit only to be a designers choice and not an inherent limitation of the protocol), so Ravenna will have to deliver on that and in an easy accessible way.

 

I think this year will show interesting developments in the AOIP world, though my feeling is that in the professional audio world things don't happen as fast as in the world of consumer high-end audio.

 

cheers

[Aleg]

Slim Devices had products on the market for years before that. I was enjoying streaming over LAN and wifi using the Squeezebox more than 10 years ago. They had the audiophile Transporter back in 2006. Way ahead of the times they were. I am just glad it is coming back around.

 

Yes, nowadays you see several solutions like that and like what JPlay has developed (the dual PC setup) a few years ago.

The Dante/Ravenna/AES67 protocols are far more robust however, they have to be to be of any value in the pro-audio world. I also think that renderers that have been built for the purpose (unlike the JPlay and NAA type solutions that use general purpose computers) have a far better chance of creating exceptional sound quality than those formentioned solutions using general purpose computers as renderer.

 

We will have to wait, see and listen, but the reported exceptional quality of the two Rednet devices makes it very promising to me.

[gldgate]

Yes, nowadays you see several solutions like that and like what JPlay has developed (the dual PC setup) a few years ago.

The Dante/Ravenna/AES67 protocols are far more robust however, they have to be to be of any value in the pro-audio world. I also think that renderers that have been built for the purpose (unlike the JPlay and NAA type solutions that use general purpose computers) have a far better chance of creating exceptional sound quality than those formentioned solutions using general purpose computers as renderer.

 

We will have to wait, see and listen, but the reported exceptional quality of the two Rednet devices makes it very promising to me.

 

I can't agree more. What has amazed me almost more than the sq has been the robustness of the Dante solution. I've had my D16 for 16 days now without a single dropout. This includes playing at sample rates from 44Mhz to the RedNet limit of 192Mhz.

[jelt2359]

I am curious how much taking USB out of the chain is due to the specific dac's implementation. I think the Yggy's (which I own) is not ideal, with numerous reports of the Mutec being a big improvement.

 

Whats interesting is there's a growing club on another site who are using the microRendu with the Chord Dave, who's designer has gone on record to say that USB is that dac's best input because their implementation has built-in galvanic isolation. This is unfortunate for me as it may not work well with my Mutec, given that I have a microRendu input already occupying the sole USB port.

 

Another alternative is AES in to the Mutec (from the Rednet) and then USB out. Who knows, that may in fact provide the best sq of all even for the Chord Dave.

[Matty70]

My point was that Audinate does not recommend using EEE. If you go back to Mattias’s post, if I understood him correctly, he still had latency issues after using EEE adopter. I should’ve replied to him rather than to Joel. My bad.

 

Yes, that's true.

But this feature can easily be disabled.

 

When including the link in my post, the forum software automatically chose the display text

 

"Energy-Efficient Ethernet Evolves Networks"

 

instead of the URL or something like 'Intel I210T1'.

 

It was not my intention to highlight the energy efficiency feature.

 

Btw - of course I cannot guarantee that changing the network adapter improves every system.

 

My recommendation based on my personally experiences would be to look at the network infrastructure first, if you want to integrate Dante in an existing network.

I think, my most successful measure was to replace the switch and to configure it like recommended on the Focusrite webpage.

 

Perhabs it is interesting to know, that my old switch had QoS features too, but it was not possible to configure the DSCP values in detail. And this was exactly what improved the performance and stability most.

[mourip]

I am curious how much taking USB out of the chain is due to the specific dac's implementation. I think the Yggy's (which I own) is not ideal, with numerous reports of the Mutec being a big improvement.

 

Whats interesting is there's a growing club on another site who are using the microRendu with the Chord Dave, who's designer has gone on record to say that USB is that dac's best input because their implementation has built-in galvanic isolation. This is unfortunate for me as it may not work well with my Mutec, given that I have a microRendu input already occupying the sole USB port.

 

Another alternative is AES in to the Mutec (from the Rednet) and then USB out. Who knows, that may in fact provide the best sq of all even for the Chord Dave.

 

Good point about the quality of USB engineering for specific DACs although pretty much everyone reporting back on their RedNet devices have seen improvement. As far as the Iggy I have read that even one of it's designers prefers the AES input. That is what I am using with a Mutec +3 USB between D16 and DAC.

 

Regarding "AES in to the Mutec (from the Rednet) and then USB out" I believe that the Mutec only has USB input.

[jelt2359]

Good point about the quality of USB engineering for specific DACs although pretty much everyone reporting back on their RedNet devices have seen improvement. As far as the Iggy I have read that even one of it's designers prefers the AES input. That is what I am using with a Mutec +3 USB between D16 and DAC.

 

Regarding "AES in to the Mutec (from the Rednet) and then USB out" I believe that the Mutec only has USB input.

 

That would make sense, but the Mutec manual does say USB input/output. I'm still waiting on my Mutec so I can't test this unfortunately. This might ultimately be a reason to purchase a Rednet to try with chord Dave for me, if the Mutec does indeed do USB out.

 

Anyhow the Mutec this does not work optically with the dave I intend to leave it permanently hooked up to the yggy.

[mourip]

I can't agree more. What has amazed me almost more than the sq has been the robustness of the Dante solution. I've had my D16 for 16 days now without a single dropout. This includes playing at sample rates from 44Mhz to the RedNet limit of 192Mhz.

 

+1

 

I can add that I am pretty sure that the D16 makes the chain more immune (unnecessary) to the usual PC tweaks also. I am experimenting with the newest version 2.0 of Audiophile Optimizer, which I have used for a couple of years, but I am not sure that it makes a difference now...if any. I am also running in GUI mode rather than my usual Core Mode on my 2012R2 box and still seeing a big improvement over the previous USB/AO/Core Mode setup.

 

Lots more data points to get but this seems very promising.

[Aleg]

....

Regarding "AES in to the Mutec (from the Rednet) and then USB out" I believe that the Mutec only has USB input.

 

 

No, definitely Mutec has USB input AND output. It is a very special feature of Mutec compared to other DDC devices.

[Superdad]

No, definitely Mutec has USB input AND output. It is a very special feature of Mutec compared to other DDC devices.

 

Hi Aleg:

Can you please clarify that? The Mutec has only one USB jack--a 'B' type, for connection to a computer. There is no indication (I skimmed the manual) that it can act as a host to output directly to a DAC via USB. Some rather different circuitry (and s/w) would be required for it to output to a DAC. Don't know why one would want to do that anyway, but I do want to be sure I am understanding the capabilities of the flexible Mutec.

Thanks,

--Alex C.

[mourip]

No, definitely Mutec has USB input AND output. It is a very special feature of Mutec compared to other DDC devices.

 

I reread my Mutec manual and you are correct however it only has one USB port so you could not receive USB from one device and then send USB out to another.

 

I guess you could take SPDIF or AES from one device and send USB to another. Most folks seem to do the opposite which is to take USB in and send out AES. I am taking AES in and sending AES out, letting the Mutec re-clock. This has given me an SQ improvement with the Mutec between my D16 and my Yggy.

 

Lots of room for experimentation however...

[Aleg]

Hi Aleg:

Can you please clarify that? The Mutec has only one USB jack--a 'B' type, for connection to a computer. There is no indication (I skimmed the manual) that it can act as a host to output directly to a DAC via USB. Some rather different circuitry (and s/w) would be required for it to output to a DAC. Don't know why one would want to do that anyway, but I do want to be sure I am understanding the capabilities of the flexible Mutec.

Thanks,

--Alex C.

Hi Alex

 

Of course. Taken from the Mutec MC3+USB product description:

Audio streams received via USB will always be converted to five audio outputs allowing multiple devices to receive the same audio simultaneously. Upon selecting one of the audio inputs, the signal will be converted into a USB audio stream to be sent to the computer.

 

I see now one could read my previous reply as havin simultaneous input and output. That is not what I meant. I tried to say what is in the quote from Mutec. So it is "either or", but USB is bi-directional.

 

Cheers

[Superdad]

I reread my Mutec manual and you are correct however it only has one USB port so you could not receive USB from one device and then send USB out to another.

 

I guess you could take SPDIF or AES from one device and send USB to another.

 

Well yes and no: As Aleg quoted the manual, "Upon selecting one of the audio inputs, the signal will be converted into a USB audio stream to be sent to the computer."

 

That was my point--to clarify that the Mutec can not be a USB "host" device to output USB to a DAC.

(This is consistent with the many pro-sound USB interfaces out there, some of which, like my old Edirol UA-5 from 2006, have A/D and D/A conveyers as well, so analog or S/PDIF inputs can also feed back into the computer. Not that I am comparing performance of that to the Mutec.)

 

I think it is very rare to see an FPGA device set up to be a full USB host to output UAC2 to a DAC. Much more s/w involved then.

 

 

Sorry for contributing to the OT conversation. Sure was enjoying the cordial spirit and openness of the AIOP discussion from the past couple of days.

 

On that note, what do folks think about why DLNA managed to get such an early hold in home network audio? Was it lack of alternatives? Was it better coordination or OS s/w support by the consortium? Was it because the the big CE and TV companies embraced it? I honestly don't know because I have pretty much eschewed UPnP/DLNA the whole time. But I think we AOIP enthusiasts (and AES67 supporters) might do well to look to the past successes and failures of DLNA to chart a course.

 

Just my $.02.

[Miska]

On that note, what do folks think about why DLNA managed to get such an early hold in home network audio? Was it lack of alternatives? Was it better coordination or OS s/w support by the consortium? Was it because the the big CE and TV companies embraced it? I honestly don't know because I have pretty much eschewed UPnP/DLNA the whole time. But I think we AOIP enthusiasts (and AES67 supporters) might do well to look to the past successes and failures of DLNA to chart a course.

 

UPnP got where it is because big consumer electronics companies just included it in their products and formed the DLNA to make them actually compatible. I was involved in some of that stuff too on my Nokia days...

 

But overall, I wouldn't even talk about UPnP and AES67 in a same forum posting, because the two are so different, coming from different worlds and for completely different purpose/goals and requirements. The only common denominator I can see is that both can do audio.

 

UPnP/DLNA is essentially:

1) Web server with bunch of media files

2) Player software that can play a file from the web server

3) Control point software that tells player what to play from the server (URL)

(and due to this architecture, there are completely idiotic things in the implementation such as seeking)

[Cebolla]

On that note, what do folks think about why DLNA managed to get such an early hold in home network audio? Was it lack of alternatives? Was it better coordination or OS s/w support by the consortium? Was it because the the big CE and TV companies embraced it? I honestly don't know because I have pretty much eschewed UPnP/DLNA the whole time. But I think we AOIP enthusiasts (and AES67 supporters) might do well to look to the past successes and failures of DLNA to chart a course.

Lack of alternatives at the time, I'd say, riding on the back of the much larger home network video market. Also UPnP/DLNA uses the network merely to provide access to (audio) files, ie file streaming, derived from traditional computer client/server concepts. This is different to the more alien task (re traditional computing) of using the network as a conduit for the real-time digital audio signal itself, as required by AOIP and AES67. So UPnP/DLNA arguably makes a much simpler use of the network, with the audio file player being at the receiver side of the network, as opposed to the source side of the network with AOIP and AES67.

[Superdad]

UPnP got where it is because big consumer electronics companies just included it in their products and formed the DLNA to make them actually compatible. I was involved in some of that stuff too on my Nokia days...

 

But overall, I wouldn't even talk about UPnP and AES67 in a same forum posting, because the two are so different, coming from different worlds and for completely different purpose/goals and requirements. The only common denominator I can see is that both can do audio.

 

Hi Jussi:

Glad you are here. I fully agree that UPnP/DLNA is a very different (and some would say primitive) thing in comparison to an RTP system such as AES67/Ravenna, but I was thinking about the paths to adoption and use, and wondering if the proponents of the latter could learn business lessons from the former.

 

Hardware-wise I have some questions as well.

If you look at the various available DLNA renderer module (such as the expensive Swiss ABC-PCB NMR, or the newer, less costly Conversdigital boards, they seem to have similar processor capability and architecture to the Dante Brooklyn and Covlez BACH modules.

 

Obviously the code and functioning of the above two camps is very different, but it would be nice to get a sense of what it will take for DLNA module makers to migrate towards other AIOP standards.

 

Also, John (Swenson) looked very closely at the AES67 specs and concluded that its clocking architecture--designed for low-latency multi-device broadcast/venue applications--is far more complicated with excess overhead than is needed or ideal for stereo audio application. As the designer of the streamlined NAA protocol, would you care to comment?

 

Thanks and regards,

--Alex C.

[Superdad]

Lack of alternatives at the time, I'd say, riding on the back of the much larger home network video market. Also UPnP/DLNA uses the network merely to provide access to (audio) files, ie file streaming, derived from traditional computer client/server concepts. This is different to the more alien task (re traditional computing) of using the network as a conduit for the real-time digital audio signal itself, as required by AOIP and AES67. So UPnP/DLNA arguably makes a much simpler use of the network, with the audio file player being at the receiver side of the network, as opposed to the source side of the network with AOIP and AES67.

 

Hi Cebolla (Mr. Onion!): Great to see you here too.

 

Your assessment is no doubt correct (video market drove UPnP/DLNA), and of course the server/renderer/controller model is different (and appealing in its own way) than RTPs like NAA, AirPlay, Dante, Ethersound, Cobranet, AES67, etc.

 

What is interesting though--and hence my question above to Miska, is that the modules for both seem to require a similar amount of process horsepower to perform their rendering duties. Why is that?

[Miska]

Lack of alternatives at the time, I'd say, riding on the back of the much larger home network video market. Also UPnP/DLNA uses the network merely to provide access to (audio) files, ie file streaming, derived from traditional computer client/server concepts. This is different to the more alien task (re traditional computing) of using the network as a conduit for the real-time digital audio signal itself, as required by AOIP and AES67. So UPnP/DLNA arguably makes a much simpler use of the network, with the audio file player being at the receiver side of the network, as opposed to the source side of the network with AOIP and AES67.

 

Well, the RTP/RTCP/RTSP/SDP protocols (AFAIK used by AES67/RAVENNA) already existed and were used for example to provide audio and video calls over internet when combined with SIP protocol already at that time. We implemented also those to the mobile phones (our first productized internet video call stack was on 770 Internet Tablet). PTPv2 used for clock synchronization is a bit newer standard and was mostly used first together with AVB standard (which is common for example in automotive segment).

 

From my point of view, it is only about different industry groups doing different stuff for different purposes with different requirements and especially wanting to make their own standard instead of using someone else's (political part of the story).

 

Technically, UPnP was never designed for things like:

1) Recording content

2) Doing low-latency live processing (audio from microphones on a stage to a mixer and from there to the PA system)

 

 

P.S. DLNA is just a consortium to agree on list of common formats - required/optional for interoperability. Because UPnP standard itself doesn't say anything about the exact content formats and codec features. DLNA then specifies things like "renderer supporting video playback shall support AVC Base Profile 640x480 @25fps in MPEG-4 Program Stream" and "renderer supporting audio playback shall support MPEG-1 Layer III audio at 44.1 kHz 16-bit stereo".

[jabbr]

the modules for both seem to require a similar amount of process horsepower to perform their rendering duties. Why is that?

 

The AES67/Ravenna modules I've seen involve an FPGA -- NAA does not use RTP as far as I know, I'm assuming a socket and without knowing any actual details, I assume NAA uses something similar to the ALSA/USB format just over TCP/IP.

[Aleg]

...

On that note, what do folks think about why DLNA managed to get such an early hold in home network audio? Was it lack of alternatives? Was it better coordination or OS s/w support by the consortium? Was it because the the big CE and TV companies embraced it? I honestly don't know because I have pretty much eschewed UPnP/DLNA the whole time. But I think we AOIP enthusiasts (and AES67 supporters) might do well to look to the past successes and failures of DLNA to chart a course.

...

 

I think this was just the first network application in A/V, so lack of alternative and all CE manufacturers just put it in their appliances.

 

From a user perspective, it was just there and allowed network access in a fairly simple way. Simple device discovery. Simple 'unicast' flows. Big hurdle was finding combinations of server, renderer and controller software that actually worked.

On the software side, being just for playback and not recording purposes, things can be made a bit simpler than for Pro-audio, like automatic channel mapping, automatic following of sample rates.

Interesting times to see how AOIP develops into the consumer market.

[dbrulhart]

Hi dbrulhart

 

Thank you for your postings that gives us more insight in the Ravenna products from Merging. Very interesting developments indeed.

Is it correct that the "Merging RAVENNA/AES67 Virtual Audio Device - STANDARD Installer" is only available for OSX, or am I overlooking the proper link for Windows?

I immediately applied for the temporary download access of course, but fail to see the Windows version of the Virtual Audio Device.

 

Thanks for your help.

 

All Merging devices ship with a Ravenna ASIO and CoreAudio driver. Professional products ship with a driver that supports AES67 and offers all flexibility to choose between the various flavors of Ravenna and AES67. Consumer products ship with a slightly modified version of the driver that uses Unicast and highly simplifies the way the connections are done between the hardware (NADAC) and the computer host running the driver (or VSC), no additional application is required to route the signal, only the NADAC front panel and/or related iOS apps are required to select which computer/playback source on the network the NADAC will listen to. Things are slightly more complex though flexible on the pro side.

For the time being these two drivers/VSC require a Merging equipment pro or consumer to be functional. They can connect to other Ravenna/AES67 compatible equipment on the network, but one Merging device must be present on the network for now.

However, we released in January the first version of a driver which doesn't need the presence of a Merging equipment on the network and this is the so called "Merging RAVENNA/AES67 Virtual Audio Device - STANDARD Installer". This is to promote and establish AES67 on the market as we strongly believe this is the future of AoIP. For technical/performance reasons this is available for now only on the Mac platform. We will release a Windows version down the road. A Linux version is also in preparation.