The No.1 Website for Pro Audio
 Search This Thread  Search This Forum  Search Reviews  Search Gear Database  Search Gear for sale  Search Gearslutz Go Advanced
Merging Hapi mic pre's vs. Audient ASP 880 Digital Converters
Old 1st January 2017
  #61
Lives for gear
 
tourtelot's Avatar
Quote:
Originally Posted by aracu View Post
If I am interpreting you correctly, are you saying that you need Dante because you use 32 channels of microphones, each with a regular or snake reduced size 300' long xlr cable, and that you want to eliminate the bulk of the cables ?
Yes, and I realize that there are other ways to do this, AVB, Madi and Ravenna to name three, but I have chosen Dante because it seems to have the lead in hardware available, present and future, and the Dante network allows a pretty unlimited addition of devices to the network.

And although you don't need a computer with Dante after everything is assigned, you need it to assign all the paths, and you do need the appropriate gear.

Oh, and I rarely need this multi-mic setup and never 32 mics. But the 32 channel snake and splitter is something I already own. But it is big and heavy

Doug
Old 1st January 2017
  #62
Lives for gear
 

Quote:
Originally Posted by tourtelot View Post
Yes, and I realize that there are other ways to do this, AVB, Madi and Ravenna to name three, but I have chosen Dante because it seems to have the lead in hardware available, present and future, and the Dante network allows a pretty unlimited addition of devices to the network.

And although you don't need a computer with Dante after everything is assigned, you need it to assign all the paths, and you do need the appropriate gear.

Oh, and I rarely need this multi-mic setup and never 32 mics. But the 32 channel snake and splitter is something I already own. But it is big and heavy

Doug
Makes sense, but personally, I feel that wireless ethernet adds a new layer of unreliability.

It seems to me that the audio gear industry makes recordists feel like they have to compete in using large quantities of microphones. The time spent in setting up huge amounts of gear could be used to take more time to set up fewer mics and result in more coherent recordings.

If the recordist is also producing or helping in the production, it is conveniant to not be a far distance away from the ensemble.
Old 1st January 2017
  #63
Quote:
Originally Posted by aracu View Post
Makes sense, but personally, I feel that wireless ethernet adds a new layer of unreliability.

It seems to me that the audio gear industry makes recordists feel like they have to compete in using large quantities of microphones. The time spent in setting up huge amounts of gear could be used to take more time to set up fewer mics and result in more coherent recordings.

If the recordist is also producing or helping in the production, it is conveniant to not be a far distance away from the ensemble.
You don't use Wireless Ethernet - EVER - for IP-based audio.

I'm starting a new thread where I'll discuss some new additions to my ethernet-based location recording rig.
Old 1st January 2017
  #64
Lives for gear
 

Quote:
Originally Posted by Deleted User View Post
No, just cheaper.
and ubiquitous.

I wonder which will be more prevalent in 5-10 yrs. AoIP or MADI?

Last edited by David Spearritt; 1st January 2017 at 11:01 PM..
Old 1st January 2017
  #65
Lives for gear
 
roonsbane's Avatar
To the original question. Before auditioning and eventually purchasing a Hapi system I spoke to a very well know multiple Grammy winning engineer, including a best classical engineered album Grammy. He told me about a comprehensive shootout with some very boutique-e preamps at Tanglewood a few years back. He said that in every blind listening test, with some very heavy hitting engineers and BSO players, the Merging Horus/pre's won out. Meaning most people chose it time and again as being their first choice. He said there were times he would have very slightly preferred a different preamp for a certain sonic, but it always was the overall preference by the group, and it always sounded great! I cant remember specifically which pre's were compared, but Grace and Millenia are a given at Tanglewood, and if I remember there were some much, much pricier preamp/ad combinations in there. I have been so happy with mine. Sometimes, when I have time, I bypass our Neve 88RS and use the Hapi instead.
Happy New Year everyone!
Cameron
Old 2nd January 2017
  #66
Deleted User
Guest
Quote:
Originally Posted by David Spearritt View Post
and ubiquitous
I'm sure you are aware that MADI can be used with fiber, the same cabling IT has been employing for decades, or CAT6, or Ethercon, just like AOIP. Optical Fiber is 1800s technology, it's certainly nothing new. Unless you specifically look at the cabling labels, you will be unable to distinguish the data stream on the "IP" and MADI cable, outwardly they will be identical.

Broadcast, as a single example, is still mostly SDI and MADI, so in that market these formats are still ubiquitous, not IP. IP is only now seeing traction to solve issues with SDI and employing larger fixed channel audio configurations. The majority of those broadcasters moving to IP are still running mixed solutions, so SDI where it makes sense and IP where a solution is required that SDI is unable to solve. Broadcasters are now also employing programmers and IT people before they employ more broadcast engineers to alleviate the now apparent skills shortage. AMWA only projects a potential switch to IP around IBC 2020, once SMPTE 2110 is a standard. As a side note: SMPTE 2110 is the sole reason I see AES67 as a bigger influence than I did before.

The recording industry is still mostly analogue, AES and MADI, so again, in that market IP also isn't ubiquitous. IP is still the cool new kid on the block. Before Merging released HORUS, most on this forum had little idea of the existence AoIP or Dante (which is already in its 10th year), let alone the implementations that came before. AES67 was only ratified in 2013. All credit to Merging's marketing team.

The live and install markets are perhaps one of the few sectors of the audio industry where IP could be called ubiquitous, and even there it's a mix of formats. It certainly isn't the sole solution.


Quote:
I wonder which will be more prevalent in 5-10 yrs. AoIP or MADI?
This is the problem I see with many employing IP, especially among the "new kid on the block is better" folks, who are excited by a new toy, regarding things as an either/or situation. On the contrary, both will still be in play as they serve different needs and solve different problems.

IP exhibits issues that MADI doesn't (such as potential packet loss, security, more time to configure, specialised knowledge), and IP solves limitations with MADI (such as distance limitations, point to point).

And I am still anticipating the first MAC table overflow or MAC flooding attack or worse on a large IP installation. The MADI and SDI parts of the install will still function unscathed and unaware.

Again, let me be clear, I am not anti-IP, which in some form has been in use here for more than just a few years (from 2001 actually with Ethersound and superMAC), and IP and MADI happily coexist, each employed because of its strengths while minimising the effects of its weaknesses. The thing with IP is that it is second nature, having spent years installing and running data networks at broadcasters, in addition to my audio-only duties, that experience is proving to be invaluable.
Old 2nd January 2017
  #67
Lives for gear
 

Quote:
Originally Posted by TMetzinger View Post
You don't use Wireless Ethernet - EVER - for IP-based audio.
You're absolutely right, and sorry for the confusion. "Ethernet" means literally
a type of wired system.
Old 2nd January 2017
  #68
Quote:
Originally Posted by Deleted User View Post
I'm sure you are aware that MADI can be used with fiber, the same cabling IT has been employing for decades, or CAT6, or Ethercon, just like AOIP. Optical Fiber is 1800s technology, it's certainly nothing new. Unless you specifically look at the cabling labels, you will be unable to distinguish the data stream on the "IP" and MADI cable, outwardly they will be identical.

Broadcast, as a single example, is still mostly SDI and MADI, so in that market these formats are still ubiquitous, not IP. IP is only now seeing traction to solve issues with SDI and employing larger fixed channel audio configurations. The majority of those broadcasters moving to IP are still running mixed solutions, so SDI where it makes sense and IP where a solution is required that SDI is unable to solve. Broadcasters are now also employing programmers and IT people before they employ more broadcast engineers to alleviate the now apparent skills shortage. AMWA only projects a potential switch to IP around IBC 2020, once SMPTE 2110 is a standard. As a side note: SMPTE 2110 is the sole reason I see AES67 as a bigger influence than I did before.

The recording industry is still mostly analogue, AES and MADI, so again, in that market IP also isn't ubiquitous. IP is still the cool new kid on the block. Before Merging released HORUS, most on this forum had little idea of the existence AoIP or Dante (which is already in its 10th year), let alone the implementations that came before. AES67 was only ratified in 2013. All credit to Merging's marketing team.

The live and install markets are perhaps one of the few sectors of the audio industry where IP could be called ubiquitous, and even there it's a mix of formats. It certainly isn't the sole solution.




This is the problem I see with many employing IP, especially among the "new kid on the block is better" folks, who are excited by a new toy, regarding things as an either/or situation. On the contrary, both will still be in play as they serve different needs and solve different problems.

IP exhibits issues that MADI doesn't (such as potential packet loss, security, more time to configure, specialised knowledge), and IP solves limitations with MADI (such as distance limitations, point to point).

And I am still anticipating the first MAC table overflow or MAC flooding attack or worse on a large IP installation. The MADI and SDI parts of the install will still function unscathed and unaware.

Again, let me be clear, I am not anti-IP, which in some form has been in use here for more than just a few years (from 2001 actually with Ethersound and superMAC), and IP and MADI happily coexist, each employed because of its strengths while minimising the effects of its weaknesses. The thing with IP is that it is second nature, having spent years installing and running data networks at broadcasters, in addition to my audio-only duties, that experience is proving to be invaluable.
Most of the issues with AOIP were solved decades ago in telephony (Voice over IP), with the principal differences being sampling rates and codecs used. I still see MADI having a future for point-to-point fixed installations, for a relatively short while, say five years. But unless someone comes up with something significantly different and better than IP as a network protocol, I'd bet that five years from now we'll see AOIP as the primary protocol with others dwindling, and in 10 years it will be AOIPv6 with MADI and other stuff in insignificant, unsupported, amounts. I'm not really concerned about the MAC overflow or other security issues - we've been building secure ethernet networks for decades - when the size and the "value" of the network grows large enough, generally the folks who own it spend the money to do it right. Doubtless some folks in audio networking will relearn the same lessons, though.

Whether Dante will still be as widely used, I don't know. In my opinion the value they bring is in the prebuilt hardware core, and the control and user interface, and they (quite rightly) charge money for the value they bring. Whether they can continue to maintain the balance between the value they bring and the price they charge will be the challenge.
Old 2nd January 2017
  #69
Deleted User
Guest
Quote:
Originally Posted by TMetzinger View Post
I'd bet that five years from now we'll see AOIP as the primary protocol with others dwindling, and in 10 years it will be AOIPv6 with MADI and other stuff in insignificant, unsupported, amounts.
I'll happily take that bet. Cirrus Logic said the same about Cobranet in the 2000s, as did Sony with superMAC and Klark-Teknik repeated it again in 2007 with HyperMAC. Digigram said the same with Ethersound. Not one of them was correct, 16 years later we still function quite well in a mixed topology environment.


Quote:
I'm not really concerned about the MAC overflow or other security issues - we've been building secure ethernet networks for decades
During the BBC R&D live IP broadcast trial as well as VRT's live IP broadcast display, it was illustrated how easily the entire broadcast network can be taken down. During a simple attack, in an unusual point of origin, the entire broadcast system was brought to its knees. Dead signal.

France Télévision's proof of concept Live IP broadcast display had a similar lengthy discussion around security which included discussions around the measures they intend to implement before going live.

Broadcasters are taking it very seriously as are the EBU. Certain members even suggested formally participanting in black hat hacking conventions and welcoming participants to circumvent the infrastructure security.


Quote:
In my opinion the value they bring is in the prebuilt hardware core, and the control and user interface, and they (quite rightly) charge money for the value they bring. Whether they can continue to maintain the balance between the value they bring and the price they charge will be the challenge.
I agree. I will say though, that may change very soon and the alternative solution will soon be able to match that experience (which until now has been severely lacking), still be offered gratis, with support also extending to Linux. It will be interesting to see if that affects Audinate in any way regarding their approach.

I will also say, that if Audinate hadn't extended to include AES67 within Dante, things may have been very different for them. It has thankfully become less of an "us vs them" or a "this vs that" discussion, and more of a "how do we make this easier for our customers?"
Old 2nd January 2017
  #70
Lives for gear
 

Interesting discussion. I agree that audio over ip is only secure when hardwired and configured as an intranet option. As soon as you connect to internet, you will be at the mercy of the whole hacking community. I would certainly prefer having my audiosignals over an intranet configuration, and that is not even a real disadavantage.

Thank you all for the valuable info on the Merging Hapi.
Old 2nd January 2017
  #71
Quote:
Originally Posted by Deleted User View Post
I'll happily take that bet. Cirrus Logic said the same about Cobranet in the 2000s, as did Sony with superMAC and Klark-Teknik repeated it again in 2007 with HyperMAC. Digigram said the same with Ethersound. Not one of them was correct, 16 years later we still function quite well in a mixed topology environment.




During the BBC R&D live IP broadcast trial as well as VRT's live IP broadcast display, it was illustrated how easily the entire broadcast network can be taken down. During a simple attack, in an unusual point of origin, the entire broadcast system was brought to its knees. Dead signal.

France Télévision's proof of concept Live IP broadcast display had a similar lengthy discussion around security which included discussions around the measures they intend to implement before going live.

Broadcasters are taking it very seriously as are the EBU. Certain members even suggested formally participanting in black hat hacking conventions and welcoming participants to circumvent the infrastructure security.




I agree. I will say though, that may change very soon and the alternative solution will soon be able to match that experience (which until now has been severely lacking), still be offered gratis, with support also extending to Linux. It will be interesting to see if that affects Audinate in any way regarding their approach.

I will also say, that if Audinate hadn't extended to include AES67 within Dante, things may have been very different for them. It has thankfully become less of an "us vs them" or a "this vs that" discussion, and more of a "how do we make this easier for our customers?"
Agree. Audinate took a longer term view, I think.

Also, on the security, I agree that the minute the signal leaves 'your' network, it's chaos. But as long as you control the infrastructure it can be secure, except for physical attack, which affects all transport.
Old 2nd January 2017
  #72
Deleted User
Guest
Quote:
Originally Posted by TMetzinger View Post
Also, on the security, I agree that the minute the signal leaves 'your' network, it's chaos. But as long as you control the infrastructure it can be secure, except for physical attack, which affects all transport.
In the cited scenarios, certain attacks were internal (i.e. not connected to the internet) to illustrate the potential weaknesses and to demonstrate that the unexpected points of origin can be critical.

Then, there is always user error. One of the more difficult vulnerabilities to solve.
Old 2nd January 2017
  #73
Lives for gear
 

Quote:
Originally Posted by Deleted User View Post
I'm sure you are aware that MADI can be used with fiber, the same cabling IT has been employing for decades, or CAT6, or Ethercon, just like AOIP.
Yes, of course, I am not referring to IP advantage being tied up in the cable, its the "modems" at either end that makes MADI/SDI/AES more specialized than IP.

Quote:
This is the problem I see with many employing IP, especially among the "new kid on the block is better" folks, who are excited by a new toy, regarding things as an either/or situation.
I think its more a convergence of IT and audio/video, as the IT world is solving the same problems. How to move multi-tenanted data around securely. Why reinvent the wheel in audio, if IT (much larger problem solving team) does it for you.

Quote:
IP exhibits issues that MADI doesn't (such as potential packet loss, security, more time to configure, specialised knowledge) ...
Packet loss indicates a faulty system. Billions of packets make it round networks every day without loss. This is hyper anxiety I suspect. But I am pleased you said "potential".

The rest will be solved by UI improvements and better software.
Old 3rd January 2017
  #74
Deleted User
Guest
Quote:
Originally Posted by David Spearritt View Post
Packet loss indicates a faulty system. Billions of packets make it round networks every day without loss. This is hyper anxiety I suspect. But I am pleased you said "potential".
No, even in a well designed broadcasting network packet loss is a reality and a given. In fact packet loss can be introduced when packets are delayed in an dynamically ordered packet routing scheme (i.e. datagrams sent via different paths, out of order and reordered at the receiver within a designated buffer according to a predefined scheme). By nature IP networks can only offer "best effort" delivery of datagrams.

RTP over UDP as the transport layer is the standard for realtime media over IP networks. UDP has no segment numbers or windowing mechanism, so it cannot react to packet loss and it does not include an ACK mechanism.

TCP isn't an option since re-transmission of packets results in packets arriving delayed outside of the buffer in real time media networks, resulting in packets also being received out of order and outside the defined ordering scheme. i.e. reduced quality of experience.

The result is that the user experiences a drop of quality, or other artefacts due to packet loss. 1% packet loss in a live uncompressed video stream will be unwatchable but 0.025% packet loss will be watchable albeit with the occasional glitch in video and possible bursts in the audio soundtrack.

SMPTE 2022-7 SIPS provides potential error-free transport even with packet loss but a packet has to arrive in tact at its destination. SIPS also increases the network bandwidth requirements as it transmits two streams and switches between them when detecting packet loss (i.e. it actually increases the risk of network congestion which may introduce further packet loss). With SIPS, you can still have severe packet loss, it just provides an alternative to forward error correction. But, if both streams have packet loss, you are back to a reduced user experience. If one stream goes down, you are solely reliant on the backup stream which is still prone to packet loss.

ITU-T Rec Y.1541 defines the minimum allowable packet loss according to three different schemes. In other words, the document regards packet loss as a standard feature of the network but defines the probability of packet loss along with the requirements for QoS along with a minumum for the resulting increase in signal delay.

That is not to say that zero packet isn't possible, BBC R&D have successfully concluded tests transmitting UHD video with total bandwidth in excess of 8Gbps with zero packet loss. Other broadcasters have done the same in their trials. Each and every broadcaster still monitors the network in real time in order to minimise the chance of packet loss. In other trials, packet loss (in the 0.025% range) was present especially in larger networks transmitting Super Hi-Vision in excess of 80Gbps, with 22.2 audio, and with more varied traffic, including control, metadata et cetera.

Last edited by reynaud; 3rd January 2017 at 10:56 AM.. Reason: clarity
Old 3rd January 2017
  #75
Lives for gear
 

Hmm, why do these discussions always quickly move to the issues of massive world dominating broadcast systems and 3000 channels of hi-def video synchronizing with 22.2 surround audio at 768kHz sampling?

Packets out of order? Wasn't PTP produced to avoid this? If buffers are expiring, the system doesn't seem well designed for separation of services and throughput. These issues are well understood.

Reynaud, I bow to your superior understanding of these issues.

But I find it hard to believe that the current efforts being expended in AoIP, AES67 etc would be happening if the problems cited above were pervasive.

It certainly seems to work well for small installations such as concert halls, opera houses, symphony orchestras, closed networks etc. And it seems to work without fault for microscopic, insignificant recording setups like mine.

We are definitely off-topic. Apologies for my part in this.
Old 3rd January 2017
  #76
Lives for gear
 

Quote:
Originally Posted by Deleted User View Post
networks transmitting Super Hi-Vision in excess of 80Gbps, with 22.2 audio
I'm curious as to what the content was about with 16 times the resolution of hd
and 24 speakers.
Old 3rd January 2017
  #77
Deleted User
Guest
Quote:
Originally Posted by aracu View Post
I'm curious as to what the content was about with 16 times the resolution of hd
and 24 speakers.
Live sports broadcast with 8K video and NHK 22.2 audio. A live orchestral performance was the alternate reference.
Old 4th January 2017
  #78
Gear Addict
 

Do packets not get reassembled in the correct order? That's the first I've ever heard of that problem. It would, however, explain why my emails have a lot of typos.
Old 4th January 2017
  #79
Deleted User
Guest
This is further off topic, but it's an interesting discussion. Perhaps the mods can create a new thread and leave the original discussion in tact. Apologies to the OP for steering things off course.

This is partly also a response to David Spearritt's response above.

Quote:
Originally Posted by JackHenry View Post
Do packets not get reassembled in the correct order? That's the first I've ever heard of that problem.
If they are correctly time stamped and the checksum matches, and they arrive at the destination within the designated buffer then, yes, they will be reassembled correctly. If not, either because the packet didn't arrive at the destination at all, or it arrived outside of the designated buffer, the checksum didn't match et cetera, the packet will then be dropped automatically.

This isn't necessarily an issue of packets being sent out of order, there are numerous reasons for packet loss.

As a singular example, from Audinate's Dante Controller manual:
"Packet loss results in audio glitches, so it is very important to ensure that all receivers have their latency set high enough to prevent packet loss
...
Latency is set on the receiver. However, when a subscription is made, there is an automatic negotiation process between the receiver and the transmitter, to ensure that the latency for the subscription is high enough to prevent packet loss
...
An amber light indicates that audio packets for one or more channels are arriving at or near the limit of the device's latency setting. You may need to increase the device's latency, or reconfigure the network to prevent audio glitches due to packet loss from late-arriving audio packets
...
Setting device latency too high, however, can interfere with low-latency applications (for example, real- time monitoring when recording vocals), so it is sometimes important to find a balance between low latency and guaranteed audio integrity"

As another example, from the Ravenna draft spec:
"Low UDP packet jitter is desired, as any increase of packet jitter needs to be compensated with larger latency settings or may lead to unrecoverable late packet arrival (which is equal to packet loss)
...
RTP stream packets need to be tagged with a high priority to ensure expedited forwarding. Priority settings are assignable and may vary between streams to allow prioritization between streams or to match individual constraints of certain network configurations. Priority needs to be lower than for PTP packets. Recommended values are EF and AF41. Note: Most existing corporate networks have assigned EF or AFx1 tags to telephony (VoIP) traffic; this needs to be adjusted accordingly as RAVENNA real-time traffic is prone to large packet jitter or packet loss, hence need to be assigned a higher priority than VoIP traffic"

This is how IP networks work by design and with real time video broadcasting pushing large amounts of mixed data, the system becomes even more complex.

I'm surprised this isn't common knowledge among users of AoIP systems. VOIP, for example, requires that packet loss not exceed 1% which results in artefacts occurring roughly once every two or three minutes. In other words, it is expected by design.

This is why you monitor the network, and determine if the dropped packets are audible or if frames are dropped and if they are audible. One can zoom in on an audio waveform that otherwise is audibly "within spec" but still exhibits lost frames (i.e. missing samples and digital black), or the transmitted video has lost frames resulting in out of sync audio.


Quote:
It would, however, explain why my emails have a lot of typos.
Email uses SMTP TCP, whereas live media broadcasting employs RTP over UDP. Different mechanisms.

Last edited by reynaud; 4th January 2017 at 11:47 AM..
Old 4th January 2017
  #80
Reynaud,

What I hear you saying is that AOIP should be:
  • On it's own network, or;
  • On a well-designed/operated/maintained converged network
No argument. Audinate best practices recommend the former, and give information to help network professionals accommodate Dante on the latter.

I'll also agree that networking knowledge at the level of detail needed to build a good converged network is not commonly found in the broadcast/recording/live sound engineering communities (though the large organizations have the ability to find it and hire it). So it IS certainly possible to encounter unpleasant surprises. Of course, the same thing can happen with any technology when practitioners "don't know what they don't know" and don't follow the guidance given to them.

That said, however, I want to give a real-world example of Dante in use to illustrate it's robustness. This morning I set up a test on my home network and ran 32 channels of 24/48 between two Dante devices while monitoring latency performance and loss.

This is NOT a dedicated Dante network - the Dante devices are connected to two different switches with a dumb switch in the middle. Also connected to that switch in the middle are printers, a network storage device, Internet router/wifi, and various smartphones/tvs/laptops/tablets throughout the house. No VLANs, no QOS, just simple unicast switching.

So the test involved having my X32 rack sending out pink noise on all 32 Dante outputs, and my NUC recorder with Dante Virtual Soundcard on the far end subscribing to each of those 32 streams twice, so that Reaper would record 64 tracks, and 32 channels (8 flows/41 Mbps) would flow across the network. I turned everything on, got the subscriptions established, reset the Dante counters, and began the recording and let it run for two hours. At the end of the two hours, here's the histogram from the recorder, showing no late traffic and no losses:

I've stopped the recording but kept the subscriptions up and the audio flowing, and now at 3:15:00 there are still no late packets. I'll continue to let it run until it hits six hours.

Edit - I let it run overnight. Even with backups running across the switch in the middle from various devices to the NAS, there were no late packets - in fact, only two packets out of hundreds of thousands approached the 4 ms buffer.


My point here is that until you get VERY large installations merging different types of near-real-time data (as you mention, lots of 8K video streams and lots of audio channels) that the simple expedient of keeping Dante on dedicated switches will make it work very reliably for 99% of users. Of course, one needs to pay attention to using good cables and such, and be ready to replace gear that fails, but that's the same no matter what.
Best wishes,

Last edited by TMetzinger; 5th January 2017 at 02:26 PM..
Old 4th January 2017
  #81
Deleted User
Guest
Agree. For reference, I use a mixture of Dante/Ravenna/AES67 devices daily with mixed traffic such as control, metadata et cetera, and the system is extremely robust even up to 128 simultaneous channels at 24/96kHz. Zero packet loss although I will admit to the occasional issue that is straightforward to remedy quickly with a little knowledge.

I guess the takeaway should be the IP network equivalent of Bob Ludwig's "never turn your back on digital".
Old 4th January 2017
  #82
Quote:
Originally Posted by Deleted User View Post
I guess the takeaway should be the IP network equivalent of Bob Ludwig's "never turn your back on digital".
Yes. Analog can deteriorate in a somewhat graceful fashion. Digital either is perfect or bad-to-gone.
Topic:
Post Reply

Welcome to the Gearslutz Pro Audio Community!

Registration benefits include:
  • The ability to reply to and create new discussions
  • Access to members-only giveaways & competitions
  • Interact with VIP industry experts in our guest Q&As
  • Access to members-only sub forum discussions
  • Access to members-only Chat Room
  • Get INSTANT ACCESS to the world's best private pro audio Classifieds for only USD $20/year
  • Promote your eBay auctions and Reverb.com listings for free
  • Remove this message!
You need an account to post a reply. Create a username and password below and an account will be created and your post entered.


 
 
Slide to join now Processing…
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
Forum Jump