Hi, I'm looking for some help with a problem I've been encountering the past three weeks when attempting to multicast stream digital audio to multiple Merging DACs. For four months prior to the error condition arising, I had been successfully (and frequently) using the MAD Driver (v2.1 and then, subsequently v2.2) and ANEMAN for multicast streaming until I hit the wall roughly three weeks ago. The new repeatable behavior is that the multicast connections are initially successfully in ANEMAN and generally remain error free for only 5-10 minutes before the following occurs:
1. MAD returns an error: "Sample Rate Unknown"
2. MAD immediately returns a second error: "ASIO Clock Missing - Is there an audio device properly configured on the network?"
3. All multicast connections in ANEMAN turn orange and ANEMAN returns the following error for each device: "Receiver [ASIO...} of device [DAC...] is in error 132 error code 0x20 - stream has been muted"
The host machine is a Windows 10 PC
The Master ASIO host is generally JRiver Media Center 29
The connected DACs are a pair of NADACs
Network hardware is Ubiquiti - which has been successfully hosting multicast streaming for months
No recent Windows updates or network firmware or software updates.
The only recent change in activity prior to the recurring error condition arising was some recording basic recording/monitoring activity using an ANUBIS and Pyramix running on the same network as described above. It's conceivable that the Pyramix recording sessions caused a setting to be changed in the MAD driver or elsewhere, but for the life of me I have not been able to find the solution.
I should add that unicast works fine - runs for hours without error. The error only arises when attempting multicast, and the error is repeatable - happens every time in fact.
Any help would be greatly appreciated.
Multicast Errors
Forum rules
The Merging Technologies team cannot be held responsible for support queries logged on the public forums. If a support query is logged here and only here, it may not be found and dealt with by the appropriate team.
If you need assistance please contact tech support.
The Merging Technologies team cannot be held responsible for support queries logged on the public forums. If a support query is logged here and only here, it may not be found and dealt with by the appropriate team.
If you need assistance please contact tech support.
Re: Multicast Errors
So this is more than a year after your post that first mentioned this problem. Don't know if you ever resolved it. But I had the same problem and I have resolved it.
The problem for me was that I had the Windows firewall turned on and had not opened needed pathways for the IGMP messages to flow. IGMP are the multicast management messages between computers (including Merging devices) and routers that set up and keep up multicast flows: Internet Group Management Protocol.
If you follow Merging instructions, you simply set up your computer with most of the security services turned off. That disables the firewall, the IGMP messages flow, and all is good. But, to me, that is not a good solution, because it leaves your computer vulnerable to attack. If you're on an isolated network, perhaps that's OK. But if you also use the computer to connect to the Internet in any significant way, then disabling the firewall is not a good idea.
So, I have some detailed analysis below, but first, here are the two solutions I identified for this issue:
1) Disable the Windows Firewall. This should get things working. HOWEVER, if your computer is connected to the Internet, this opens your computer up to potential malicious attacks. I DO NOT SUGGEST this solution unless you're on an isolated network that doesn't see the Internet.
2) Open up an inbound rule on the Windows Firewall to allow incoming IGMP (Multicast) traffic on the firewall. I'll leave it to you to find instructions on other web pages about how to edit Firewall rules in Windows. But the general rule that needs to be added is:
INCOMING FIREWALL RULE:
Name: IGMP for Ravenna on 169.254.0.0/16
Programs and Services: Allow all programs
Protocols & Ports: IGMP
Scope: Remote: IP addresses: 169.254.0.0/16 and 224.0.0.0/24. Local is 'any IP address'
Note that I use the 169.254.x.x network for my Ravenna, and I have another Ethernet port on 192.168.1.x where I connect to the Internet. So in the 'Scope' above (and in the name), I've included the Ravenna network range, but not the other 192.168 network range. This allows incoming IGMP ONLY on my Ravenna network - not on the Internet connected network. You could also set Scope: Remote: Add Addresses to "any IP address", and that would work as well, but it'd leave you slightly more vulnerable if you have networks connected other than a Ravenna network.
If your Ravenna network prefix is anything other than 169.254.x.x (which is entered as 169.254.0.0/16), then replace the above with that network information. For example, if your network is 192.168.10.x, then enter 192.168.10.0/24.
DETAILED ANALYSIS
So before I figured out what the IGMP problem was, this problem first appeared for me when I upgraded from MAD 2.0.4 to 2.2.3. For whatever reason, the old MAD code didn't have the multicast issue. And my solution, at that time, was to downgrade back to 2.0.4 and things worked. But then the newer MAD had some features I wanted to use, so I contacted Merging tech support. They convinced me that my old Dell router must be going bad, and that I should buy a new Cisco router. So I did. The Dells were really old. But the new router didn't help. Back to MAD 2.0.4 again . . . Both routers were configured correctly, by-the-way for Multicast.
Finally, when I had some time, I pulled out the old trusty Wireshark network analyzer software and began packet sniffing. This let me look at all of the messages flowing between the PC with MAD and my Merging devices. I set Wireshark up on a separate PC, and connected the monitoring PC to a port on the Cisco router that was set for "Port Mirroring" to all of the other ports. This way, I could see all traffic on all other ports of the router.
The way IGMP works (simplified) is that each endpoint computer (including Merging devices) that wants to participate in a Multicast stream, as well as the routers between the endpoints, sends out IGMP requests, reports, and membership queries notifying about Multicast stream availability and/or asking to be included in some Multicast streams periodically - say every 30 seconds. MAD sends those out. Merging devices send those out. And the router(s) in the middle send and receive these IGMP messages and based on them, sets up / keeps up the multicast routing to allow the Multicast traffic to flow. If the router sends out an IGMP membership query to an endpoint and doesn't hear a response after a few queries, it will assume the computer that quit responding to the queries no longer wants the multicast stream, and will disconnect that computer from the stream. If the endpoint doesn't hear the membership query announcement of a stream's availability from the router for a period of time, it will assume the stream is no longer available and will quit sending out requests or responses to receive that stream.
What I saw on the wireshark capture was that when things first started, the IGMP messages would flow both ways between the Router and the WIndows PC with MAD on it. But after a while, I noticed that MAD would quit responding to the Router's IGMP membership queries. The router was still sending them out, but MAD quit responding to them. Many of the multicast streams continued. But the one that stopped was on Multicast address 239.1.219.2 stream, which is the ASIO Clock multicast stream. And around 30 to 90 seconds after the router got no response from MAD 2.2.3 to the several multicast membership queries it had sent out, the router quit sending the 239.1.219.2 stream to the MAD PC. That's when the audio stream stopped and the "ASIO Clock Missing" message showed up.
Strangely, if I set up a Ravenna stream flowing from a Merging device TO the PC MAD driver, this problem seems to stop. When MAD is receiving a Ravenna stream, it apparently starts sending IGMP messages regardless of whether it receives the multicast membership queries from the router. But if the only Ravenna flows are from the PC out to some Ravenna device (typical of playback only scenarios), then MAD quits responding to the router's Multicast queries, and audio stops shortly afterwards. This problem does not occur with MAD 2.2.0 or 2.0.4. I'm guessing that MAD 2.2.0 sends out IGMP messages regardless of whether it receives any multicast membership queries from the router, and that's probably why it works and 2.2.3 (and probably later versions as well) doesn't.
Anyway, now the question was: why isn't MAD 2.2.3 responding to the IGMP membership queries from the router? What I figured out was that the Windows firewall was blocking the incoming router IGMP Membership query messages. So MAD never saw them, and after a while, MAD quit sending out its IGMP response messages. (apparently MAD 2.2.0 sent these messages regardless of whether it saw the membership queries, which is why it continued to work.) So what can block the incoming IGMP membership queries that are definitely on the Ethernet? A FIREWALL can do that!
So just to test it out, I disabled the Windows Firewall. Voila! Now things worked, and the audio never stopped flowing. MAD 2.2.3's began responding to all of the router's IGMP membership queries, and the router therefore kept the multicast stream for the ASIO clock up and running for MAD. But as I've said before, I don't think this is a good long-term solution. Without a firewall, any internet-connected computer becomes vulnerable to attack. Yes, a router between the internet and your computer will block a lot of malware. But its still best to have a firewall in place. So, I looked at what firewall rules I could add to the Windows firewall to allow IGMP messages to flow to/from local computers on my Ravenna network without being blocked, while still having the Firewall in place to protect against malicious traffic.
I created a rule to allow incoming IGMP on my Ravenna network. I'm using the 169.254.x.x. network for Ravenna, so I set up a new Windows Firewall rule as follows:
Name: IGMP for Ravenna on 169.254.0.0/16
Programs and Services: Allow all programs
Protocols & Ports: IGMP
Scope: Remote: IP addresses: 169.254.0.0/16 and 224.0.0.0/24. Local is 'any IP address'
This resolved the problem. Now, I could keep the firewall turned on and still get Ravenna traffic to flow correctly without the "ASIO Clock Missing" error that stops audio flow.
While I was in the Firewall settings, other things I made sure were enabled for incoming passthrough in the firewall were: mDNS, File and Printer sharing, Network Discovery, and the rtpMIDISvc. They were already enabled in my setup, but if not enabled, those might cause problems in a Ravenna setup.
Merging has provided setup instructions that indicate to disable security features. I get it. If you just turn that stuff off, things work. And if you don't turn those things off and things don't work, it can be awfully difficult to figure out what is breaking things (as I can attest and have described above). But again, turning off security is NOT a good idea on any internet connected computer. Disabling the Firewall and UAC are both weakening the security posture of your PC, and make you more vulnerable to malicious attack. So what I'd really like to see from Merging would be something along the following lines in their documentation:
1) If your computer only connects to an isolated audio network with no network connectivity to the Internet or other potential malicious networks, the simple approach is to disable security aspects on your computer to allow the Ravenna traffic to flow freely. You can disable the Windows Firewall and User Account Control (UAC) for the simplest, most straight-forward approach to pain-free operation. (Then point at their current setup methods)
2) If your computer connects to any network, directly or indirectly, that could be malicious, and that includes the Internet, then the safest approach is to configure your computer for secure operation while sill allowing Ravenna traffic to flow. This is more work than option #1, but will result in a your PC remaining protected against malicious intent from the outside. (Then point to another document that goes through how to set up Ravenna securely, including leaving the Firewall enabled and how to create Firewall rules to allow the required Ravenna traffic to flow).
Just my $.02
The problem for me was that I had the Windows firewall turned on and had not opened needed pathways for the IGMP messages to flow. IGMP are the multicast management messages between computers (including Merging devices) and routers that set up and keep up multicast flows: Internet Group Management Protocol.
If you follow Merging instructions, you simply set up your computer with most of the security services turned off. That disables the firewall, the IGMP messages flow, and all is good. But, to me, that is not a good solution, because it leaves your computer vulnerable to attack. If you're on an isolated network, perhaps that's OK. But if you also use the computer to connect to the Internet in any significant way, then disabling the firewall is not a good idea.
So, I have some detailed analysis below, but first, here are the two solutions I identified for this issue:
1) Disable the Windows Firewall. This should get things working. HOWEVER, if your computer is connected to the Internet, this opens your computer up to potential malicious attacks. I DO NOT SUGGEST this solution unless you're on an isolated network that doesn't see the Internet.
2) Open up an inbound rule on the Windows Firewall to allow incoming IGMP (Multicast) traffic on the firewall. I'll leave it to you to find instructions on other web pages about how to edit Firewall rules in Windows. But the general rule that needs to be added is:
INCOMING FIREWALL RULE:
Name: IGMP for Ravenna on 169.254.0.0/16
Programs and Services: Allow all programs
Protocols & Ports: IGMP
Scope: Remote: IP addresses: 169.254.0.0/16 and 224.0.0.0/24. Local is 'any IP address'
Note that I use the 169.254.x.x network for my Ravenna, and I have another Ethernet port on 192.168.1.x where I connect to the Internet. So in the 'Scope' above (and in the name), I've included the Ravenna network range, but not the other 192.168 network range. This allows incoming IGMP ONLY on my Ravenna network - not on the Internet connected network. You could also set Scope: Remote: Add Addresses to "any IP address", and that would work as well, but it'd leave you slightly more vulnerable if you have networks connected other than a Ravenna network.
If your Ravenna network prefix is anything other than 169.254.x.x (which is entered as 169.254.0.0/16), then replace the above with that network information. For example, if your network is 192.168.10.x, then enter 192.168.10.0/24.
DETAILED ANALYSIS
So before I figured out what the IGMP problem was, this problem first appeared for me when I upgraded from MAD 2.0.4 to 2.2.3. For whatever reason, the old MAD code didn't have the multicast issue. And my solution, at that time, was to downgrade back to 2.0.4 and things worked. But then the newer MAD had some features I wanted to use, so I contacted Merging tech support. They convinced me that my old Dell router must be going bad, and that I should buy a new Cisco router. So I did. The Dells were really old. But the new router didn't help. Back to MAD 2.0.4 again . . . Both routers were configured correctly, by-the-way for Multicast.
Finally, when I had some time, I pulled out the old trusty Wireshark network analyzer software and began packet sniffing. This let me look at all of the messages flowing between the PC with MAD and my Merging devices. I set Wireshark up on a separate PC, and connected the monitoring PC to a port on the Cisco router that was set for "Port Mirroring" to all of the other ports. This way, I could see all traffic on all other ports of the router.
The way IGMP works (simplified) is that each endpoint computer (including Merging devices) that wants to participate in a Multicast stream, as well as the routers between the endpoints, sends out IGMP requests, reports, and membership queries notifying about Multicast stream availability and/or asking to be included in some Multicast streams periodically - say every 30 seconds. MAD sends those out. Merging devices send those out. And the router(s) in the middle send and receive these IGMP messages and based on them, sets up / keeps up the multicast routing to allow the Multicast traffic to flow. If the router sends out an IGMP membership query to an endpoint and doesn't hear a response after a few queries, it will assume the computer that quit responding to the queries no longer wants the multicast stream, and will disconnect that computer from the stream. If the endpoint doesn't hear the membership query announcement of a stream's availability from the router for a period of time, it will assume the stream is no longer available and will quit sending out requests or responses to receive that stream.
What I saw on the wireshark capture was that when things first started, the IGMP messages would flow both ways between the Router and the WIndows PC with MAD on it. But after a while, I noticed that MAD would quit responding to the Router's IGMP membership queries. The router was still sending them out, but MAD quit responding to them. Many of the multicast streams continued. But the one that stopped was on Multicast address 239.1.219.2 stream, which is the ASIO Clock multicast stream. And around 30 to 90 seconds after the router got no response from MAD 2.2.3 to the several multicast membership queries it had sent out, the router quit sending the 239.1.219.2 stream to the MAD PC. That's when the audio stream stopped and the "ASIO Clock Missing" message showed up.
Strangely, if I set up a Ravenna stream flowing from a Merging device TO the PC MAD driver, this problem seems to stop. When MAD is receiving a Ravenna stream, it apparently starts sending IGMP messages regardless of whether it receives the multicast membership queries from the router. But if the only Ravenna flows are from the PC out to some Ravenna device (typical of playback only scenarios), then MAD quits responding to the router's Multicast queries, and audio stops shortly afterwards. This problem does not occur with MAD 2.2.0 or 2.0.4. I'm guessing that MAD 2.2.0 sends out IGMP messages regardless of whether it receives any multicast membership queries from the router, and that's probably why it works and 2.2.3 (and probably later versions as well) doesn't.
Anyway, now the question was: why isn't MAD 2.2.3 responding to the IGMP membership queries from the router? What I figured out was that the Windows firewall was blocking the incoming router IGMP Membership query messages. So MAD never saw them, and after a while, MAD quit sending out its IGMP response messages. (apparently MAD 2.2.0 sent these messages regardless of whether it saw the membership queries, which is why it continued to work.) So what can block the incoming IGMP membership queries that are definitely on the Ethernet? A FIREWALL can do that!
So just to test it out, I disabled the Windows Firewall. Voila! Now things worked, and the audio never stopped flowing. MAD 2.2.3's began responding to all of the router's IGMP membership queries, and the router therefore kept the multicast stream for the ASIO clock up and running for MAD. But as I've said before, I don't think this is a good long-term solution. Without a firewall, any internet-connected computer becomes vulnerable to attack. Yes, a router between the internet and your computer will block a lot of malware. But its still best to have a firewall in place. So, I looked at what firewall rules I could add to the Windows firewall to allow IGMP messages to flow to/from local computers on my Ravenna network without being blocked, while still having the Firewall in place to protect against malicious traffic.
I created a rule to allow incoming IGMP on my Ravenna network. I'm using the 169.254.x.x. network for Ravenna, so I set up a new Windows Firewall rule as follows:
Name: IGMP for Ravenna on 169.254.0.0/16
Programs and Services: Allow all programs
Protocols & Ports: IGMP
Scope: Remote: IP addresses: 169.254.0.0/16 and 224.0.0.0/24. Local is 'any IP address'
This resolved the problem. Now, I could keep the firewall turned on and still get Ravenna traffic to flow correctly without the "ASIO Clock Missing" error that stops audio flow.
While I was in the Firewall settings, other things I made sure were enabled for incoming passthrough in the firewall were: mDNS, File and Printer sharing, Network Discovery, and the rtpMIDISvc. They were already enabled in my setup, but if not enabled, those might cause problems in a Ravenna setup.
Merging has provided setup instructions that indicate to disable security features. I get it. If you just turn that stuff off, things work. And if you don't turn those things off and things don't work, it can be awfully difficult to figure out what is breaking things (as I can attest and have described above). But again, turning off security is NOT a good idea on any internet connected computer. Disabling the Firewall and UAC are both weakening the security posture of your PC, and make you more vulnerable to malicious attack. So what I'd really like to see from Merging would be something along the following lines in their documentation:
1) If your computer only connects to an isolated audio network with no network connectivity to the Internet or other potential malicious networks, the simple approach is to disable security aspects on your computer to allow the Ravenna traffic to flow freely. You can disable the Windows Firewall and User Account Control (UAC) for the simplest, most straight-forward approach to pain-free operation. (Then point at their current setup methods)
2) If your computer connects to any network, directly or indirectly, that could be malicious, and that includes the Internet, then the safest approach is to configure your computer for secure operation while sill allowing Ravenna traffic to flow. This is more work than option #1, but will result in a your PC remaining protected against malicious intent from the outside. (Then point to another document that goes through how to set up Ravenna securely, including leaving the Firewall enabled and how to create Firewall rules to allow the required Ravenna traffic to flow).
Just my $.02