1
\$\begingroup\$

This is a question about digital audio cables. I know this isn't an audio engineering forum but the question's specific to the physical connections and there's limited info online which I can find about this problem, so I felt this was the best place.

I'm working in a radio studio and we have a CD player which has been installed, connected to our patch panel in our server room, which connects to our mixing console, which is a Mandozzi CIMIX 12F. The cable is a Belden 70053 multicore, using the AES digital connection on the CD player. The cable has a nominal impedance of 110 Ohms and nominal capacitance of 40 pF/m. I'm unsure of the exact length of the installed cable but I estimate that it's about 15 m.

Our problem is the audio from the CD player is very bitty and harsh-sounding. From my knowledge, this is a sign that the digital signal is noisy. I only noticed it recently so I thought at first it was a fault with the player. I checked the player is on the latest firmware. I opened up the player to re-seat all of the connectors (this has fixed audio issues I've had with laptops before). This didn't fix it. I tried the CD player in our other studio which also has AES connections to the server room, over a shorter distance. The audio was clean. So I can confirm the issue is not with the player, so I investigated the connections. I tried the signal on the other multicore in our studio, which is a Sommer SC-Pegasus CMCK cable, which has two layers of braided shielding instead of the Belden which has just one foil layer. The signal on this cable was also bitty. So at this point I figured that the issue is due to distance or interference.

I took a multimeter, set it to volts AC, and measured the voltage between pins 1 and 2 on the AES connector on the back of the CD player. Then, I measured pins 1 & 2 on the XLR connector of the Belden cable at the server room end. Then, I made a new cable using Sommer SC-CICADA 4 cable, running from the CD player to the server room along the floor, to see if this had the same problem. The SC-CICADA cable has a nominal impedance of 145 Ohms and capacitance of 75 pF/m; I've tested it before and this cable does work well for AES - I've used it for patching. The audio from this custom-made cable also sounds bitty. I measured the voltage coming from the server room end of this cable as well.

I measured the voltage when a CD is playing and when a CD is not playing. Here are my results:

When CD is not playing:

  • Output from AES connector on CD player: 0.031 V
  • Output from XLR connector on installed cable in server room: 0.035 V
  • Output from XLR connector on custom-made cable in server room: 0.009 V

When CD is playing:

  • Output from AES connector on CD player: 0.1 V
  • Output from XLR connector on installed cable in server room: 0.038 V
  • Output from XLR connector on custom-made cable in server room: 0.01 V

I know that because digital audio has only two levels, it can provide a semi-reliable constant RMS voltage when the sample words are being transmitted. When there is no audio playing, there still data being transmitted such as auxiliary bits, channel mode, user bits, etc. So there will be some signal spikes but it will add up to a lower RMS, though do correct me if I'm wrong. Ideally I should use an oscilloscope to test the signal but I don't have one.

From the results, we can see there is some signal attenuation from the CD player to the server room. I expected the custom-made cable to have a lower voltage at the other end as the SC-CICADA cable has a higher impedance.

One method which could improve the signal is to use a distribution amplifier part-way along the cable to improve the signal strength. We have a Sonifex RB-DA6 AES amplifier which we could use to test this, and determine if the issue is definitely caused by the distance. However, I am unsure at which distance along the cable it needs to be inserted in order to boost the signal.

I have a couple of questions. Firstly, does anybody know the ideal operating voltage which AES audio should be running at in order to transmit a clean signal along a cable? I have looked through the AES/EBU specifications and I cannot find an answer which is useful. With the right information, I can use the capacitance information to insert the distribution amplifier at the correct distance along the cable in order to test it.

Secondly, is there a suitable converter available which can be used to convert the impedance of the signal so that the audio can be transmitted over a longer distance with less loss? Would using a certain type of DI box solve the issue? I know that Blackmagic make a MiniConverter Audio to SDI box which takes AES audio in and transmits using SDI over BNC cables. I've used Blackmagic SDI boxes to transmit HDMI video over long distances. Would using these boxes fix the audio?

Alternatively, we could buy a Dante AVIO adapter to convert the AES signal to be used on our Dante audio network. This would be a cheaper fix but would take up our spare network ports, which I occasionally need to use for diagnostics or backup.

Thirdly, are there any other checks which I'm not doing, which would help to determine what the cause of the issue is?

Thank you.

\$\endgroup\$
3
  • 4
    \$\begingroup\$ Far too many words and not enough diagrams that show the connections and the cable types and the equipment. Don't use words when a picture is far better. Also don't expect folk to understand all the equipment name dropping. I mean if the name of the equipment is relevant then explain why it's relevant to the problem at hand. Problems with consumer or bought goods are beyond the remit of this site so try and stick to the simplest scenario and ask for help in fault diagnosis is my opinion. \$\endgroup\$
    – Andy aka
    Nov 26 '20 at 12:50
  • 1
    \$\begingroup\$ TL; DR but you can't use multimeter to measure anything about SPDIF/AESEBU audio, as it is too slow. The audio is also biphase mark encoded to remove DC. Did it occur to you that the CD player might output incorrect Channel Status info so the next device can try to assume the audio is something else that it really is? \$\endgroup\$
    – Justme
    Nov 26 '20 at 17:20
  • \$\begingroup\$ Try measuring your AC volts between pins 2 and 3 of the XLR. These should be square waves of several volts out of phase with each other so you should read several volts on your meter. Measuring to pin 1 (ground) may not work because the pin 2/3 signals are likely transformer-coupled so are not referenced to that ground. The ground is really just for shielding. And of course you've already done this, but triple check that your sample rates are truly locked. \$\endgroup\$
    – td127
    Nov 26 '20 at 20:32
2
\$\begingroup\$

Your multimeter measurements won't tell you anything : getting a good eye diagram on an oscilloscope will tell you a lot more.

Signal levels came straight from RS-422 so you can look that up to see what to expect at the driver end (via a 1:1 transformer).

Signal levels at the receive end depend on length and cable type but an unscreened twisted pair should be good for at least 300m or most of the way round the Albert Hall (I've seen this done, as part of the BBC Designs Dept team that demonstrated it to the AES, in 1982 or 1983).

Screened twisted pair won't get that far thanks to its higher capacitance but should be good for at least 100m. Avoid star-quad cable : in the process of suppressing interfering noise, its high capacitance is also extremely good at suppressing AES signals.

To get that performance you need the recommended transformer and equalisation at the receiver, and a voltage controlled crystal oscillator to regenerate a usefully low-jitter clock for a decent sounding DAC. There are papers on the importance of low jitter including a classic by Julian Dunn (here's another of his with better graphics) who joined that team a little later. There is a world of difference between a typical SPDIF receiver and a decent AES receiver and you need to be sure the transmitter didn't take shortcuts either.

Electrical specifications summarized here (page 147 on).

As @bobflux notes in a comment, this mixing desk appears to have sample rate conversion on its digital inputs, adding an un-necessary signal conversion stage (versus locking the CD player to a studio master clock).

Now this SHOULD tolerate signal degradation due to degraded eye diagram (inter-signal interference as seen in Julian's papers) but if poorly implemented, could translate phase errors (recovered clock jitter) into voltage errors (well, code errors) due to the ASRC process itself. (At which point you're looking for papers by Bob Adams ... such as "Clock Jitter, D/A Converters, and Sample-Rate Conversion By Robert W. Adams, Published in The Audio Critic, Issue No. 21" if you can find it.)

EDIT following comments:

I can't recommend a suitable transformer today, but I can report success with 7 + 7 turns (oops, memory failing, see below) on a FX2634 ferrite core, which was about 0.5 inch square and 0.25 thick, with two holes through it. Same transformer core was used at each end, but the TX was wound 6T+6T driven from a fairly large (0.1uF?) capacitor, and the RX was 4T:8T with the equaliser below, into the 9637 line receiver. For your short line, the equaliser is probably unnecessary!

Please excuse the quality of the 35 year old schematic print...

enter image description here

\$\endgroup\$
13
  • \$\begingroup\$ I'm not sure jitter would matter for sound quality since it's a digital mixing console, I'd assume it would do asynchronous sample rate conversion but... that would need confirmation. \$\endgroup\$
    – bobflux
    Nov 26 '20 at 18:03
  • \$\begingroup\$ There was only one ASRC in existence when I was doing that stuff ... Roger Lagadec's one for Studer. \$\endgroup\$ Nov 26 '20 at 18:06
  • \$\begingroup\$ @bobflux You may be on to something with your mention of ASRC ... when I was doing this, it was expected that pro gear would accept a master clock input, to lock the whole studio, no SRC required. But this mixer does seem to have SRC on its AES inputs. Now how SRC accommodates incoming jitter is a matter of implementation, and it's certainly possible to get it wrong. \$\endgroup\$ Nov 26 '20 at 18:39
  • \$\begingroup\$ I had a look at the console datasheet, it does say "8 AES inputs with SRC", also the device can be clocked from a variety of master clock sources... but the number of digital audio IOs hints that they crammed everything in a FPGA, so who knows if they used hardware SPDIF/SRC chips or soft SPDIF RX fpga cores, how these react to bit errors due to bad signal integrity and if it's SRC soft core how it will react to jitter?... \$\endgroup\$
    – bobflux
    Nov 26 '20 at 21:06
  • 1
    \$\begingroup\$ @bobflux exactly. If they used Bob Adams SRCs with a 3Hz jitter filter (AD189x) I'd say, no problem. If they crammed them into FPGA there may be cut corners somewhere, that only show up with long cables. My SRC took 6 cards of TTL, and it wasn't even an ASRC! (48kHz to 32kHz) \$\endgroup\$ Nov 26 '20 at 22:10
0
\$\begingroup\$

IF the transmitter has been up_powered, and that is co-sited with the control_room, then RFI at an increased level may be causing the "bit errors".

To evaluate this, you can install ferrite clamps, such as you see on the cables to VGA displays or other displays.

Any contrivance that dissipates energy along the outside of the cable, and thus changes the voltages across the cable_sheild_to_cable_interior_wires, may help your diagnosis.

At high frequencies, just firmly closing your fist around the cable sould cause a change.

\$\endgroup\$
0
\$\begingroup\$

Using an oscilloscope to look at the signal would definitely help to know if the problem is attenuation or reflections.

If the problem is attenuation along the cable: you could look at the SPDIF output inside the CD player. It is usually implemented as a logic gate driving a resistive attenuator which also matches the output impedance to the cable. You could modify the resistor values to keep the impedance matching but output a higher voltage.

However if the problem is due to impedance mismatches causing reflections along the cable, especially if the cable path is made of several different cables, patch panels etc then more signal amplitude probably won't help. You'd need to check for impedance discontinuities.

It could also be noise induced by crosstalk from other signals, but it is difficult to know without looking at the signal.

\$\endgroup\$
2
  • \$\begingroup\$ If he's using an SPDIF output that's a problem... this is AES/EBU. Same protocol, different physical media, levels, impedance, isolation. \$\endgroup\$ Nov 26 '20 at 17:51
  • \$\begingroup\$ He said "using the AES digital connection on the CD player" so... OP should confirm that the CDP really has an AES output and not a SPDIF RCA kludged into AES. \$\endgroup\$
    – bobflux
    Nov 26 '20 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.