Yes, lost sync was the ADAT light flickering and at the same time there was a short interruption of audio in the recording.
- The Octamic (sorry for calling it Octapre) was master set to 48 kHz using the dip switches.
- From the ADAT output of Octamic I connmected a short and new optical cable to the ADAT in port of the UCX.
- The UCX was set to 48 kHz and also set to sync on the incoming ADAT.

Since it's time consuming I have not had time to try to reproduce this error. However as I wrote; I had sucessfullt recorded more than one hour of music (and also listen to yet another hour of reharsal) without any issues. Then I hade these two interruptions about 15 minutes apart. Then the concert was over.

I see no configuration error and there was absolutely nothing special going on at the moment of the interruptions. I was sitting still by the desk with my headphones on. No one was even near the interfaces or cables. We were in a remote room so there were no vibrations or anything like that.

Matthias oortone said
"- The UCX was set to 48 kHz and also set to sync on the incoming ADAT."

meaning he set the sample rate manually on 48 kHz and chose as clock source the ADAT.

Which leads me to a puzzling question: why has RME choosen not to automatically set the UCX clock sample rate to the sample rate offered on the chosen clock source?

I try to find the logic behind this choice, but fear I must be overlooking some argument because I can't think of any reason.

- The UCX knows the sample rate on the chosen digital input,
- the UCX is capable of automatically changing the internal word clock, as it does so with ASIO and is supposed to do so with KS over USB,
- the UCX requires the sample rates on all digital input and its internal word clock to be of the same sample rate to be in sync.

So why doesn't the UCX set its internal sample rate automatically to the chosen clock source?

Could you enlighten me?

Cheers

Aleg

Also, you can set the unit to 96k (for example) when the master clock only sends single speed word clock (48k), even when working at double speed. Plus, some devices don't flag the double speed and quad speed audio correctly, so you need an override, so to speak.

Please check the resulting wave file - do you actually see an interruption in the sense of discontinuity or a distinct "step" in the waveform? Or is there a click in an otherwise continuous wave form?

The former would point to an actual interruption of the ADAT transfer for a moment. The latter would point to sync issues.

Have you ever tried reproducing this, preferrably also with another cable?

Regards
Daniel Fuchs
RME

Hello again.

Now I set up my system in an identical manner and I got the same sync problems. Only difference I lost sync more often than the original incident.

Looking at the waveform there is no complete interruption, the waveform just looks a bit different when the sync failure occurs. There is no obvious discontinuity and it sounds a bit like a rather silent click (far from fullscale) followed by maybe 250 ms of “bitcrushed” sound on all channels from that interface.

Just to make clear how I set things up:
Octamic (original version): Internal Clock, 48 kHz
UCX: Clock source Optical, 48 kHz
Connection with toslink cable from Octamic-Main to Adat-input on UCX.

I tried two different Octamic with same result.
I also tried Wordclock out from UCX to Wordclock in on Octamic (obviously changing sync to internal on UCX, and sync to external/wc on Octamic), same result.

I tried changing the toslink cable to another one, which was 3 m instead of 0,5 m. Now the result was even worse. So I’m beginning to suspect bad cables. Both are
Deltaco Toslink to toslink (TOTO-3) Audio.

I’ll try with other cables but that might take some time since there are none available at this production site at the moment.

Meanwhile I have two questions:
1.    I’m under the impression that all toslink cables should have the same spec but maybe I’m wrong. Are there toslink cables specially suited for adat-signals?
2.    Is it possible that wrong settings in the DAW (Protools 10) could cause these sync problems? What should I look for in that case? I use the Fireface directly, no aggregate.

I would be interested to hear if the same happens when you change the setup to 44.1 kHz. One can not rule out that the TOSLINK input of the UCX is at fault. Lowering the optical data rate by changing to 44.1 kHz with no faults then would point to such a cause.

Just to bring in my own experience with an UCX and optical cables:
I did some recordings of jazz concerts with an 01V96 as source. First let me say that this kind of recording setup is a dream. Put in one cable and you have 8 channnels. Only real danger is the sound engineer not working with mic gain correctly and a wrong setup in the mixer (postfader...).
Altough it worked, on some recordings I had strange events. One Track lost signal 2 times within 10 minutes for under a second. Another night there were a heavy burst for around a second on all channels but only once. Fortunately for me both events were relatively easy editable.

Regarding the quality of cables... Those cheap ones aren't really for road usage of course - having a spare one is a must. But you can get very sturdy ones if you are willing to pay. When you calculate 8 channels of analog symmetric cables the price isn't that high in the end.

With best regards
El Duderino

Here's a short excerpt from the recording. The error is in the middle. It's two mono files (L/R) from the main omnis on the recording. The error sounds more or less identical on all channels.
http://sigvardson.se/public/rme-error.zip

Now I've examined the setup further and these are my findings.
- Other cables
If I changed to a no-name toslink I found at home (looks kind of cheap, about 3 meters long) things improved considerably. No error during the time I was testing.

- Changing to 44,1
Seems to make the error less common than using the "bad cable".

- Sending the Octamic adat signal to another interface.
I connected the Octamic using the "bad cable" to a Babyface and there were no errors during my test.

- Another Octamic
I also tried another Octamic (both are the original version) but using the "bad cable" the error were about as common as with the original Octamic.

So I'm not sure what to make of this. Obviously the cable makes a difference but connected to the Babyface there was no problem. I guess the most probable cause is that the ADAT-port of UCX is not healthy. On the other hand El Duderinos problems sound a lot like mine which makes me wonder if this problem is not just on my device. Maybe a whole batch.

When I say that things were ok with babyface or another cable keep in mind that it's very tedious and time consuming to sit and stare on a led or try to find a glitch in a recorded sinewave so I really can't say that either of these things eleminated the problem completely. I did not test for three hours, more like 20 minutes. But obvioulsy they make a difference. Problem is I could get the same error after two-three hours of recording. There's no way to know. I really don't know how to make sure this happens again. How can I ever trust ADAT in this setup again?

I wonder if there's a way to assess if the ADAT-port is ok or not?

Just for the record. I had the settings confirmed by a colleague and I've been using ADAT in various ways since the 90:ies (Fostex VC8, Motu 8 pre, Marian ADCON, Yamaha 0196/Hammerfall, Alesis AI3) and I'm quite sure I've set up things right. Neverhad a problem like this before.