RME FF400 vs. Weiss INT 202 FireWire

[PeterSt]

LOL !

Still I was using them some 20 years ago already ... for my synthesizers, drum machines and other MIDI stuff ...

Btw Pedal, wasn't that 26dB ?

[pedal]

Btw Pedal, wasn't that 26dB ?

Yes and the standing waves in the bass disappeared too!

I didn’t take those statements literally, although I did hear too what you meant. I had a similar “weird” experience changing from MosFet to Bipolare power amplifier. -My old arc enemy, a very troublesome nodal resonance in the bass, just “disappeared” because of better damping factor. The 2 amps measured the same, but behaved differently on music. -Because such measurements are done with static noise, not dynamic music.  It could probably not be measured in a traditionally in-room response, but it sure sounded like a “several-dB-improvement”.

Anyway, back to topic: What you said about word clock is of course very, very interesting.

We audiophiles are characterized by being both flock animals and creatures of habit. We walk the upgrade path as zombies. Adding a filter improves the mains, adding a PSU improves the amps, separates improves on integrates, biwire is better than singlewire, etc, etc. So, naturally, adding separate word clock improves your DAC! There are word clock BNC in/out connectors on the back of my RME FF400. When I lower my ear very close to the chassis I can hear their seductive siren song “Try me, try me”. It’s only a matter of time before I give in...

Honestly I don’t understand all this tick-tock-tech-talk. But can it be compared to a symphonic orchestra? -A word clock ensures that the orchestra starts playing exactly on time on 20.00.00, not 20.00.05. However the word clock doesn’t improve synchronization of the musicians. Whether they play out of tune or not, depends on the local clock.

To the audience, 5 seconds concert delay is a bagatelle. But musicians playing out of tune (not synchronized) are very audible of course.

Correct me if I am wrong. ["Everything should be explained as simple as possible, but not simpler."]

[PeterSt]

Honestly I don’t understand all this tick-tock-tech-talk. But can it be compared to a symphonic orchestra? -A word clock ensures that the orchestra starts playing exactly on time on 20.00.00, not 20.00.05. However the word clock doesn’t improve synchronization of the musicians. Whether they play out of tune or not, depends on the local clock.

Very well said, I think. However

However the word clock doesn’t improve synchronization of the musicians.

This is a tad contradictionary, because this *is* what it is about. But I'm sure the intention is right.

Before the orchestra there's the conductor. He is the word clock. The violins will start striking on his command. All the players are slaved to the master.
The violinists have sticks of restricted length. When the're at the end, they have to change the direction of striking. This too is dictated by the conductor hence word clock. However, when the violinist strikes too fast he will be at the end of the stick too soon, and silence will occur (waiting for the next command to change direction of striking). This is why the violinist was adapted a bit clock. The bit clock is the musical notes on his paper, and each musical note implies a time length. Now it works better, because if each musician works with the same time intervals, they should reach the end of the stick at the same time.
While going through the length of the stick, nothing much is the matter, and when the one violinist plays some faster as the other this is not much audible. However, the micro vibrations of the horse hair will have a faster frequency when striking faster. This is jitter. This is audible amongst two or more violinists, but it also will be audible when the one violinist is not striking with the same speed throughout this one stroke length. Actually this is flutter.
The better each musician is aware of the absolute time intervals and the better each musician is capable if sustaining the speed without flutter, the better it will sound.
Still the violinists need an indication on when to change the direction if they don't do *this* at the exact same time, it will be very very audible. And this is, again, what the conductor hence wordclock is doing.

If the wordclock would take 3 seconds per stroke in this example, one could try to derive the minimum audible flutter variation from that, by resestting the timer at the moment the stroke changes direction. But supposed this needs "servo speed control" each 1ms because otherwise flutter will be audible, it is obvious that it doesn't make much sense to derive a higher granularity from something with a lower. Te other way around though works perfectly, because after 3000 1ms intervals, 3 seconds WILL have been passed, and the stroke direction has to change.


Btw, although the story may be "readable", in digital practice there's no real analogy with the flutter throughout the stroke of the stick, because that complete stroke should comply with one sample. This means that the time which passes to fulfill the complete stroke is only about shifting in the bits, and this is not subject to jitter or anything. It is only about the moment the whole sample is put out. There's also no analogy with all the violinists changing direction at the same time "or it will be very much audible" because in digital practice it is about 1 violinist only, and the super exact time it takes to fulfill each (half) stroke. If *that* is not equal, that's jitter.

Ok, this for sure made it more confusing.
Peter

[PeterSt]

Don't take my words too much for granted; The more I think about it, the more I can imagine that deriving the "clock" from SPDIF (or AES/EBU) data just is a complete different story.
That, therefore, SPDIF etc. shouldn't be used at all, is another story again ...


A bit back to the topic ...
In my attempts to get a FireWire interface going, I bought a Pro device with the BridgeCo chip in order to test what would happen at using it. So, I used it via FireWire and SPDIF-out to the DAC (which had an SPDIF-in at the time). So, here too (like with the RME and like what you do with the INT202 Pedal) I just used it as the "interface". The sound coming from that was totally crazy and way bright. I would say that it was normal SPDIF (compared to i2s) but exponentially. Thus ? way way more jitter ? I don't know. I still have the device though and could measure it, but only through the analogue outs of the device itself (which will be apples and oranges). What I do know though, is that at grabbing the i2s from it and looking at a test signal, it looked totally strange to me ...
Next I took another Firewire interface with the same BridgeCo chip (I have a museum here !) and it looked exactly the same.

Now, at attempting to write drivers for it, or let them write by the manufacturer - and where at first the manufacturer had said they could do that for me, I required a sub 32 sample latency and they said it couldn't be done. It couldn't be done "because there's too much processing in the BridgeCo chip in order to meat that spec".

Processing ?

In either case, the sound was horrible. Well, maybe not exactly that, because it was a very fresh sound (like a Weiss has a very fresh sound) but there was no resemblance with reality. Mind you, with my own still the same DAC at the end of it.

Thinking in the bit perfect realm, and by now knowing how jitter can be graphed by means of an FFT - a same FFT which shows me how the signal comes out regarding harmonic distortion etc., it is quite easy to see how jitter only (thus still bit perfect) drastically WILL change sound. But here too, one possibly needs to think different from what is common. I mean, if I can change the sound easily by reducing analogue noise which is well under the audible level, we must think better what is going on. An example is the fact that this noise itself creates jitter, because it's in the whole system, and thus "broadens" the variation of the clock signal. So, noise which is inaudible, creates jitter which is audible. Isn't it fun.

By itself this is nothing new for engineers with some expertise on this, but now you really have to listen to this (which tells at least me *everything*) :

Last week I consulted a world fameous company on jitter (I won't mention names, but many will be able to guess), just because I couldn't get rid of some noise. Actually the story is a little different, because I was trying to solve a problem, sent some graphs, and next was told to get rid of that noise first, in order to judge better. I couldn't do it, and thus carried the lot over to there. It was connected to one of the xxx scopes they had there, but the signal was found to be just clean. Oh.
Apperently I provided them some graphs, and without proper interpretation it was found too noisy by them, but at measuring it themselves it was found to be very OK, and actually my 2 hour trip to there had been for nothing. Still though, this is a knowledgeable company, and they could easily apply some adjustments which were better for theory, and without being able to measure the results, I went home and found it really helped.

Now, how can a company -or very good engineer if you like- create a good product in this realm, while they judge a random signal as good enough, while it isn't good at all *and* helps a lot for better sound quality when the particular noise is removed ?
I guess this is what I meant earlier (having this experience already, plus a few others), at saying that it needs other thinking an engineer doesn't "have". We (they) take all for granted what was learned, but what was learned was from 28 years ago while sneakily many things around us improve(d). But keep in mind : I still was helped a lot by this company, while I really couldn't do the particular thing by myself.

All 'n all, from this I learned that I'm operating at levels others never looked at, so in theory this should bring more progress. Sadly, there's nothing to learn from others now (as it seems so far), so it is really difficult for me.
Anyway, and as said, once you are able to graph jitter by means of an FFT (which by itself is nothing special), it is the most easy to see how drastically the sound can change just by looking at the FFT hence the net output harmonics coming from a test tone.

So Pedal, that's the kind of better answer to your original post; when you posted it I couldn't have this answer. Now I can. Tomorrow I may be able to do it even better.

Peter

[manisandher]

Don't take my words too much for granted; The more I think about it, the more I can imagine that deriving the "clock" from SPDIF (or AES/EBU) data just is a complete different story.
That, therefore, SPDIF etc. shouldn't be used at all, is another story again ...

Yes. But I think there are ways to optimise the connection.

In my attempts to get a FireWire interface going, I bought a Pro device with the BridgeCo chip in order to test what would happen at using it. So, I used it via FireWire and SPDIF-out to the DAC (which had an SPDIF-in at the time). So, here too (like with the RME and like what you do with the INT202 Pedal) I just used it as the "interface". The sound coming from that was totally crazy and way bright. I would say that it was normal SPDIF (compared to i2s) but exponentially. Thus ? way way more jitter ? I don't know.

This pretty much reflects my experience in using spdif (and AES/EBU) interfaces. BUT... this is exactly where slaving the interface to the DAC really, really helps. The brightness disappears and the sound becomes 'organic' and 'whole'. The exact mechanism that is causing this, I'm not sure.

My strong advice to anyone using an spdif interface connected to a DAC: if it is possible, try slaving the interface to the DAC. You will be amazed at the improvement in sound.

My strong, strong advice to everyone: ditch your spdif interface and DAC as soon as the NOS1 is available

Mani.