Genelecs fed with AES digital - unwanted clicks in audio

[sleepy.sock]

I am super happy with my desktop Genelec 8331As + 7350. However, I have noticed something strange that I thought it would be worth sharing. I drive them purely with their AES digital input from an RME ADI-2 FS R (which has a nice AES digital output). So far, I have been feeding them data at whatever sample rate the audio file happened to come at (44.1/48/96/192/etc). They switch sample rates (little red flash of their leds) and it all seemed to work ok. Or rather, it seemed to work ok 99.9% of the time. I would hear occasional, but very real, audible clicks during playback. These clicks sound exactly clocking/sample errors.

The clicks were rare and did not seem to have a pattern I could discover. I could never reproduce them by e.g. replaying the same section of the file again. It was driving me nuts. Everything in the signal chain seemed ok and there should be ample headroom within the attenuated digital signal they received for any sample rate conversion without e.g. intersample overs.

Genelec say all their internal DSP and conversion works at 96kHz and 48kHz. My hypothesis was that there may be some subtle bug with clocking or converting other sample rates, or perhaps with tracking changes in sample rate of AES input.

I've now changed my signal chain so all audio that hits the Genelecs has been resampled to 96kHz -- they never see anything but 24/96 data now. So far (fingers crossed), the clicks have disappeared (and they still sound amazing, as always).

Does anyone else have a similar experience?

 

[PureLIN]

I have two 8341s which digital board are faulty: when connected GLM and feed them aes signal, 48k will have cracks rarely, 96k will increase times dramatically and 192k will make blink red light and audio continue drops, without GLM it works seems fine.
Local dealer even don't reproduce problem at first time.
Maybe you can have a try.

 

[sleepy.sock]

Thanks, I'm interested in any more reports of this.

I have not tried switching GLM off. It may be that the clicks are caused by the GLM correction process -- although I don't have a particularly severe correction filter.

I can report that since changing my setup -- now I only feed the Genelecs 96kHz data -- things have noticeably improved. Before, I was getting audible clicks roughly 1-2 times per hour. It was clearly noticeable and annoying.

I *think* I have resolved the issue, but I confess that I am not entirely sure. Occasionally, I hear what sounds like another click of the same kind. When I replay the track, it is absent, indicating that it was not on the recording. However, this event occurs sufficiently rarely (maybe once a day?) that it is (a) not too annoying; (b) I begin to doubt that I really did heard the click in the first place (maybe I imagined it...). Hence, I am interested in the experience of other users on this.

@PureLIN if you are getting flashing LED lights at 192kHz that indicates the speaker is not locking onto the signal successfully. You could try cycling the power to the speaker (switching it off and on again). This resolved flashing LEDs issues for me in the past. If that doesn't do it, there it would be worth checking all your AES cables (I had one dodgy one that produced flashing LEDs).

 

[PureLIN]

I think you don't understand what I means with "connected GLM", I means connect the 8341 to GLM adapter with net cable, but not if enable/bypass the calibration.
The flashing LED is indicate my 8341 are rebooting, the GLM software will show my speaker keep offline and online when that happens.
May be a broken controller chip, but I can't sure since the repair solution is total replace the digital board.

 

[sleepy.sock]

Ok, I think I understand. Hope the replacement fixes it. Still would be interested to hear if you get clicking noises on the replacement units.

 

[sleepy.sock]

I can confirm that I am still getting intermittent audible clicks, even with resampling to always feed 96kHz over AES to my Genelecs. Not frequent, but definitely there.

I am happy with the speakers (they sound magnificent), but there really shouldn't be any audible clicks occurring at all. It sounds like a digital processing or clocking issue, maybe some subtle bug.

Would be keen to know if anyone else has noticed this.

 

[RobL]

Have you contacted Genelec to ask about the issue? They are very responsive.

 

[sleepy.sock]

I haven't yet -- I wanted to check online to see how 'normal' it is in terms of expected behaviour. I'll check with them now.

 

[holdingpants01]

Are you sure the Genelecs are the problem? It could be the source, interface or cable. Is it clicking at the same time in both speakers? If yes that would suggest the problem occurs before it even get to the monitors. Same goes for PureLIN, which is much more possible the source/cable/clocking is the culprit rather than two faulty boards, especially if dealer can't reproduce the problem and it's occurring on both speakers at the same time.
I have more than 10 Genelec digital monitors in my studio and none of them is clicking at any sample rate I throw at them

 

[sleepy.sock]

Thanks for the suggestions, which I'll explore. Not sure if it's clicking at the same time on both speakers, but good idea to check. No clicks over the RME headphone output, so I was assuming it is likely not the source or interface.

 

[holdingpants01]

Thanks for the suggestions, which I'll explore. Not sure if it's clicking at the same time on both speakers, but good idea to check. No clicks over the RME headphone output, so I was assuming it is likely not the source or interface.

I would suggest changing the cables first, are you using dedicated AES/EBU XLR cable with proper 110 ohm impedance both between interface and two monitors?

 

[sleepy.sock]

yes, it is all mogami/neutrik cables dedicated for AES, 110 ohm connections.

 

[Zapper]

It sounds like a sync problem between the RME and the Genelecs. AES is like SPDIF (but unlike USB) in that there is no handshaking between transmitter and receiver. The transmitter sends data at its own clock rate and the receiver has to figure out what to do with it, because the receiver's clock will be slightly different. Either it can sync its clock to the incoming datastream using a PLL, or it can resample the data to its clock. If something goes wrong in this process you hear occasional clicks or dropouts.

Your RME manual has a good discussion of this issue. The problem may appear to be with the Genelecs, since they are the receivers of the AES signal. However, it could be that the RME is sending poorly formatted AES signals, the way some TVs (some say LGs in particular) send a S/PDIF that many DACs can't read properly, also resulting in clicks or dropouts.

 

[sleepy.sock]

Just had a chat with Genelec (excellent) and they have suggested it may be a buffer size issue, causing the RME to drop samples. That sounds plausible to me. I've increased the buffer size for the device in Roon to 100msec, and will report back if that cures the issue and the clicks disappear.

 

[Zapper]

That sounds plausible to me. I've increased the buffer size for the device in Roon to 100msec, and will report back if that cures the issue and the clicks disappear.

What is the signal path on the input to the RME?

If the input buffer size is the problem, wouldn't you hear it on the headphones too?

 

[sleepy.sock]

My signal path is: - Raspberry PI running Roon client, volume levelling, -3dB for headroom, resample to 96kHz --USB over ALSA--> RME ADI-2 Pro (digital volume attenuation, normally around -20dB) --AES--> 7350A --AES--> 8331A (right) ---AES--> 8331A (left) GLM calibration and bass management are on, -30dB of volume attenuation. I don't know why I didn't notice it with the headphones on -- it may have been absent, in which case the RME is innocent and fiddling with buffer size won't fix it (only time will tell if this is the case -- I'll report back if it fixes it). Or, it may be that the clicks/dropouts were there all along but the 8331As are just insanely good at highlighting them (they are when there is any clicks in the background on the source recording).

 

[cl516]

I use an Apogee Symphony I/O Mk2. One of its two modules is the 2X6SE which has a dedicated AES output on XLR. That feeds my 8361A's. There are no clicks here. GLM can be bypassed or not, doesn't matter. No clicks for me.

 

[Zapper]

Raspberry PI running Roon client, volume levelling, -3dB for headroom, resample to 96kHz --USB over ALSA--> RME ADI-2 Pro (digital volume attenuation, normally around -20dB) --AES--> 7350A --AES--> 8331A (right) ---AES--> 8331A (left)

For the sake of debugging you could try another digital source into the RME.

 

[HiMu]

I don't know why I didn't notice it with the headphones on

I presume your headphones aren't connected with AES/EBU and doesn't have clock/sync issues because of that, if the problem is between interface and the speakers.

 

[Zapper]

If the buffer tweak doesn't fix it, some basic trial and error troubleshooting is called for. Try a different digital source into RME (tests if interface from Pi to RME is problem). Try an analog source into RME (tests if the problem is digital input). Connect to speakers on analog XLR (tests if problem is in AES interface). If you have any other devices with AES outputs you could it instead of RME.