You can say whatever you like. Meanwhile, high-end audio companies continue to release products based on FireWire.
UAD just announced this month a FireWire-based DSP accelerator card - one that should be very attractive to folks wanting to perform biamping EQ without the hiccups of running under a generic operating system.
Metric Halo Labs released their LIO-8 FireWire audio interface last year, and are winning awards this year as probably the best DAC on the planet.
These are not the cheap USB Audio interfaces that your grandma buys at Fry's. It's a totally different ball game.
Sorry, but you're wrong. Jitter is random timing fluctuations, and it is audible as an increased noise floor at best or correlated distortions at worst. Jitter introduces analog errors tens of thousands of times per second. So, it's 'constant' in the sense that it is happening all the time, but it's not literally constant because the timing error is different with every sample.
Thanks for the encouraging words!
Hmmm, how do you multiquote?
Don't mention it. People like me getting the best out of smart people as you is called progress ;-)
You can say whatever you like. Meanwhile, high-end audio companies continue to release products based on FireWire
.
I usually say whatever I like
UAD just announced this month a FireWire-based DSP accelerator card - one that should be very attractive to folks wanting to perform biamping EQ without the hiccups of running under a generic operating system.
Metric Halo Labs released their LIO-8 FireWire audio interface last year, and are winning awards this year as probably the best DAC on the planet.
These are not the cheap USB Audio interfaces that your grandma buys at Fry's. It's a totally different ball game.
Yes, dead was an overstatement - sorry. But the target is moving from the home to the professional domain. There is little interest from the broad market.
Sorry, but you're wrong. Jitter is random timing fluctuations, and it is audible as an increased noise floor at best or correlated distortions at worst. Jitter introduces analog errors tens of thousands of times per second. So, it's 'constant' in the sense that it is happening all the time, but it's not literally constant because the timing error is different with every sample.
If it is as bad as you describe - of course it affects the sound. What was these people thinking of when they created the standards?
Thanks for the encouraging words!
Don't mention it. People like me getting the best out of smart people as you is called progress ;-)
Hello guys,
back from a short trip... I see things are getting wild here
There's a lot to chatch up for me thus I'll try to share my opinions one at a time... hoping I'll not ruin the thread
WaveIO must be redesigned, main goal being the need to isolate things there (and I'm speaking about I2S). On my perspective, digital (noisy) ICs must stay on one side of board while sensitive/analog ones on the other side. Besides that, I saw how "sensitive" the XMOS reference design is (mostly in software) thus I'll try to keep this implementation close to original as possible (for obvious reasons)... meaning that, from the hardware point of view, I'll not place any isolator between the XMOS and PC/MAC. I'm tired about BSODs and other "fancy" behaviours without them.
On the other hand, I2S must be isolated somehow and now, I'm thinking how to do this without getting too much jitter on the path. One solution could be to realign all the I2S signals at the DAC side but for now it's in prototyping stage...
Cheers,
L
back from a short trip... I see things are getting wild here
There's a lot to chatch up for me thus I'll try to share my opinions one at a time... hoping I'll not ruin the thread WaveIO must be redesigned, main goal being the need to isolate things there (and I'm speaking about I2S). On my perspective, digital (noisy) ICs must stay on one side of board while sensitive/analog ones on the other side. Besides that, I saw how "sensitive" the XMOS reference design is (mostly in software) thus I'll try to keep this implementation close to original as possible (for obvious reasons)... meaning that, from the hardware point of view, I'll not place any isolator between the XMOS and PC/MAC. I'm tired about BSODs and other "fancy" behaviours without them.
On the other hand, I2S must be isolated somehow and now, I'm thinking how to do this without getting too much jitter on the path. One solution could be to realign all the I2S signals at the DAC side but for now it's in prototyping stage...
Cheers,
L
HTML:
I manually insert [/quote] and [quote]
(end quote and begin quote)
in the larger quoted text
anywhere that I want to comment,
then I type my responses in betweenIt was so long ago that I don't know. Certainly before my time as a professional, although I was curious at the time. I get the impression that they really were not aware of the effects of jitter. I certainly did not understand until I attended an AES meeting where someone demonstrated it in real time with frequency analyzers connected to the output of a CD player. Part of the issue is that it's cheaper to omit a quality master clock, but the original standards seem more like they were completely oblivious rather than just cutting costs.
I met one digital audio circuit designer who admitted that he did not realize the importance of the layout of traces and other esoteric aspects of the clock design until someone demonstrated the improved clarity of the sound. Afterwards, he put way more effort into every board design, and the company's products were all the better.
One innocuous aspect is that if the spectrum of the jitter noise is Gaussian, then it really just adds noise that reduces the effective bit depth. Unfortunately, it's far more common that the jitter noise has some unnatural spectral quality that is correlated to the data in a way that sounds really harsh.
Whether it DOES is on a case by case basis.
Until somebody measures it on a comparative basis it hasn't been demonstrated that it CAN in any case.
You've got NO IDEA what constitutes evidence.
You just make these claims, not even realising that you invalidate them in the next sentence. You need to learn to think about what you yourself have written. The overall contribution of your statement is noise.
This is one of their most helpful documents - the USB component recommendations start on page 12:
http://www.murata.com/products/catalog/pdf/c35e.pdf
His point was perfectly clear to me
OK, elucidate it.
Let's face it, you two are simply seeking to dispute with anybody you think might be competent to put up a good argument.
Now, c'mon friends. We are probably all twisting strings on subjects where there are no commonly agreed answers yet. Thats a definition to me of an emerging standard...
The first step would be to bombard MS with request for a uac2 common driver and build the hw from there.
Yupp, I have sent my wishes to ms. Whatever they decide will of course set the baseline even if we know better ;-)
Brgds
The first step would be to bombard MS with request for a uac2 common driver and build the hw from there.
Yupp, I have sent my wishes to ms. Whatever they decide will of course set the baseline even if we know better ;-)
Brgds
Last edited:
Now we are moving. What is jitter (we know this)? How much were allowed if quantification methods were available at the time on implementation? If not, what is the best method to measure it so it would be understandable by the average buddy/Joe/Clarissa (me
I do not favor the term "jitter", but "phase noise".
You can look at "phase noise plot" on this page.
phase noise definition
In this example, the plot is for a master clock.
I wish we could measure a phase noise for MCLK, LRCLK, BCLK signal of I2S just at input pins of DAC chip.
I2S and async USB...
1. For I2S you have: data, bit clock, word clock, and master clock:
Some DACs, will not need masterclock, as they will be using their own and reclocking-aligning the master clock to the bit clock. But best performance will be realised with one oscillator producing both the masterclock and bit clock, so that no realigning (PLL) is needed, as long as the provided clock is low in phase noise.
2. For I2S the sender does not have to be the master. For example, again the Ayre QB-9: the two oscillators are on the DAC board, close to the DAC chip, and then the master clock signal is sent back over I2S to the USB receiver (which is XMOS based). The DAC board is powered by a separate supply from the USB receiver board, hence the oscillators get a clean supply.
Lorien, could the new rev be made with the option to accept masterclock in to accommodate the approach used in "2" above?
1. For I2S you have: data, bit clock, word clock, and master clock:
Some DACs, will not need masterclock, as they will be using their own and reclocking-aligning the master clock to the bit clock. But best performance will be realised with one oscillator producing both the masterclock and bit clock, so that no realigning (PLL) is needed, as long as the provided clock is low in phase noise.
2. For I2S the sender does not have to be the master. For example, again the Ayre QB-9: the two oscillators are on the DAC board, close to the DAC chip, and then the master clock signal is sent back over I2S to the USB receiver (which is XMOS based). The DAC board is powered by a separate supply from the USB receiver board, hence the oscillators get a clean supply.
Lorien, could the new rev be made with the option to accept masterclock in to accommodate the approach used in "2" above?
hi folks
little off beat question... but necessary for me to join my buffaloII with WaveI/O.
WaveI/O has outputs provision of MCLK, LRCLK, BCLK and DATA , now where do they in relation with the BuffaloII inputs of the I2S, there the SCL,SDA, GND,and DVCC .,
i don't understand the abreviation of those terms that are used for the I2S inputs on the Buffalo dac , i looked and looked but to no avail .
any help is appreciated .
regards
rols.
little off beat question... but necessary for me to join my buffaloII with WaveI/O.
WaveI/O has outputs provision of MCLK, LRCLK, BCLK and DATA , now where do they in relation with the BuffaloII inputs of the I2S, there the SCL,SDA, GND,and DVCC .,
i don't understand the abreviation of those terms that are used for the I2S inputs on the Buffalo dac , i looked and looked but to no avail .
any help is appreciated .
regards
rols.