Title: RME FF400 vs. Weiss INT 202 FireWire Post by: pedal on August 31, 2010, 06:43:48 pm In the left corner my old trusty FF400 (http://www.rme-audio.de/en_products_fireface_400.php) From Germany. In the right corner a Swiss newcomer (http://www.weiss-highend.ch/int202/index.html) on loan for a short periode.
The Weiss is about 50% more expensive and has less features. I use my FF400 for one reason only: It receives a firewire signal from my PC, and it generates the RCA spdif signal for my Buffalo II DAC. Listening tests a couple of years ago proved that the FF400 sounded better than USB, with slightly better transparency and microdynamics. (This was before asyncron USB became available). In fact, I have been very happy with my sound lately, except for a slight "softness" of transients which I have adressed to my interconnects with the telling name "SILK". Connecting the WEISS box yesterday evening was a shock. It sounded much more dynamic and "sharp" compared with RME FF400. More transparent all over and more tight in the very low bass. Curiously it sounded much louder too. (I didn't measure, but had to step down the volume several dBs - how can it be?) I only had time for a few familiar songs, so I must of course do a longer more systematic listening session. With the Weiss, trumpets really got their metalic "blast" (blat?) which I have been missing and (wrongly) attributed to my interconnect cables. I havn't been so excited for a long time. The cost of upgrading 5 sets of interconnets has really mared me. Perhaps the sound is slightly too much "in your face" now, but that is something I certainly can tweak and solve. Eventually I step down the tweaters a dB on my electronic X-overs. Also there are adjustments in XX on hand. It seems to me that the RME FF400 (and FF800) sucks in a highend setting. Probably their synthetic clock is not up to the best standards. When I come to think about, Peter also ditched his FF800 some time ago, saying that I2S was a totally different league. So, Firewire is not Firewire, there are big differences. Firewire is probably the better digital sound protocole, compared with USB and SPDIF. However the very best protocole is NO protocole. Which means running native I2S straight from the PC to the heart of the DAC chip, which is what the PHASURE DAC is doing, as far as I have understood. The Weiss is really a killer component. On top of it, there is a remote digital volume controle. However, it's high price puts it too close to a COMPLETE Phasure DAC setup from XX, so I'll wait for the complete Dutch solution. :xx: ---------- Morale of the day: There is much more sound quality to gain from tweaking the PC-DAC interface. Probably most of us have no idea how far digital sound quality can be stretched when EVERYTHING is done "perfectly" in the PC-DAC route. PS PS: Hold on to your trusty inexpensive interconnects, they might be better than you think... Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: PeterSt on August 31, 2010, 11:23:38 pm Hei hei Pedal, nice post !
Maybe Mani can comment with some sense. I think he has both too (a FF800 though, but that really shouldn't matter). Btw ... you may not know it much from our forum here (I don't think I told much about it), but I reall really took much effort in a FireWire interface for the Phasure NOS1, but after a whole year of pushing I gave up. I have development boards of all the known chips, but they all s*ck all over. Ok, my opinion. The DICEII too (IIRC used in the INT202) is just not for real. I mean, to me it is impossible that (indeed !) it is so much more loud on its SPDIF interface (within FireWire). It's processed ... somehow. The only trustworthy seems to be RME, but it is proprietary AFAIK. All 'n all, to me FireFire seems a bit of a hoax, and the Pro world really protects it (meaning : the consumer world won't have entrance to it, unless it's a Weiss, them coincidentally providing "comsumer products" just the same). But trust me, your Buffalo(II) sounds better than any Weiss or other Pro DAC (I know, which is different from a converter). But I think Mani uses the INT202 over his FireFace (which latter really isn't on par with jitter specs from today :)). Just my 2c. Peter Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: manisandher on August 31, 2010, 11:57:35 pm Just for clarification, I have the following interfaces:
- Weiss AFI1 (firewire) and not the INT202 - RME AES-32 (PCI) - RME FF800 (firewire) - MOTU 896HD (firewire) - M2Tech hiFace (USB) My only interest is in interfacing my ADC/DAC to my PC, and so I use these in a similar way to pedal.. My strong preference is the RME AES-32 - it simply sounds the best in my setup, easily bettering the Weiss AFI1, which does sound bright and edgy in comparison (maybe a family trait here?). And I'm really not convinced by the DICEII firewire chip. I think Weiss use it because computer audio (as opposed to digital audio) hasn't really been what they've made their name in, in the past, so they simply buy the firewire solution off the shelf. Incidentally, I chose the AFI1 over the INT202 because the AFI1 can accept wordclock I/O. Over many years of experimentation, I'm absolutely convinced that the master clock needs to sit as close to the ADC/DAC chips as possible for the best SQ, and if you're using a separate ADC/DAC, this just isn't possible without a wordclock I/O. Maybe, as pedal suggests, the RME clock isn't great. But that's not an issue if the unit is being slaved to the ADC/DAC clock... Mani. Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: pedal on September 03, 2010, 10:34:30 am Thanks Mani and Peter for your feedback. There is consensus between us that the Weiss is several dB louder and that it has a completely different sound than the RME family. "Different" in the meaning of brighter, more edge, etc.
Yesterday evening I had another hour of critical listening. First I reduced 1dB on my electronic crossover at 800Hz (I have a ribbon tweeter covering 800-40kHz). This improved the subjective tonal balance, making the system quite neutral on most records.* Still I could enjoy a sharper definition and "faster" sound. I got more realism from guitars and brass. I would not say it sounded TOO edgy or "metalic". Also I hear more recorded details, with a better sense of acoustics. The stage gets bigger, simply put. There is a see-through quality missing from the RME. But there is a catch. I miss the relaxement and ease of the RME. With Weiss it sounds like the musicians drank too much Red Bull in the studio. Open question to everybody: Any suggestions how to change my XX settings to add more "relaxement" and ease? [Similar to what we experienced here on the forum when reducing Q1 from 14 down to 4 and below]. Today I use (see signature) Engine 4, Adaptive Mode, Latency 1024, Q1=1 Q2-5=0. -------------- The Weiss is on loan. I am not buying it. But this is an interesting and educating territory, well worth exploring. Hopefully the I2S interface from PHASURE will combine the 2 traits: The RME ease combined with the WEISS speed. *FYI: There is no fasit which XO settings are correct. I have a 3-way system, where bass and treble can be adjusted in relation to the (fixed) midrange. The principe of tuning is rather simple: As much bass as possible, without getting boomy or without getting too chesty male vocal. Same principe with the treble: Maximum level without sound edgy on "most" records. There is no setting which is perfect for all records. I tune it to suit a large range of neutral quality recordings. Sometimes I wish I had 0,5dB steps instead of 1dB steps. Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: manisandher on September 03, 2010, 11:16:05 am Pedal, this is probably not very helpful, but here is what I would look into...
1) Get a wordclock output working from your DAC to your interface. Of course, I understand that this may be very difficult, impossible even. Not only do you have to figure out what to do on the hardware side, but you also need to figure out a way to switch rates at your DAC. Even if this is possible, it's a right PITA. 2) If this is a no-go, then I'd play around with different spdif cables. There is one that not many people know about, which is supposed to be better than any other, irrespective of price. It is the Belkin Platinum Synopsis cable (#F8C310-06-PLT). This will definitely take out any trace of digital sound that you have. But, you won't be able to find this anywhere - people who have this cable will not change it for anything else. However... I have a spare cable (brand new, still in package). Although I'd rather keep it, I'd be happy to sell at the same price I paid for it (~€50 IIRC) :). 3) More practical, I'd keep your current settings and play around with the split file size. No doubt you've followed the thread - it really changes the sound, with a higher split file size providing a 'more relaxed' sound - a Red Bull detox. Mani. Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: PeterSt on September 03, 2010, 02:50:38 pm Quote FYI: There is no fasit which XO settings are correct. I have a 3-way system, where bass and treble can be adjusted in relation to the (fixed) midrange. The principe of tuning is rather simple: As much bass as possible, without getting boomy or without getting too chesty male vocal. Same principe with the treble: Maximum level without sound edgy on "most" records. There is no setting which is perfect for all records. I tune it to suit a large range of neutral quality recordings. Pedal, I can't be sure, but it looks like you are skipping the dimension of the cross-over "connection"; Whatever means of crossover you use (L/R, Bessel etc.) there is one - and one "level" point only where the crossover matches. You can't just turn up the level of one section, and forget about the other; the connection will "shift" and the phase will shift. This means mid and bass (or mid and high) don't coorporate, and which is the foremost thing going wrong in speakers (and speaker design). Peter Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: AUDIODIDAKT on September 03, 2010, 04:00:40 pm Pedal,
Maybe a little offtopic here, but anyway Don't underestimate the need for a "clean" speaker XO, trimpots to adjust the volume of seperate speaker-drivers in XO isnt the way, use for eg. high-end resistors. (L-Pad) Maybe do some tweaking there, dont know about your soldering skills. Just out of interest, maybe you can post/PM your x-over schematics or speaker type. X-over looks kind of "dirty" to me, very simple to clean this up. Trimpots in the low-end is not the biggest problem, but behind a tweeter is undone, When I build speakers I always set the tweeter-volume by ear, so get a handfull of resistors and 2 wires out of your speaker and just make several combinations to lower the output of your tweeter. When this is found, then solder the resistor directly to your tweeter. NO knobs/trimpots in the signal path, anywhere! Roy Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: boleary on September 03, 2010, 06:05:41 pm Quote Open question to everybody: Any suggestions how to change my XX settings to add more "relaxement" and ease? Like mani said, adjusting the SFS (split file size) is a relatively quick fix. When you do play a trak at a volume up to where it sounds edgy at your current settings, then increase you SFS by twenty and see if it sounds a little mushy. If so turn up the volume a bit and see if that brings it into better 'focus". Repeat until edgyness goes away and mushyness is no longer! Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: AUDIODIDAKT on September 03, 2010, 06:15:52 pm Thank you Boleary (and Mani) for pointing that out a while ago, about the SFS.
I got very good results at high CPU speed (3,2 a 3,4Ghz) and lowest SFS (12MB). This is at special-mode 48samples 1,30,30,0,0. This is mostly for my ambient section. I still have to try adaptive mode on other genres. Also very difficult to find common sense in this. Roy Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: pedal on September 03, 2010, 07:03:52 pm Hold your horses, Gentlemen. Don't get carried away in the wrong direction! My electronic XO are top notch, (RRP €4k/pair): 3-way, dual mono chassis, external power, all balanced circuits (true push-pull operation), DC-coupled, no capasitors, 4th order Linquist-Reilly, high grade components, etc. Adjusting treble level +/- 1dB doesn't degrade anything.
----------- Mani, thank you very much for the cable offer. You are allways so helpful and supportive here at XXhighend. However, I do not plan any changes of hardware before the PHASURE DAC and its companion I2S interface has been installed in my system. Then I will take it from there. But thanks anyway for the offer. (I'll try to google a little about this special cable. It triggered my curiosity). ---------- Next listening session will be dedicated to the setting of SFS, that's for sure. ---------- Back to the Weiss - RME duel. It's quite amazing that 2 interfaces sound more different than 2 DAC's can do. I mean, both devices are "bit perfect" (according to the manufacturers promotion blurb at least), so how come such gross differences? Peter: Can you tell more specifically the SQ gain you got when replacing your RME 800 with the new I2S proprietary connection you have developed for the PHASURE DAC? Open question: I think the Buffalo II DAC connections for external clock/-syncing. Maybe I could hook it up the clock input of the RME FF400. Then everything would run from one (Buffalo) clock. Are there any hinders here? Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: PeterSt on September 04, 2010, 10:40:05 am Quote Peter: Can you tell more specifically the SQ gain you got when replacing your RME 800 with the new I2S proprietary connection you have developed for the PHASURE DAC? This is a very clear refinement of the sound in general. SPDIF sounds "rough" while i2s sounds like it has a much higher granularity. SPDIF is ratatatatata while i2s is bzzzzzzzzzzz :) Quote I think the Buffalo II DAC connections for external clock/-syncing. Maybe I could hook it up the clock input of the RME FF400. Then everything would run from one (Buffalo) clock. Are there any hinders here? I'll be honest : I don't understand a f*ck what the audio(phile) world is trying to achieve with such a thing. Most probably it does "something", but in my mind there's nothing a word clock could improve on SQ ... A world clock maybe, but that's qomething quite different. In addition, I read a test the other day about superclocks and whatever, and no single solution could improve on jitter etc. specs. And if it did, it was marginal. But maybe I must emphasize again that I may not understand things for the technical merits (I did create a DAC from the ground up though haha); The word clock is there to synchronize audio streams between devices. This was "invented" in/for the Pro world, them having numerous digital decives, and they all have to process the samples at the same time. So, a word clock is about samples and when a next sample (devided by Left and Right (etc.) is to be processed. There is NO reason in my mind this could improve on jitter or any other SQ merit. Of course, unless this is about two or more devices processing the same data - or data which must be synchronized. Think about several channels which are mixed and go through digital mixers and other processing devices; you'd really want the samples of all those in fact loose running channels to be aligned. Well, the word clock is doing just that, and it takes a master and slaves. So, what would happen is that your word clock in the ESS is based upon a more stable physical clock (oscillator) than the one in the RME (which in today's terms is not stable at all), so the start of a sample is better defined or whatever you like to think with this. It still does nothing to the sound. How can it. It is the bit clock which is the one "defining" the sound - hence carries the more or less jitter. The bit clock is in your DAC and it determines when a complete sample is put out. Yes, it does that on the edges of the word clock, but it is still the bit clock which determines when to look. So, for a 32 bit sample, you can take it that the bit clock runs at 32 times the speed of (half of) the word clock, which is needed to shift in the bits, bit per bit. After 32 of them have been passed, it is the change of the plus/minus of word clock (which is a square wave with e.g. the plus part for the left channel and the minus part for the right channel) which tells the DAC the sample must be complete (and not because 32 bits were counted somewhere somehow). And notice that while the word clock has a fixed relation with the bit clock (no matter a master clock somewhere else created the word clock), it really can be so that after 32 bits the changing plus/minus of the word clock comes by. Always. Also, when the sample width would be 16 bits, the word clock is "smaller", so that now after 16 bits the plus/minus change comes by. On the danger of being the most snobby guy in this world, I really really don't understand all the techno babble on other forums on async and whatever connection means, or PLLs ASRCs and name it to improve on jitter specs. To me it looks there's just no single engineer around who really understands. Am I saying something here ... :smirk: For the Phasure NOS1 DAC I have two connection means, both equally good for jitter; the one I am using for a year or so now, and if you see it (which will happen :)) you'll say "oh, well, yeah, hmm ... I could have thought of that" which in the end is true, BUT you won't be able to understand the technical implications hence merits of it. However, looking at the specs (or listening) will tell you that something must me in there which is "better" than common, and I will tell you that this can only be achieved by doing it the way it has been done. But : From this other connection -which still is in the make and still may fail because of not thought implications- you will look and look and look, and you will not understand how it works in the first place. This is already *the* reason why it's made. It's completely proprietary and completely new, other than the first "oh well" connection. I only want to say : this second connection (if it gets to work) will show you how things really are and how any "async" whatever thinking is just the difficult way to do it while it *still* will have all the jitter inherent to a DAC once the data is inside of the DAC. Not so here, because here the only jitter which can be there is the jitter of the physical clock, added with the jitter which emerges from "dividing" to the bit clock, which is not necessarily the physical speed of the "oscillator" (44.1 needs more divisions than 88.2 than 176.4 than 352.8 ). Btw, at this moment I am trying to get a grab of how to show the (measured) jitter expressing in dB, in a time figure. Funnily enough this first needs to bring down the noise level even further than it is, because otherwise there's nothing much to see for the various types of jitter. On this part there's more going on than what I see in the books, which will all be about the way to measure, what the analyser inherently can show (like discrete jitter figures), not being able to use the SPDIF ouput of the analyser (hence its generator) because I don't have SDPIF input on the DAC, the limits of the analyser (like 192 sample rate while I use 384), how to bring forward what, and how to exactly interpret things. Yes, I am trying to be a John Atkinson, but I really am not. Maybe later. All 'n all, a rather long story to tell you that hopefully soon I will be able to show things by means of graphs and figures, and why a word clock really can't make a difference. Oh, it will make a difference allright, but nothing under our control. I hope I didn't lie too much. Peter Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: manisandher on September 04, 2010, 11:02:27 am Most probably it does "something", but in my mind there's nothing a word clock could improve on SQ ... A world clock maybe, but that's qomething quite different. ??? Here's what Pat at 'Analog Research Technologies' had to say about it when I asked him: "Transmitting a word clock, separate by itself, will greatly reduce jitter. But, it will not eliminate it. Most modern DAC chips use the bit clock, as the crucial clock. The word clock merely tells it when all the bits are loaded. (Look at the PCM1704, as an example. The conversion takes place 2 bit clocks pulses after the word clock changes state.) It would seem to me that there has to be some sort of PLL, to derive the bit clock from the word clock. Obviously, this is a much easier matter than getting the bit clock from the SPDIF (or AES/EBU signal), but there will be a measurable amount of jitter. Audible? Perhaps not. It will be Gaussian in nature, and the threshold of audibility is higher, than with data-correlated jitter." In any event, my experience is that if you're using an spdif cable to connect a PC-interface to a DAC, the best SQ is achieved when you slave the PC-interface to the DAC via a separate wordclock cable. But of course, eliminating an spdif cable in the first place may be a better solution. Mani. Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: PeterSt on September 04, 2010, 12:34:57 pm Haha ... if your "???" was about "world clock" ... I was just joking. But at least that's an atomic clock.
If your "???" was about not understanding what I said ... Pat there says exactly the same. One small difference : he thinks the bit clock may be derived from the word clock. IMO this is nonsense. Btw, we can also think that Pat is saying (implying) that the word clock drives the "conversion" (letting loose of) the samples - or at least in DAC cases. IMO that would be very bad because the word clock will be a huge division (like 16 times) of the physical clock ... unless the physical clock runs at the speed of the (max) word clock, which I don't think will be the case anywhere. But : You already can see where the difference (and misinterpretation) starts : he takes SPDIF as the base. I don't ... I just don't have it. Here too : Quote Audible? Perhaps not. It will be Gaussian in nature, and the threshold of audibility is higher, than with data-correlated jitter." True (I think) about the Gaussion nature, but not true on the data correlated part. i2s inherently can't have data correlated jitter ... (although I can measure some !). Anyway, this is a perfect example of those "merits" I talked about, just looking at the "oh .. well" connection I use. It wil look as simple as can be, but in the mean time all bases as to how people normally look don't apply. And this, to my experience, is not how an engineer apporaches things. I guess you have to be a software engineer to approach this stuff how it should. Forget all you have learned, and create new stuff not hindered by formal knowledge. Create a base with many ways to Rome. Make it modular so it will survive future changes. The latter, btw, is exactly why I can still be working on these matters, while in th mean time the DAC is completely finished. This is also about (deliberate) software parts, the hardware explicitly anticipating on that softare (changes). AP is an example of it, but not what I talk about here. I have never had so much fun in my life, and the closer I get to the optimum, the better I can see what can be improved. So right now, each and every day I can explicitly improve *again* just by interpreting the signal as the result from the previous improvement. The fact that my scope just shows completely silence is greatly attributing to this all, while the analyser sticks at a certain level of noise. This means I am now looking to "digital" noise only, while because it was a mixture of analogue and digital noise and no sense can be gotten from that. So, another hurdle was taken (only last week !), and now I can start working on the real merits. Just because they allow interpretation now. But ... which suddenly means I have to understand it all, and most probably in areas nobody did before. What this all brings is totally unbelieveable. You may recall I havge been talking about stuff like flagiolettes coming forward so much (which is about harmonics only), but there's also the (at this moment still) very strange phenomenon like oscillating on-stage amps coming forward so much. That too I have mentioned before, and this is about the (mainly) electric bass performers, screwing up the volume of their amps to max in order to softly play with loud bass volume. This creates a buzz (oscillating) in their amp, and I have examples which are totally unlistenable because of that noise getting nearly as loud as the music. 2 months back I didn't even know this "noise" was in the particular track ... It's similar to the cymbals. How can they come forward sooooo much, while 2 years ago they just weren't there at all. Right now I'm experiencing another freaky thing : each day there are more cymbals again, just because there are so many (cymbal hits) in a random track, and it's just the level they are played which make them vanish ... until I squeeze them out. And this is about reducing noise only (this, while the analogue noise is totally inaudible from the speakers without signal, which of course the scope already told me). All 'n all, there's noise and noise, and where an analyser shows THD+N, the N has disappeared 100%, making THD the noise itself. And so, at the bottom of this all (read : the noise level) there's a kazillion HD distortions I can work on now. And so I do ... Peter (quite off topic, sorry). Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: manisandher on September 04, 2010, 01:12:56 pm Hey Peter, I always appreciate your long posts. But I just wanted to say that your above post struck a particularly sweet chord... I have never had so much fun in my life... For me, this says it all.In his book, 'Good to Great', Jim Collins talks about the 'hedgehog principle'. A great company has three factors in place: 1) it is passionate about what it does 2) it is the best in the world at what it does 3) it can sustain itself economically from what it does One of my favourite companies in the world is Rolls Royce (aero engines, not cars!). I think it fits all three factors. But I think you can apply these three factors to individuals as well. When you're doing something that hits the spot on all three, then look no further... you've found your 'calling'. Mani. Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: pedal on September 04, 2010, 11:49:22 pm Hello fellows, do you remember the old Peter? The self made audiophile who could post and post about bass increasing with 10dB just because of some modification in XX, and all that?
Well, it’s all gone now. Finished. Now it’s the new Peter. After studying DAC constructions and looking into his scope for days and nights he’s become serious. Dead serious. -Doesn’t even believe in external word clocks anymore… :o Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: PeterSt on September 05, 2010, 07:41:15 am 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 ? :swoon: :) Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: pedal on September 05, 2010, 09:02:01 am Btw Pedal, wasn't that 26dB ? :swoon: 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."] Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: PeterSt on September 05, 2010, 10:15:17 am Quote 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. :prankster: Very well said, I think. However Quote 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 Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: PeterSt on September 05, 2010, 11:08:47 am 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 Title: Re: RME FF400 vs. Weiss INT 202 FireWire Post by: manisandher on September 05, 2010, 01:05:22 pm 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. |