@mhakman
Transmitting or receiving audio in a Cobranet network won't work with a standard Ethernet card. What you can do is controlling the network or sending auxiliary data, but for audio you need a card with a Cobranet chip.
Firewire is definitely worth thinking about. There you can stream audio and video from a PC without problems, because isochronous streaming is an integral and standardized feature of Firewire. Suitable hardware for DIY would be the DICE chips from tc applied technologies.
Transmitting or receiving audio in a Cobranet network won't work with a standard Ethernet card. What you can do is controlling the network or sending auxiliary data, but for audio you need a card with a Cobranet chip.
Firewire is definitely worth thinking about. There you can stream audio and video from a PC without problems, because isochronous streaming is an integral and standardized feature of Firewire. Suitable hardware for DIY would be the DICE chips from tc applied technologies.
These guys make a firewire<-> I2S board if it will help.
http://www.zpeng.com
It would be exremely difficult, if not impossible, to source CobraNet audio directy from a PC unless you can write drivers with very strict deterministic timing to make sure all the CobraNet frames are sent when required. Absent that you would need to build the CobraNet I/F into a PCI or PCMCIA card using CobraNet chips.
But there are probably a number of ways that you could get digital audio from the PC to a CobraNet interface if you then wanted to use CobraNet to distribute audio on a network.
Steve
http://www.zpeng.com
It would be exremely difficult, if not impossible, to source CobraNet audio directy from a PC unless you can write drivers with very strict deterministic timing to make sure all the CobraNet frames are sent when required. Absent that you would need to build the CobraNet I/F into a PCI or PCMCIA card using CobraNet chips.
But there are probably a number of ways that you could get digital audio from the PC to a CobraNet interface if you then wanted to use CobraNet to distribute audio on a network.
Steve
Yes, of course, CobraNet doesn’t use IP protocol; it is its own protocol. IP is one type of Ethernet payload, Netbios is another, and CobraNet is yet another one. In Ethernet protocol (or rather in what is commonly called Ethernet protocol) there is a slot bearing ID (a number) of the type of payload embedded within Ethernet envelope. IP has its own number, Netbios (or rather Netbui) has its own, CobraNet has its own etc. Then of course you cannot use the whole IP stack to send or receive other protocols than IP. However, near the bottom of network stack there is a level where you can feed (or get) whatever payload you want. You need to write a stack for CobraNet and interface it to the link level. If software driver for CobraNet using plain network cards would exist then this stack would be a part of the driver.
Ethernet is CSMACD type of network. This means that before sending a packet a network device has to “listen to” the network for clear (without payload) carrier signal. Until it receives clear carrier it will wait because it means that some other device is sending. Then during the transmission it compares the signal it sends with the signal on the wire. If the 2 don’t agree then we have a collision and the device performs a recovery procedure which causes all devices to stand back for a while and then start sending again with a random delay statistically computed in such a way that only 50% of devices will start sending (provided they have something to send) within the time interval required for one whole packet to traverse the whole net. If we get another collision at this moment then the recovery procedure is repeated with random statistical delay resulting in only 25% of all devices starting to send etc. until there are no collisions. Because of this, the latency and delivery time cannot be guaranteed. If CobraNet cards are to work on plain Ethernet together with other devices (which the FAQ says) then they must obey these rules too. Then it doesn’t help that a special CobraNet card is very fast, with precise timing etc. Delays, latency and therefore jitter is caused by cooperation among devices, not by an individual device and must be taken care of by using other means (buffering and good protocol at higher levels?). I would guess. Those who know better please do correct me; otherwise I still don’t see why you couldn’t use plain Ethernet card to do the job, at least from technical point of view.
Concerning ADAT, it won’t do for me. I need either 3 2-channel or 6 1-channel S/PDIF or AES/EBU streams. I was considering getting one of those FW/USB external boxes providing ADAT (LightPipe) (there are some very nice boxes out there) but then I would need to demultiplex ADAT to 3 or 6 S/PDIF channels and the only devices capable of doing this that I found and still in production/market are very expensive. Perhaps I could build my own demultiplexer out of of-the-shelf ADAT demux IC, a Toslink component and 3 S/PDIF IC’s plus transformers. But it feels more right to use another method of which CobraNet would be one. I would prefer a solution giving me support up to 192 kHz sampling frequency which neither ADAT nor CobraNet give. Why? 24 Mbits/sec is not that much – my notebook pumps out about 60 Mbits/s over Ethernet. Well, perhaps I would have to settle down on ADAT + demux.
Building a device around an eval board would be a way to go if the price was in 300 EUR range. EUR 1500 is long over my budget considering that other things have to be purchased too and that you buy something that you don’t for sure know will work in the end.
Nevertheless I’ll check both the DICE and ZP Eng chips and boards.
Ethernet is CSMACD type of network. This means that before sending a packet a network device has to “listen to” the network for clear (without payload) carrier signal. Until it receives clear carrier it will wait because it means that some other device is sending. Then during the transmission it compares the signal it sends with the signal on the wire. If the 2 don’t agree then we have a collision and the device performs a recovery procedure which causes all devices to stand back for a while and then start sending again with a random delay statistically computed in such a way that only 50% of devices will start sending (provided they have something to send) within the time interval required for one whole packet to traverse the whole net. If we get another collision at this moment then the recovery procedure is repeated with random statistical delay resulting in only 25% of all devices starting to send etc. until there are no collisions. Because of this, the latency and delivery time cannot be guaranteed. If CobraNet cards are to work on plain Ethernet together with other devices (which the FAQ says) then they must obey these rules too. Then it doesn’t help that a special CobraNet card is very fast, with precise timing etc. Delays, latency and therefore jitter is caused by cooperation among devices, not by an individual device and must be taken care of by using other means (buffering and good protocol at higher levels?). I would guess. Those who know better please do correct me; otherwise I still don’t see why you couldn’t use plain Ethernet card to do the job, at least from technical point of view.
Concerning ADAT, it won’t do for me. I need either 3 2-channel or 6 1-channel S/PDIF or AES/EBU streams. I was considering getting one of those FW/USB external boxes providing ADAT (LightPipe) (there are some very nice boxes out there) but then I would need to demultiplex ADAT to 3 or 6 S/PDIF channels and the only devices capable of doing this that I found and still in production/market are very expensive. Perhaps I could build my own demultiplexer out of of-the-shelf ADAT demux IC, a Toslink component and 3 S/PDIF IC’s plus transformers. But it feels more right to use another method of which CobraNet would be one. I would prefer a solution giving me support up to 192 kHz sampling frequency which neither ADAT nor CobraNet give. Why? 24 Mbits/sec is not that much – my notebook pumps out about 60 Mbits/s over Ethernet. Well, perhaps I would have to settle down on ADAT + demux.
Building a device around an eval board would be a way to go if the price was in 300 EUR range. EUR 1500 is long over my budget considering that other things have to be purchased too and that you buy something that you don’t for sure know will work in the end.
Nevertheless I’ll check both the DICE and ZP Eng chips and boards.
A few points.
Ethernet is not really CSMACD anyomore. It was some years ago. In modern switched networks, as opposed to older repeater hub based networks, collisions were possible and the older 10BT flavor of Ethernet used CSMACD to recover. Not really applicable today. CobraNet requires use of at least a 100BT full duplex switched network. Ttat means WiFi and PowerLine as an Etherent transport are out. A minimum of 100BT full duplex switched is what all of the equipment is today anyway, no big deal. Collisions are not an issue in this century. The only possible caveat would be data being dropped or delayed in a switch if the network bandwidth is oversubscribed. But you will not have the timing issues arising due to backoffs and retransmissions that used to happen as a result of collisions in a CSMACD net. This is a NON-ISSUE in a properly provisioned and configured modern network.
The lower level driver you are talking about (in Windows land) is the NDIS layer. It is here that you would have to implement a CobraNet driver. BTW, CobraNet is a registered Ethernet protocol, 0x8819. However, the details of the protocol are not public. The easiest solution would be to use a chip. Then it would all work as expected.
Steve
Ethernet is not really CSMACD anyomore. It was some years ago. In modern switched networks, as opposed to older repeater hub based networks, collisions were possible and the older 10BT flavor of Ethernet used CSMACD to recover. Not really applicable today. CobraNet requires use of at least a 100BT full duplex switched network. Ttat means WiFi and PowerLine as an Etherent transport are out. A minimum of 100BT full duplex switched is what all of the equipment is today anyway, no big deal. Collisions are not an issue in this century. The only possible caveat would be data being dropped or delayed in a switch if the network bandwidth is oversubscribed. But you will not have the timing issues arising due to backoffs and retransmissions that used to happen as a result of collisions in a CSMACD net. This is a NON-ISSUE in a properly provisioned and configured modern network.
The lower level driver you are talking about (in Windows land) is the NDIS layer. It is here that you would have to implement a CobraNet driver. BTW, CobraNet is a registered Ethernet protocol, 0x8819. However, the details of the protocol are not public. The easiest solution would be to use a chip. Then it would all work as expected.
Steve
Streaming audio over standard-Ethernet with a small latency is really complex, that won't work in software. It has its reasons why Cirrus has used FPGA and now offers dedicated chips for this purpose.
Cobranet is also a compromise, its latency of a minimum of 1.3ms is the price you have to pay for being able to use standard-Ethernet. That will work for most purposes, but in live-sound applications every millisecond counts and one would prefer a solution with lower latency. There are other solutions which give up Ethernet compatibility partly or completely use their own protocol over Cat 5, resulting in much better performance specs and lower hardware requirements.
It's always an appreciation of values for a specific application.
Cobranet is also a compromise, its latency of a minimum of 1.3ms is the price you have to pay for being able to use standard-Ethernet. That will work for most purposes, but in live-sound applications every millisecond counts and one would prefer a solution with lower latency. There are other solutions which give up Ethernet compatibility partly or completely use their own protocol over Cat 5, resulting in much better performance specs and lower hardware requirements.
It's always an appreciation of values for a specific application.
I had tried to make my ethernet device work over Wifi... but ping time is random from 10 ms to 1 second depending on conditions, so it was unusable.
I hear CobraNet is used in stadiums and very large PAs. For that you don't care about sub-ms latency, just that :
- it works (ie redundancy, ring topology, etc)
- it works (versus running analog audio into kms of cables)
I hear CobraNet is used in stadiums and very large PAs. For that you don't care about sub-ms latency, just that :
- it works (ie redundancy, ring topology, etc)
- it works (versus running analog audio into kms of cables)
I have to trust you Audiosteve, I didn’t study 100BT switched network well enough to argue on collisions. Maybe I should read details because it is interesting how collision avoidance (CA) is implemented as opposed to collision detect (CD). Especially in large networks with many switches upstream and many branches downstream and doing it before all devices learned all MAC address/port pairs. Anyhow, a device has to wait until the network is free. And that means that the devices compete for bandwidth and latency – the one that talks fastest gets most of it (not that unlike real life). Therefore latency and delivery time cannot be predicted because it does not depend on a single NIC implementation – it is a randomly varying result of competition. I would say that this is much bigger factor than the “precious” special CobraNet NIC implementation, unless you are on dedicated CobraNet net.
It should be quite easy to implement CobraNet over standard NIC would the protocol be generally available. Just give the spec to Linux networking group and you’ll see. And this is the reason why it isn’t. And this is also the reason why to stay away from it. Networks are about interoperability which requires openness. A vendor marketing a technology that allows them to sell more own chips is perfectly in order. But a technical motivation for that chip that simply doesn’t stand technical inspection is not, whatever vendor’s name is.
Nevertheless I like the idea of transmitting audio using ordered protocol with handshaking. This allows treating audio as data and forgetting about precise timing of that data by sending sampling frequency as a separate data piece thereby allowing the DAC to use its own clock. This is what is being done inside a computer when reading and playing audio from hard drive. Why not to do it between devices too?
Then again, if you have very stringent requirements when to start and when to stop then you need a different technology. I still remember a pair of scissors placed in the immediate vicinity of recording head and tape – that’s what I call doing it yourself
It should be quite easy to implement CobraNet over standard NIC would the protocol be generally available. Just give the spec to Linux networking group and you’ll see. And this is the reason why it isn’t. And this is also the reason why to stay away from it. Networks are about interoperability which requires openness. A vendor marketing a technology that allows them to sell more own chips is perfectly in order. But a technical motivation for that chip that simply doesn’t stand technical inspection is not, whatever vendor’s name is.
Nevertheless I like the idea of transmitting audio using ordered protocol with handshaking. This allows treating audio as data and forgetting about precise timing of that data by sending sampling frequency as a separate data piece thereby allowing the DAC to use its own clock. This is what is being done inside a computer when reading and playing audio from hard drive. Why not to do it between devices too?
Then again, if you have very stringent requirements when to start and when to stop then you need a different technology. I still remember a pair of scissors placed in the immediate vicinity of recording head and tape – that’s what I call doing it yourself
The network (as in "cable") is always free since you use switches : each NIC sees a switch port through a full duplex cable. Since there are ony two NICs on the cable, there can be no collisions. (If hubs are used, things are different, but nobody uses those anymore).
What may happen is contention in the switch buffer.
Suppose you have a network with 4 computers (A,B,C,D) and 1 switch.
If A sends at 100 Mbps to B
and C sends at 100 Mbps to D,
everything should be fine if the switch can handle it.
Now if A and B both send at full speed to C, of course the switch won't be able to fit 200 Mbps in a single wire and there will be dropped packets.
In a dedicated audio network, the traffic is pretty deterministic so you can be sure it will work. If you mix in file servers...
Anyway given the price of CAT-6 cables I guess you can use dedicated cables !
What may happen is contention in the switch buffer.
Suppose you have a network with 4 computers (A,B,C,D) and 1 switch.
If A sends at 100 Mbps to B
and C sends at 100 Mbps to D,
everything should be fine if the switch can handle it.
Now if A and B both send at full speed to C, of course the switch won't be able to fit 200 Mbps in a single wire and there will be dropped packets.
In a dedicated audio network, the traffic is pretty deterministic so you can be sure it will work. If you mix in file servers...
Anyway given the price of CAT-6 cables I guess you can use dedicated cables !
@peufeu
“If A sends at 100 Mbps to B
and C sends at 100 Mbps to D,
everything should be fine if the switch can handle it.”
Unless B and D are on another downstream branch than A and C because then you have single shared 100MBps between both downstream switches and upstream switch and the traffic has to go all the way up and down. So while A talks to B, C and D has to wait. Switches or not is still shared media.
“In a dedicated audio network, the traffic is pretty deterministic so you can be sure it will work. If you mix in file servers...”
…or video servers/sources to take more relevant example. This is exactly what I mean – CobraNet claims that it can be used on a non-dedicated network which obviously will not work all right as soon as you have any other serious traffic on it. Then it has to be seen as dedicated net.
“Anyway given the price of CAT-6 cables I guess you can use dedicated cables !”
Well, that depends on network size. First there are the cables which do cost money if you have a lot of them, then we have switches that cost some real money if you need many of good quality, then in larger installations we have coupling boxes (or whatever the name is in English), then space in tunnels in walls, and don’t forget about labor cost during installation. All those costs are not negligible at large sport/entertaining arena installations. Wasn’t this size the primary target for CobraNet?
@hwb
Any Ethernet protocol can (has to) be implemented in software, whether that software runs on a special or general processor. And because I don’t believe that the timing done in NIC is the problem (because Ethernet doesn’t stipulate such exact overall timing) any protocol that claims to be standard Ethernet protocol that will function all right when run on standard Ethernet with many different devices on it, will be possible to implement over any good quality NIC. And this is most probable reason why the protocol isn’t disclosed. It’s probably very simple and easy to implement once to have the spec. There is nothing wrong with keeping certain technology for yourself and do not allow others (equipment) to cooperate with you – this is a business decision which may be right or wrong (compare closeness of Mac and openness of PC and the resulting market shares). But marketing such a technology using arguments that, IMHO, don’t stand critical analysis is not. They simply have to find better arguments. There is nothing wrong with selling loudspeaker cables for EUR2000/m as long as the marketing arguments hold, which they don’t do. Again, find better arguments then I’m with you.
“If A sends at 100 Mbps to B
and C sends at 100 Mbps to D,
everything should be fine if the switch can handle it.”
Unless B and D are on another downstream branch than A and C because then you have single shared 100MBps between both downstream switches and upstream switch and the traffic has to go all the way up and down. So while A talks to B, C and D has to wait. Switches or not is still shared media.
“In a dedicated audio network, the traffic is pretty deterministic so you can be sure it will work. If you mix in file servers...”
…or video servers/sources to take more relevant example. This is exactly what I mean – CobraNet claims that it can be used on a non-dedicated network which obviously will not work all right as soon as you have any other serious traffic on it. Then it has to be seen as dedicated net.
“Anyway given the price of CAT-6 cables I guess you can use dedicated cables !”
Well, that depends on network size. First there are the cables which do cost money if you have a lot of them, then we have switches that cost some real money if you need many of good quality, then in larger installations we have coupling boxes (or whatever the name is in English), then space in tunnels in walls, and don’t forget about labor cost during installation. All those costs are not negligible at large sport/entertaining arena installations. Wasn’t this size the primary target for CobraNet?
@hwb
Any Ethernet protocol can (has to) be implemented in software, whether that software runs on a special or general processor. And because I don’t believe that the timing done in NIC is the problem (because Ethernet doesn’t stipulate such exact overall timing) any protocol that claims to be standard Ethernet protocol that will function all right when run on standard Ethernet with many different devices on it, will be possible to implement over any good quality NIC. And this is most probable reason why the protocol isn’t disclosed. It’s probably very simple and easy to implement once to have the spec. There is nothing wrong with keeping certain technology for yourself and do not allow others (equipment) to cooperate with you – this is a business decision which may be right or wrong (compare closeness of Mac and openness of PC and the resulting market shares). But marketing such a technology using arguments that, IMHO, don’t stand critical analysis is not. They simply have to find better arguments. There is nothing wrong with selling loudspeaker cables for EUR2000/m as long as the marketing arguments hold, which they don’t do. Again, find better arguments then I’m with you.
You give the answer yourself: "Ethernet doesn’t stipulate such exact overall timing..." Exactly this is the point. For streaming audio with very low latencies and therefore minimal buffering you are dependent on exact timing. There is a VCXO in every Cobranet device which is synchronised with special packets from a master to control the timing of audio transmission. This won't work with a standard NIC. You might be able to sniff audio packets on the network and record them to disc, but not more.
All other traffic is unregulated, so Cobranet can coexist with non-audio traffic on the network up to a certain degree, but audio needs synchronisation and therefore special hardware.
All other traffic is unregulated, so Cobranet can coexist with non-audio traffic on the network up to a certain degree, but audio needs synchronisation and therefore special hardware.
That exact timing is not supported by standard Ethernet. However exact your VCXO is, will that timing be spoiled by waiting for the wire to become free on a mixed net. Therefore you need dedicated net. Any special packets are subject to the same delays as all other packets – as far as Ethernet concerns there are no special packets. A switch or other device may even buffer, queue or rewrite packets. Therefore CobraNet requires very special Ethernet installation. It is in fact an Ethernet with additional CorbaNet requirements. Therefore it is not standard Ethernet. It is CobraNet.
Either the synchronization works on a usual trafficked net in which case timing available on standard NIC is enough or you require special timings in which case you need special net, special devices (or a selection of devices among all available) and therefore special NICs. Either Or but not Both. Either you are plain vehicle driver in which case you are obliged to stop for red light, in which case a siren doesn’t help, or you are emergency vehicle driver in which case you are obliged to use siren and you may pass through unless the way is blocked by hundreds of other cars. You cannot be both at the same time. Now, standard Ethernet does not care for your siren therefore you may make as much alarm as you want but you will not arrive faster. You have to wait for green and for free way, how ever much power and acceleration you can get from your engine. Only if you are alone on the lane can all that power buy you time.
Either the synchronization works on a usual trafficked net in which case timing available on standard NIC is enough or you require special timings in which case you need special net, special devices (or a selection of devices among all available) and therefore special NICs. Either Or but not Both. Either you are plain vehicle driver in which case you are obliged to stop for red light, in which case a siren doesn’t help, or you are emergency vehicle driver in which case you are obliged to use siren and you may pass through unless the way is blocked by hundreds of other cars. You cannot be both at the same time. Now, standard Ethernet does not care for your siren therefore you may make as much alarm as you want but you will not arrive faster. You have to wait for green and for free way, how ever much power and acceleration you can get from your engine. Only if you are alone on the lane can all that power buy you time.
Mhakman,
No, actually CobraNet is standard EtherNet with an IEEE registered protocol (EtherType) of 0x8819.
The Ethernet frames look exactly like any other Ethernet frame and are sent and received the exact same way as any other. There is no magic in the CobraNet interface with regard to anything non-standard as far as the network interface is concerned. The magic is in what it does with the Ethernet frames it receives and how it drives the VCXO used to re-construct the system wide audio clock. CobraNet will co-exist nicely on a data network as long as the bandwidth of the Ethernet links are not oversubscribed. There is a minimal amount of buffering in the protocol to allow acceptance of small delays and there is hysteresis and filtering in the VCXO adjustment algorithm that also allows the audio clock to remain locked in the face of any hiccups in packet forwarding delay on the net.
Being that CobraNet is standard EthereNet, HWB was very correct on sayiong that you could probably use a standard PC interface to receive CobraNet audio. Just add a little additional buffering to smooth out the non-deterministic timing introduced by the OS. But the transmission of CobraNet frames must be very deterministic and would make implementation of this function on a standard PC very difficult in the absence of a dedicated interface driven by its own processor. A CobraNet Adapter card would most likely be required for transmission from a PC to insure proper operation under all conditions. So which one of you smart guys out there wants to make such a card? I'll provide guidance and support but I don't have the time to do it.
BTW, I'll be out of town for the next week on biz so if anyone wants to reply to me in this forum I won't see it after Saturrday morning.
No, actually CobraNet is standard EtherNet with an IEEE registered protocol (EtherType) of 0x8819.
The Ethernet frames look exactly like any other Ethernet frame and are sent and received the exact same way as any other. There is no magic in the CobraNet interface with regard to anything non-standard as far as the network interface is concerned. The magic is in what it does with the Ethernet frames it receives and how it drives the VCXO used to re-construct the system wide audio clock. CobraNet will co-exist nicely on a data network as long as the bandwidth of the Ethernet links are not oversubscribed. There is a minimal amount of buffering in the protocol to allow acceptance of small delays and there is hysteresis and filtering in the VCXO adjustment algorithm that also allows the audio clock to remain locked in the face of any hiccups in packet forwarding delay on the net.
Being that CobraNet is standard EthereNet, HWB was very correct on sayiong that you could probably use a standard PC interface to receive CobraNet audio. Just add a little additional buffering to smooth out the non-deterministic timing introduced by the OS. But the transmission of CobraNet frames must be very deterministic and would make implementation of this function on a standard PC very difficult in the absence of a dedicated interface driven by its own processor. A CobraNet Adapter card would most likely be required for transmission from a PC to insure proper operation under all conditions. So which one of you smart guys out there wants to make such a card? I'll provide guidance and support but I don't have the time to do it.
BTW, I'll be out of town for the next week on biz so if anyone wants to reply to me in this forum I won't see it after Saturrday morning.
Thats' right on both points.
A software only solution would be possible but very difficult, if not impossible, on the transmission side.
And you would have to use sample rate converter, whether software or hardware, to transcode 44.1 kHz audio. I know a lot of people get real heartburn over SRC's, probably due to their memory of the hardware SRC's first released. But modern hardware and software SRC's are pretty darn good and you'd be hard pressed to listen to one and tell the difference. Take a listen for yourself and see what you think. The CODEC in my PC transcodes everything to 48kHz whether I ask it to or not. I feed that via S/PDIF to a Grace m902 used as a DAC and it sounds awfully darn good.
A software only solution would be possible but very difficult, if not impossible, on the transmission side.
And you would have to use sample rate converter, whether software or hardware, to transcode 44.1 kHz audio. I know a lot of people get real heartburn over SRC's, probably due to their memory of the hardware SRC's first released. But modern hardware and software SRC's are pretty darn good and you'd be hard pressed to listen to one and tell the difference. Take a listen for yourself and see what you think. The CODEC in my PC transcodes everything to 48kHz whether I ask it to or not. I feed that via S/PDIF to a Grace m902 used as a DAC and it sounds awfully darn good.
audiosteve said:
If you could provide protocol spec then I could try to do it in software – it’s much cheaper and faster to develop software than hardware for me. If it works well enough using software only driver then building hardware could only get it better.
I cannot see what Ethernet has to do with 44.1 kHz sampling. Are you saying that CobraNet is expecting packets to arrive with certain frequency? Then it is not Ethernet. Ethernet is NOT real-time transport. It does NOT guarantee that if you send a packet each millisecond they will arrive at the destination each millisecond. This has nothing with bandwidth to do. It’s latency that is unspecified even if bandwidth is there.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.