| MWP |
Hi all,
Im trying to work out how I need to use the SRC4192 resampler IC.
Im going to be setting up somthing like:
DIR1703 -> SRC4192 -> DAC
Does anyone have an schematic, etc they can put up as an example?
Ive been getting rather large headaches working out how to tie the three ICs together... in particular what input & output port modes the SRC4192 should be in, and where to get clocks from.
Thanks. |
|
|
| 5th element |
Just a stab in the dark really. With the clocks I would imagine you would take the SCKO from the DIR1703 and input it directly to the SRC4192 RCKI pin. Then you select the same clock rate on both the DIR and the SRC via the relavent pins. Say you had SCF0 high and SCF1 low for a DIR of 256Fs. You would then select mode0,1 and 2 to either 1,1,0 or 1,1,1. depending on if you need input or output master mode? Appart from that I dont really know, its just a guess.
As I cannot see anywhere which indicates how you select the sample rate conversion it could be dependant on the clock selection:scratch:
How to select what data to accept from the DIR and what data to give to the DAC looks simple enough. Im a little confused myself haha. But my next DAC was gonna be based around DIR1703 some upsampling device and then say four DAC chips in the output. PCM1794 in mono mode and paralleled or something. |
|
|
| gmarsh |
I've used the AD1896 chip, which is more or less identical.
From the DIR170x chip, you'll need to bring over I2S/LJ/whatever signals only - these attach to the BCKI, LRCKI and SDIN pins on the SRC.
The reference clock input (RCKI) is driven directly from your local oscillator, and the same oscillator that drives the DAC.
Pin strapping is used to determine the input/output formats, and to determine the output sampling rate of the SRC relative to the RCKI input. |
|
|
| 5th element |
| So if SCKO from the DIR would normally go to SCK on the DAC chip, you connect the SCKO from the DIR to the DAC & the SRC? and how do you select your upsampling etc? is it a standard resample everything to 192khz or is it a ratio thing? |
|
|
| fr0st |
The DIR1703 has to be a master and it would probably be easier having the DAC as a master aswell.
You can disregard the master clock of the DIR1703 and only connect the Data, LR clock and bitclock to the ASRC's input port. On the DAC side, connect the Data, LR clock and bitclock to the ASRC's output port and your local oscillator (must be >= 128Fs which is probably your DAC MCLK aswell) to the ASRC's reference clock input. Both the input and output ports are in slave mode and your DAC must be the master.
The data format between the ASRC and DIR1703 can be of your choosing, they just both have to be set the same (16 bit right justified for cd?). You also have to set the output port format, as long as your DAC is set to the same thing it won't matter too much.
This way all data is upsampled and reclocked with a low jitter local oscillator instead of the DIR1703's 70ps one.
I think I explained that right.... |
|
|
| 5th element |
So in this situation do you still use a crystal with the DIR1703 or would it be better to drive the DIR from the accurate oscillator clock? I think it can work like this.
Im assuming that you would make something like the tent clock to feed the DAC and the ASRC. |
|
|
| 5th element |
| I d/l yet another pdf file :) |
|
|
| fr0st |
I normal crystal should be fine in the DIR.
I'm not 100% sure but I'd imagine that the internal PLL (or oscillator) creates most of the jitter and not the crystal. The ASRC should eliminate any jitter on the input clock anyway, as long as the data in clocked in correctly and the frequency remains constant (I can't remember how accurate but it would be to strict, probably 100-200ppm ) the ASRC should be fine.
The DAC clock should be of high accuracy since it uses it as a time base for the output.
Please correct where wrong :clown: |
|
|
| jcx |
Just a little reminder
There is no reason for ASRC in the reproduction chain, it simply encodes the sum of transport and ref clock jitter into the PCM words
The only legitimate use of ASRC is in the studio to merge live digital streams with multiple clock sources
The consumer can only assume that the PCM words on those shiny disks are meant to be reproduced at equal sampling times with the minimum jitter, Reclocking with a deep buffer (hard disk or even full track length ram as in xrcd mastering) and quality reference clock is the best “add on” option if a well executed (or tweaked) integrated player is for some reason considered unacceptable |
|
|
| MWP |
| So there is no improvment to be had by upsampling to 192khz before the DAC? |
|
|
| Pitch254 |
Whether or not to apply an ARSC, Fr0st got it right.
That´s the correct way to connect the thing. |
|
|
| AMT-freak |
| quote: |
There is no reason for ASRC in the reproduction chain, it simply encodes the sum of transport and ref clock jitter into the PCM words
|
Sorry to say, but this is plain wrong.
We agree that the best way to avoid the jitter issue is to locally clock the DAC and slave the transport to it (no matter whether the DAC is internal or external).
The second best, however, is using an ASRC with a local low-jitter clock clocking both directly the DAC and the ASRC. The ASRC apporach has a much better jitter supression performance than relying only on a PLL in a crappy receiver chip! The misunderstanding an ASRC would encode the jitter into the PCM comes from the simplified model of ASRC operation that we have in mind... The underlying math is too complicated to be explained in a few words, but here is an excellent in-depth thread.
The buffer approach is somewhat impractical, at least for DIY. Either you need some means to pitch the transport's clock to adjust the "buffer fill level", but then you would better slave the transport to the DAC and avoid the buffer alltogether. Or, you would need a buffer which is big enough to contain your complete listening session, and you would have to load it before you could listen to music. |
|
|
| jcx |
Good thread,
Difficult material to present in this format, but pedagogically flawed, the context and central claim should be up front rather than having to plow through the "tutorial" presentation to ~ post#65 ( refuting your "plain wrong" claim btw ) and finally post #80
The central claim is that starting from a spdif data stream, with the limitations of practical CMOS integrated pll receivers, that existing ASRC chips provide effective jitter filtering while syncing the recovered bit clock to a local high quality oscillator
At the moment I can only say maybe, I need to think about it – I have Adam’s papers at home and have designed and implemented polyphase FIR filters to do fixed time interpolation so I do have the background to follow the argument but I currently don’t see I don’t see how a length 64 FIR ( @ 44.1KHZ ) gives jitter suppression down to 3 Hz in the ASRC |
|
|
| tiroth |
| quote: | Originally posted by jcx
At the moment I can only say maybe, I need to think about it – I have Adam’s papers at home and have designed and implemented polyphase FIR filters to do fixed time interpolation so I do have the background to follow the argument but I currently don’t see I don’t see how a length 64 FIR ( @ 44.1KHZ ) gives jitter suppression down to 3 Hz in the ASRC |
Have you read the AD1896 data sheet, especially "The Conceptual High Interpolation Model" and the following hardware model description? The conceptual model is of 2^20 convolutions per period, it is only by some cleverness (and fudging) that it is reduced to a single 64-tap filter. |
|
|
| jcx |
The polyphase implementation of the asrc interpolation is a filtering process, however clever the coefficient selection a fir filter cannot attenuate frequencies much below the lowest zero that can be implemented given the filter length, for 44.1 KHz / 64 tap filter this ~= 690 Hz, further the point of this filter is to pass 20KHz audio without attenuation so the jitter attenuation of the asrc filtering is restricted to frequencies above audio
My reading of the ad1896 data sheet leads me to believe the jitter attenuation below 20 KHz is the result of the digital pll, so we have Werewolf’s argument in serious trouble, after all he “set fire” to the “straw man” implementation of cascaded plls early in his argument and appears to attribute the jitter reduction superiority of the ASRC chip implementation to the ASRC process itself
I can now step back and agree that a ASRC chip that implements a superior jitter reduction pll may be a viable approach depending on the details of the ASRC pll performance but still would point out that the equivalent performance pll that simply reclocks the data will give the same jitter reduction without necessarily impacting the pll design by needing to implement it on a mixed signal/digital CMOS process along side the ASRC polyphase filtering circuitry |
|
|
| rlim |
I just found out from the headfi forum that the src4192 may not have the digital servo loop's low-pass set to a low enough frequency, thus defeating any jitter attenuation properties of the ASRC. Has anyone here heard of that? According to John Siau, director of engineering for Benchmark Media Systems Inc., the low-pass is set at 5KHz, way too high......
rlim |
|
|
| Wodgy |
| Regardless of where the jitter attenuation abilities of the AD1896 come from (be it the pll or the ASRC process itself), the actual measured performance of the AD1896 at rejecting jitter is hard to argue with. Given the reasonable price and ease of implementation, there aren't many better alternatives. |
|
|
| gmarsh |
| quote: | Originally posted by Wodgy
Regardless of where the jitter attenuation abilities of the AD1896 come from (be it the pll or the ASRC process itself), the actual measured performance of the AD1896 at rejecting jitter is hard to argue with. Given the reasonable price and ease of implementation, there aren't many better alternatives. |
It's the clock ratio estimation / digital PLL circuit that provides the function of jitter rejection.
The actual ASRC part of the chip is nothing more than a regular FIR filter on steroids. It doesn't matter if there's jitter on the input or not; provided that the rate estimator/filter generator give the same polyphase filters to the ASRC block and the input data remains the same, the output will be the same.
I'm hammering TI for some information on the SRC chip, but they really don't want to talk about it. Lately i've been bugging them for samples to run up on the System Two at work, but they haven't been eager to do that too... sigh. |
|
|
| Terry_Demol |
| quote: | Originally posted by Wodgy
Regardless of where the jitter attenuation abilities of the AD1896 come from (be it the pll or the ASRC process itself), the actual measured performance of the AD1896 at rejecting jitter is hard to argue with. Given the reasonable price and ease of implementation, there aren't many better alternatives. |
Very true. Just checked out Stereophiles measurements of
Benchmark dac1 and it is one of the best dacs they've
measured *regardless* of price.
The jitter attenuation and low level linearity are superb.
http://www.stereophile.com/digitals...886/index4.html
Cheers,
Terry |
|
|
| Kuei Yang Wang |
Konnichiwa,
| quote: | Originally posted by gmarsh
The actual ASRC part of the chip is nothing more than a regular FIR filter on steroids. It doesn't matter if there's jitter on the input or not; provided that the rate estimator/filter generator give the same polyphase filters to the ASRC block and the input data remains the same, the output will be the same. |
Yes, but is it REALLY SO?
1) The input Data has jitter.
2) The input data is clocked through a digital filter with 64 steps, in other words 64 Input datawords are held in the memory.
3) The data is filtered using a particular coefficient loaded from ROM depending upon the ratio of Input and Output Clock.
4) If the input clock and output clock ratio varies (due to jitter) the selection of the Filter coefficient is changed to account for that
Now, it does matter if our clock ratio estimator actually runs through a sufficiently slow PLL, but does it? Well, that is a question difficult to answer from the datasheets.
Sayonara |
|
|
| gmarsh |
The architecture of every ASRC i've ever seen looks like this...
input clock / output clock ---> rate estimator
(rate estimator is basically a digital pll that tracks the two clocks)
rate estimator's "frequency tuning word" ---> integrator ---> index to polyphase filter generator
input data + polyphase filter from generator ---> FIR engine ---> output data.
If the input/output clocks vary due to jitter, then this causes the rate estimator to think that the clock ratio is higher or lower than expected. So it increases or decreases its "frequency tuning word" to compensate, which causes the filters coming from the polyphase filter generator to vary.
Any instantaneous jitter event on the incoming clock won't immediately cause a jitter error to be encoded in the output clock. The rate estimator typically averages thousands of incoming clocks to estimate a sample rate before the FTW gets updated, and when that happens it's updated gradually anyway. So a single event will typically get averaged out, or the overall contribution to ratio error (and thus the amount of jitter error encoded in the output data) will be very small.
Most high frequency jitter (eg clock recovery jitter) is completely eliminated by an ASRC. But any sort of long term variation in the clock, eg. a warming up clock oscillator that's slowly changing frequency, won't be corrected.
Same applies to any sort of low frequency modulation of the clock... any AC powered signal source has the potential for 60 or 120Hz ripple to appear on the power supply of it's oscillator, and any ASRC worth its salt should be able to attenuate this to extremely low levels.
I wrote an ASRC in DSP. It's an interesting exercise, and a timing nightmare :D
| quote: | Originally posted by Kuei Yang Wang
Konnichiwa,
Yes, but is it REALLY SO?
1) The input Data has jitter.
2) The input data is clocked through a digital filter with 64 steps, in other words 64 Input datawords are held in the memory.
3) The data is filtered using a particular coefficient loaded from ROM depending upon the ratio of Input and Output Clock.
4) If the input clock and output clock ratio varies (due to jitter) the selection of the Filter coefficient is changed to account for that
Now, it does matter if our clock ratio estimator actually runs through a sufficiently slow PLL, but does it? Well, that is a question difficult to answer from the datasheets.
Sayonara |
|
|
|
| Wodgy |
| gmarsh, thanks for that explanation. I found it very helpful. |
|
|
| Kuei Yang Wang |
Konnichiwa,
| quote: | Originally posted by gmarsh
The architecture of every ASRC i've ever seen looks like this...
input clock / output clock ---> rate estimator
(rate estimator is basically a digital pll that tracks the two clocks)
|
Exactly.
Now what kind of precision is required for the PLL?
(Hint, A LOT)
How stable is the PLL?
Does it ever "hunt", especially with cyclic, sample rate related jitter?
I still do not feel that an ASRC makes a good jitter attenuator. It may make the jitter under certain conditions low in a measured sense, however most such conditions tend to be not neccesarily indicative of real world performance.
So, use an ASRC if you need to convert sample rate, use better PLL's and/or memory buffering if you like to reject jitter.
Sayonara |
|
|
| gmarsh |
| quote: | Originally posted by Kuei Yang Wang
Konnichiwa,
Exactly.
Now what kind of precision is required for the PLL?
(Hint, A LOT)
How stable is the PLL?
Does it ever "hunt", especially with cyclic, sample rate related jitter?
I still do not feel that an ASRC makes a good jitter attenuator. It may make the jitter under certain conditions low in a measured sense, however most such conditions tend to be not neccesarily indicative of real world performance.
So, use an ASRC if you need to convert sample rate, use better PLL's and/or memory buffering if you like to reject jitter.
Sayonara |
All-digital PLL's are great in that they're digital. There's no charge pump / VCO / phase detector running inside a SRC chip that's contributing noise and creating its own jitter - instead there's a completely digital "emulation" of a PLL with ideal characterisitics that can be changed on demand, and precision is only limited by quanitzation which you can set obscenely high just by design.
Do digital PLL's hunt? are they unstable?... depends on how you design the loop filter, and what sort of signal you feed them with. If you feed them with cyclic jitter, loop bandwidth will dictate how much they "hunt". Really, they're no different from an analog PLL.
I think ASRC's make a fantastic jitter attenuator - they do a wonderful job of extracting data from a digital audio input while throwing away (arguably) the audible jitter, and they also allow you to use a high-performance, low phase noise, single frequency clock inside your DAC.
Making a VCO that can vary over the entire 44-48, 32-96, 32-192, etc... range of frequencies while maintaining excellent phase noise performance is *hard* - even a high performance VCO for tracking the 44-48 range will likely get stomped by a high quality, off-the-shelf fixed-frequency XO. A VCXO-based PLL won't be far off but it'll only work at one sample rate.
Memory buffers work excellent, except that having the pointers collide in FIFO sounds far worse than jitter :D
Of course, there's no question that the best thing to do is to slave your CD player off your DAC. And for this, I propose that a standard should be created - use LVDS over CAT5/6 cable, RJ45 connectors. Send a sync clock at 256*Fs to the transport, and get I2S back. |
|
|
| Bricolo |
| quote: | Originally posted by Kuei Yang Wang
Konnichiwa,
Exactly.
Now what kind of precision is required for the PLL?
(Hint, A LOT)
How stable is the PLL?
Does it ever "hunt", especially with cyclic, sample rate related jitter?
I still do not feel that an ASRC makes a good jitter attenuator. It may make the jitter under certain conditions low in a measured sense, however most such conditions tend to be not neccesarily indicative of real world performance.
So, use an ASRC if you need to convert sample rate, use better PLL's and/or memory buffering if you like to reject jitter.
Sayonara |
And how good are they, when used as a digital filter (yes, oversampling)? |
|
|
| Kuei Yang Wang |
Konnichiwa,
| quote: | Originally posted by gmarsh
Do digital PLL's hunt? are they unstable?... depends on how you design the loop filter, and what sort of signal you feed them with. If you feed them with cyclic jitter, loop bandwidth will dictate how much they "hunt". Really, they're no different from an analog PLL. |
Exactly. But an ASRC is NOT ONLY a PLL, it is also a Digital filter.
| quote: | Originally posted by gmarsh
I think ASRC's make a fantastic jitter attenuator |
Maybe, my ears so far have told me otherwise.
| quote: | Originally posted by gmarsh
Making a VCO that can vary over the entire 44-48, 32-96, 32-192, etc... range of frequencies while maintaining excellent phase noise performance is *hard* |
Hmm. Why do we need, for home audio, anything but 44.1KHz? Software in other formats is practically non-existent. So, give 44.1KHz "X-Tal lock" and leave things normal for the rest.
| quote: | Originally posted by gmarsh
A VCXO-based PLL won't be far off but it'll only work at one sample rate. |
It doesnt need to work at more than one rate.... At the total max you need two, one for use with 32/48/64/96/192KHz sample rates and another for 44.1/88.2/176.4KHz sample rates.
| quote: | Originally posted by gmarsh
Memory buffers work excellent, except that having the pointers collide in FIFO sounds far worse than jitter :D |
Hmm, that surely is merely a design problem?
| quote: | Originally posted by gmarsh
Of course, there's no question that the best thing to do is to slave your CD player off your DAC. And for this, I propose that a standard should be created - use LVDS over CAT5/6 cable, RJ45 connectors. Send a sync clock at 256*Fs to the transport, and get I2S back. |
Absolutely, but now we are back at single sample rate AND as non-standard interconnection requirements.
Sayonara |
|
|
| gmarsh |
| quote: | Originally posted by Kuei Yang Wang
Konnichiwa,
Exactly. But an ASRC is NOT ONLY a PLL, it is also a Digital filter. |
Yes. I'm only talking about jitter rejection, which is the PLL part of the ASRC.
| quote: | | Maybe, my ears so far have told me otherwise. |
Now we're getting subjective. :D
I've listened to oversampled and non-oversampled DACs, I prefer the oversampled variety - i find that non-OS ones tend to attenuate the high end a bit, music loses a bit of 'bite'. And this is contrary to what a lot of people on this forum say... alas, i'm probably gonna start a holy war by saying this. :D
| quote: | | Hmm. Why do we need, for home audio, anything but 44.1KHz? Software in other formats is practically non-existent. So, give 44.1KHz "X-Tal lock" and leave things normal for the rest. |
Why do we need CD's? vinyl is just fine... :D ... oh wait! obsolescence!
The CD 20 years old, professional audio equipment has been 24/96 for years, and I've spoken to a studio engineer that said he feels "dirty" when he reduces his work down to 44.1/16. And DVD Audio players, computers, and much more consumer equipment is able to produce 24/96. 44.1 isn't going to be around for that much longer...
| quote: | | It doesnt need to work at more than one rate.... At the total max you need two, one for use with 32/48/64/96/192KHz sample rates and another for 44.1/88.2/176.4KHz sample rates. |
You're right.
| quote: | | Hmm, that surely is merely a design problem? |
It's a fundamental issue - if your DAC clock and your transport clock aren't in sync, then you're either filling or emptying your memory buffer. So either sync them up (and throw the buffer out entirely) or sit and wait while you dump a good part of a CD to your DAC's memory...
| quote: | Absolutely, but now we are back at single sample rate AND as non-standard interconnection requirements.
Sayonara |
Yes, and that's the only real solution to jitter. |
|
|
| Terry_Demol |
| quote: | Originally posted by Kuei Yang Wang
Konnichiwa,
Maybe, my ears so far have told me otherwise.
Sayonara |
What ASRC's have you evaluated and base this decision
on?
To be fair to ASRC's, anything before AD1896 is not worth
looking at. And it appears that the TI chip doesn't have a
sufficiently low jitter (artifact) rejection LPF corner freq.
The 1896 is around 2Hz or so.
I still haven't heard back from Cirrus (crystal) app eng's
WRT CS8421 LPF corner freq and I am assuming it is inferior to
the AD1896 (2Hz) as they don't state it in data sheet.
T |
|
|
| gmarsh |
| quote: | Originally posted by Terry_Demol
What ASRC's have you evaluated and base this decision
on?
To be fair to ASRC's, anything before AD1896 is not worth
looking at. And it appears that the TI chip doesn't have a
sufficiently low jitter (artifact) rejection LPF corner freq.
The 1896 is around 2Hz or so.
I still haven't heard back from Cirrus (crystal) app eng's
WRT CS8421 LPF corner freq and I am assuming it is inferior to
the AD1896 (2Hz) as they don't state it in data sheet.
T |
I'm still trying to score samples from TI, so I can test their jitter performance on the AP. But they won't send any my way... :(
The AD1895, which I use in a board at work, is surprisingly good for a cheap ASRC. |
|
|
| jwb |
God damn it. I cannot believe how this has devolved YET AGAIN into another flamefest about digital filtering.
THE ORIGINAL POST DID NOT ASK FOR YOUR OPINION ON FILTERING. ITS A SIMPLE QUESTION. IF YOU ARE UNABLE TO ANSWER IT PLEASE SHUT UP.
The TI chip is identical to the Analog chip, so you can look at both Analog's and TI's reference implementations for ideas. The basic thing is this: the ASRC has two serial ports and two clock domains. One serial port takes data from the DIR and the other one outputs data to the DACs or other circuit. You can run the ASRC with both ports as slaves, meaning that the DIR provides the clocks on the first serial port, and the downstream circuit provides the clocks on the second port. Or, you can let the ASRC be the master on the second port, generating the serial clocks from the master clock. Either way, the ASRC needs to be fed the master clock signal.
Personally I prefer to make both ports on the ASRC slaves. If you are uncertain about the options on the chip, just set everything for I2S, both ports slaves, master clock 256x Fs. You can easily work from there. |
|
|
| Kuei Yang Wang |
Konnichiwa,
| quote: | Originally posted by jwb
God damn it. I cannot believe how this has devolved YET AGAIN into another flamefest about digital filtering.
THE ORIGINAL POST DID NOT ASK FOR YOUR OPINION ON FILTERING. ITS A SIMPLE QUESTION. IF YOU ARE UNABLE TO ANSWER IT PLEASE SHUT UP. |
The poster who started the thread asked in the following post within this thread:
http://www.diyaudio.com/forums/show...9147#post439147
| quote: | Originally posted by MWP
So there is no improvment to be had by upsampling to 192khz before the DAC? |
Thus the issues of the objective and subjectovbe impact of the ASRC have been raised. No-one was talking about fdigital filters as such, only about them as part of the ASRC, which given post #11 in this thread is ON TOPIC.
IF YOU CANNOT PARTICIPATE IN A SENSIBLE DISCUSSION WITHOUT CHLIDISHLY THROWING YOUR TOYS OUT OF THE PRAM EVERYTIME SOMEONE MENTIONS THE WORD "DIGITAL" "FILTER" PLEASE SHUT UP.
Sayonara |
|
|
| Kuei Yang Wang |
Konnichiwa,
| quote: | Originally posted by gmarsh
I've listened to oversampled and non-oversampled DACs, I prefer the oversampled variety - i find that non-OS ones tend to attenuate the high end a bit, music loses a bit of 'bite'. |
Where the Non-os DAC's you heard fitted with the (IMHO neccesary) filter to offset the Sin(X)/(X) HF Rolloff (I have dubbed this filter "anti-sinc" FIlter)? If not you are hearing the result of > 3db attenuation at 20KHz, similar to Wadia & Pioneer Legato link, except more so.
| quote: | Originally posted by gmarsh
The CD 20 years old, professional audio equipment has been 24/96 for years, and I've spoken to a studio engineer that said he feels "dirty" when he reduces his work down to 44.1/16. And DVD Audio players, computers, and much more consumer equipment is able to produce 24/96. 44.1 isn't going to be around for that much longer... |
Yup, 44.1 is prettyt much a goner, the replacement is called 128kbps MP3. Hi_Rez is a non entity in commercial temrs and not wanted by the market music companies supply. So, 44.1 is likely the last "high quality" music format we are going to see commercially, plus many of the commercial (eg non-audiophile labels) Hi-Rez recordings are as bad as the ones they issue on CD and in most commercial recordings the sound quality is drastically below what 16/44.1 can deliver if exploited to the maximum. But now we are really off Topic.
| quote: | Originally posted by gmarsh
It's a fundamental issue - if your DAC clock and your transport clock aren't in sync, then you're either filling or emptying your memory buffer. So either sync them up (and throw the buffer out entirely) or sit and wait while you dump a good part of a CD to your DAC's memory... |
Or you use a digital PLL with sufficient hysteresis build in that the frequency changes VERY SLOWLY and use a very small buffer (smaller in fact than the buffer in the common ASRC's.... Lavery does it like that, interesting to read his whitepaper. Also interesting to read his experiences in testing ASRC's.
| quote: | Originally posted by Terry_Demol
What ASRC's have you evaluated and base this decision
on? |
In terms of Chips AD1890/91 & CS8420, in terms of equipment various pro ASRC (not sure what was inside) and the dCs Purcell ASRC (they call it upsampler). My conclusion in each case was that a direct feed without ASRC sounded different in most cases, adding the ASRC provided significant alterations in sound, in other word an "effect". I personally percieved the alterations as "degrading" the sound, making it less realsitic, but that is subjective.
I keep the position that if quality is of primary concern ASRC's are best avoided, as they significantly alter the signal, audibly so. Luckily enough most ASRC's have "bypass" pins so these are best made selectable, then anyone can try themselves.
Sayonara |
|
|
| gmarsh |
| quote: | Originally posted by rlim
I just found out from the headfi forum that the src4192 may not have the digital servo loop's low-pass set to a low enough frequency, thus defeating any jitter attenuation properties of the ASRC. Has anyone here heard of that? According to John Siau, director of engineering for Benchmark Media Systems Inc., the low-pass is set at 5KHz, way too high......
rlim |
Finally got this tidbit from TI today:
| quote: | The digital servo loop is equivalent to a 2nd order low pass filter with a cutoff frequency equal to 48Hz with a sampling frequency equal to 192kHz.
The cutoff frequency scales with sampling frequency per the following relationship:
Fco = 0.00025 * Fs
Jitter attenuation is directly related to this cutoff frequency and 2nd order response. |
It's not 5KHz, but it's still an order of magnitude higher than the AD1896. I think I'll stick with the AD part for now... |
|
|
|
