Hi,
Having a few days off over the Xmas holidays I thought I’d try my hand at a fresh ESS9018 design rather than going the easy route and buying the TP or Acko solutions. Although there is a lot of ESS9018 discussion on this forum, there are basically only the two designs easily available to the DIY crowd. There is nothing wrong with the Acko or TP DACs but I want to “roll my own” as I want to build a solution that focuses on my design goals and I wanted to use this as both a learning exercise but also to use my audio electronics skills acquired over the years (I don’t consider myself an expert – my expertise & comfort is mostly on the digital electronics & software side, not analog).
I’ll use this thread to document the summary of my learning, implementation decisions (and reasons) as well as seek input and feedback from this community. Building a DAC like this is a complex topic so I’ll break the various aspects of design/implementation into separate posts. I’d also like to thank the various folks who have been posting about the ESS solutions over the last 3 years as a lot of what I have picked up has been from reading the various threads on this forum & others (although at times the S/N ratio on some threads is questionable!). Hopefully by the time the thread is finished it should hold a summary of the main design & implementation discussions and decisions so should be useful to others.
OK, to start off, like any good project, it needs the boundaries defined through a series of high level design goals. These are:
1) The DAC will be PC connected, to a HTPC which is the music & video source. The main reason for wanting such a high quality DAC is to support my growing collection of blu-ray music which is a mix of 48Khz and 96Khz, 16 and 24 bit. Blu-ray audio has a bright future IMO as it is now a mainstream media format with high storage capacity, uses lossless codecs and if mastered well (as a lot of concerts are - less processing!), the source audio quality is very good. I also have a large collection of ripped Redbook material, catalogued.
2) Multi-channel 5.1 (7.1 option) as my current home theatre is kitted out with a 5.1 speaker setup (Dunlavy speakers). Although not relevant to the design, I will be mating this amp with a set of the new Hypex NCore Class D amp modules.
3) Connection is by High Speed USB async (interrupt transfer mode – guaranteed packet delivery and latency) supporting up to 14 channels (only 6 will be implemented) and at sample rates of up to 192Khz. I know there is the option of DSD audio but I don’t have any material, and unlikely to buy any, and don’t really see any advantage in DSD over PCM so it won’t be supported (although its theoretically possible to implement without too many changes). The USB bits are pretty complex and I’ll open another thread on that (see Koon’s thread about 24 channel USB to I2S interface for a discussion between the both of us on this topic). It might be interesting to know that I’ll implement the PC side as a virtual soundcard which will also have hook to insert mixers, delay, processing etc. based on the excellent BASS audio libraries. The USB bits will be completely isolated from the DAC and it will be designed such that the PC or software used won’t make a difference to the audio quality (ie. No need for special PC power supplies or “pure” software….)
4) DAC control like volume and even the ESS registry settings will be via the PC over the USB connection (effectively playing the role of a home theatre receiver). So stuff like onscreen display, remote volume etc. will all be handled in software on the PC end.
5) Differential outputs per channel feeding Hypex NCore modules in the amplifier.
6) The quality level I’m aiming for is to make a significant improvement over my existing multi-channel Lynx 2B soundcard, which is no slouch and has served well for several years now. So I’m looking for a high end ESS design/implementation but not “extreme” or “ultimate”.
7) Keep the cost to about $1000, without having the price sacrifice the quality. As I am looking at multiple ESS9018 chips, a TP or AckoDAC solution especially with decent regulators adds up in price pretty quickly, so this design will be more integrated (and less flexible) to keep costs down. For example, the entire USB subsystem with functionality similar to the EXA solution will cost $10. Of course if time is money the cost will be many times higher, but this DIY after all….
8) Even though I hope to finish off with a leading edge DAC solution, I have no intention of starting a kit or product business. I will be making the PCB’s from scratch (I have a good source for PCBs) and I may have some left over if others want to implement something similar, but note this design is not going to be as flexible as the Acko or TP solution and there won’t be any formal support.
I’m certainly looking for your feedback as I document thoughts in this thread around the implementation decisions, and I’ll try to summarize what I have learnt from the forum and the datasheets to help others. Please keep any feedback on topic and in good spirit.
Over the next day or so I’ll start posting the design & implementation options & decisions (ESS9018 settings). Thanks in advance for your input!
Having a few days off over the Xmas holidays I thought I’d try my hand at a fresh ESS9018 design rather than going the easy route and buying the TP or Acko solutions. Although there is a lot of ESS9018 discussion on this forum, there are basically only the two designs easily available to the DIY crowd. There is nothing wrong with the Acko or TP DACs but I want to “roll my own” as I want to build a solution that focuses on my design goals and I wanted to use this as both a learning exercise but also to use my audio electronics skills acquired over the years (I don’t consider myself an expert – my expertise & comfort is mostly on the digital electronics & software side, not analog).
I’ll use this thread to document the summary of my learning, implementation decisions (and reasons) as well as seek input and feedback from this community. Building a DAC like this is a complex topic so I’ll break the various aspects of design/implementation into separate posts. I’d also like to thank the various folks who have been posting about the ESS solutions over the last 3 years as a lot of what I have picked up has been from reading the various threads on this forum & others (although at times the S/N ratio on some threads is questionable!). Hopefully by the time the thread is finished it should hold a summary of the main design & implementation discussions and decisions so should be useful to others.
OK, to start off, like any good project, it needs the boundaries defined through a series of high level design goals. These are:
1) The DAC will be PC connected, to a HTPC which is the music & video source. The main reason for wanting such a high quality DAC is to support my growing collection of blu-ray music which is a mix of 48Khz and 96Khz, 16 and 24 bit. Blu-ray audio has a bright future IMO as it is now a mainstream media format with high storage capacity, uses lossless codecs and if mastered well (as a lot of concerts are - less processing!), the source audio quality is very good. I also have a large collection of ripped Redbook material, catalogued.
2) Multi-channel 5.1 (7.1 option) as my current home theatre is kitted out with a 5.1 speaker setup (Dunlavy speakers). Although not relevant to the design, I will be mating this amp with a set of the new Hypex NCore Class D amp modules.
3) Connection is by High Speed USB async (interrupt transfer mode – guaranteed packet delivery and latency) supporting up to 14 channels (only 6 will be implemented) and at sample rates of up to 192Khz. I know there is the option of DSD audio but I don’t have any material, and unlikely to buy any, and don’t really see any advantage in DSD over PCM so it won’t be supported (although its theoretically possible to implement without too many changes). The USB bits are pretty complex and I’ll open another thread on that (see Koon’s thread about 24 channel USB to I2S interface for a discussion between the both of us on this topic). It might be interesting to know that I’ll implement the PC side as a virtual soundcard which will also have hook to insert mixers, delay, processing etc. based on the excellent BASS audio libraries. The USB bits will be completely isolated from the DAC and it will be designed such that the PC or software used won’t make a difference to the audio quality (ie. No need for special PC power supplies or “pure” software….)
4) DAC control like volume and even the ESS registry settings will be via the PC over the USB connection (effectively playing the role of a home theatre receiver). So stuff like onscreen display, remote volume etc. will all be handled in software on the PC end.
5) Differential outputs per channel feeding Hypex NCore modules in the amplifier.
6) The quality level I’m aiming for is to make a significant improvement over my existing multi-channel Lynx 2B soundcard, which is no slouch and has served well for several years now. So I’m looking for a high end ESS design/implementation but not “extreme” or “ultimate”.
7) Keep the cost to about $1000, without having the price sacrifice the quality. As I am looking at multiple ESS9018 chips, a TP or AckoDAC solution especially with decent regulators adds up in price pretty quickly, so this design will be more integrated (and less flexible) to keep costs down. For example, the entire USB subsystem with functionality similar to the EXA solution will cost $10. Of course if time is money the cost will be many times higher, but this DIY after all….
8) Even though I hope to finish off with a leading edge DAC solution, I have no intention of starting a kit or product business. I will be making the PCB’s from scratch (I have a good source for PCBs) and I may have some left over if others want to implement something similar, but note this design is not going to be as flexible as the Acko or TP solution and there won’t be any formal support.
I’m certainly looking for your feedback as I document thoughts in this thread around the implementation decisions, and I’ll try to summarize what I have learnt from the forum and the datasheets to help others. Please keep any feedback on topic and in good spirit.
Over the next day or so I’ll start posting the design & implementation options & decisions (ESS9018 settings). Thanks in advance for your input!
Last edited:
so let me get this straight, your USB/control interface will allow the hosting of VST/AU plugins for XO duties? since you are building a more integrated/less flexible setup, i'm going to suggest that you forget async and use, or at least provide the option to use the usb clocking as master with the dac in NOS mode, this requires careful layout, but you have the opportunity here to do better than what async offers.
The USB driver will support plugins for VST (via the BASS audio library), mostly to provide a delay for home theater setup purposes. These will be settable in the driver control panel. The driver will be used for another project (SPDIF AC3 input decoder) so will have additional functionality as well.
Definitely will try to use synchronous mode and avoid resampling, however its not as well documented and as I'm working through the ESS datasheet there are a number of questions about sync mode that aren't well explained and will need help from others here more familiar with ESS solutions. For example, using OSF bypass (which I assume is the switch for synchronous) it requires the I2S data be fed in at 8*Fs, however its not clear if you need to upsample externally or the chip will do that for you. Also not clear is the DPLL bandwidth settings to use in synchronous mode.
My biggest concern is the clocks, and how to get a clean clock signal off the DAC into the USB module. I may require special coax connectors between boards.
Also the choice of I/V and regulators is almost mind boggling. I'm still working through the pros and cons of each topology (eg. local shunts on each power pin with a shared high quality supply, or a full blown low noise reg for each pin, IV with a opamp or discrete etc.).
Definitely will try to use synchronous mode and avoid resampling, however its not as well documented and as I'm working through the ESS datasheet there are a number of questions about sync mode that aren't well explained and will need help from others here more familiar with ESS solutions. For example, using OSF bypass (which I assume is the switch for synchronous) it requires the I2S data be fed in at 8*Fs, however its not clear if you need to upsample externally or the chip will do that for you. Also not clear is the DPLL bandwidth settings to use in synchronous mode.
My biggest concern is the clocks, and how to get a clean clock signal off the DAC into the USB module. I may require special coax connectors between boards.
Also the choice of I/V and regulators is almost mind boggling. I'm still working through the pros and cons of each topology (eg. local shunts on each power pin with a shared high quality supply, or a full blown low noise reg for each pin, IV with a opamp or discrete etc.).
ahh ok, well that rules me out, i'm running mac and id prefer to stick to UAC2, it sure would be nice to have DSP and dac topologies linked with the one interface. i'm kinda stuck due to my usb interface being UAC2, which is a bit ironic. i can run win in parallels or natively to use allocator, but then i dont have access to the usb audio hardware. so i'm stuck with expensive AU studio crossover plugins, or the integrated XO in puremusic, which is nice and all, but its no allocator.
externally, switch off the oversampling filter and you dont have oversampling =) re. DPLL, as low as you can before you start getting dropouts. there is a fair bit of related info on best DPLL settings vs sampling in the SD memory card transport thread and posts by Bunpei will help out here. how low you can go will depend largely on quality of layout and quality of the clocks. so you should look at oversampling in whatever DSP you are using for the USB->i2s and then dedicated clocks for 22.1x and 24x plus a dedicated clock for the DSP/USB provided your usb implementation allows that to be done at the RX end (as far as USB is concerned).
I thought i saw reference to a suitable XO rate <100MHz that would divide 22 and 24x integers and thus rule out the need for switching, but cant for the life of me remember what it was. yes you will need to provide suitable high speed connectors and really the ones acko is using the w.fl or u.fl are the most suitable.
how are you planning on isolating USB ground? could you not have everything all on the one multilayer board, but with different ground planes and have MCLK on a little battery powered island? not sure how good LVDS would be for MCLK as far as jitter, but thats one possibility
re power supply. 2 power supplies, one for analogue pins/processes and one for digital pins/processes. so AVCC L/R, CLOCK, VDD L/R (reference) on one high quality supply with dedicated regulators so they all share a common ground point back on the PSU and the others can be just standard reasonable quality chip regs, there is no need to have shunts on all the pins, IMO thats just for marketing purposes. they shouldnt be bad or have a dirty switching ground or something, but no need to go crazy on them. the IV should have its own dedicated supply also, were you thinking opamps here?
i'll let others chime in with specific details, as although i've built a number of sabre dacs and have some experience, i dont have any experience of the level of integration you are talking about. ive only recently started to play around with the shell/USB link my ackodacs.
have you seen that separate ESS document on the inner workings of the sabre chip posted in the widget thread? if not let me know i'll dig up a link
externally, switch off the oversampling filter and you dont have oversampling =) re. DPLL, as low as you can before you start getting dropouts. there is a fair bit of related info on best DPLL settings vs sampling in the SD memory card transport thread and posts by Bunpei will help out here. how low you can go will depend largely on quality of layout and quality of the clocks. so you should look at oversampling in whatever DSP you are using for the USB->i2s and then dedicated clocks for 22.1x and 24x plus a dedicated clock for the DSP/USB provided your usb implementation allows that to be done at the RX end (as far as USB is concerned).
I thought i saw reference to a suitable XO rate <100MHz that would divide 22 and 24x integers and thus rule out the need for switching, but cant for the life of me remember what it was. yes you will need to provide suitable high speed connectors and really the ones acko is using the w.fl or u.fl are the most suitable.
how are you planning on isolating USB ground? could you not have everything all on the one multilayer board, but with different ground planes and have MCLK on a little battery powered island? not sure how good LVDS would be for MCLK as far as jitter, but thats one possibility
re power supply. 2 power supplies, one for analogue pins/processes and one for digital pins/processes. so AVCC L/R, CLOCK, VDD L/R (reference) on one high quality supply with dedicated regulators so they all share a common ground point back on the PSU and the others can be just standard reasonable quality chip regs, there is no need to have shunts on all the pins, IMO thats just for marketing purposes. they shouldnt be bad or have a dirty switching ground or something, but no need to go crazy on them. the IV should have its own dedicated supply also, were you thinking opamps here?
i'll let others chime in with specific details, as although i've built a number of sabre dacs and have some experience, i dont have any experience of the level of integration you are talking about. ive only recently started to play around with the shell/USB link my ackodacs.
have you seen that separate ESS document on the inner workings of the sabre chip posted in the widget thread? if not let me know i'll dig up a link
Last edited:
Hi qusp,
Thanks for the informative posts, quite a few good tips! I assume you posted while watching the boxing day test (I'm relaxing on holidays in Bali at the moment...)
Unfortunately the path I'm taking on the USB side will only be useful for Windows, although if Cypress have equivalent Mac drivers you are welcome to the code to do something similar on the Mac side. I'd prefer UAC2 as well but that isn't going to happen easily or quickly on Windows and as the Cypress drivers do all the heavy lifting on the USB side, my driver code can concentrate on the bits relevant to the DAC and not the USB plumbing.
Regarding sync vs async on the ESS9018, is that controlled by the Jitter_Reduction setting which switches in/out the ASRC.
But the OSF_Bypass still has me a bit stumped and I can't find answers in the various threads (I may have missed it, there is a *lot* of posts to get thru). Are there any benefits in bypassing the oversampling filter when running in synchronous mode (is it even applicable)? In order to use OSF_Bypass, I2S needs to be fed in at 8*Fs and it seems from the datasheet that you have to upsample externally. With the USB scheme I want use this will cause extra complexity so I would prefer to feed the DAC with native sample rate if possible. If the FIR filter is not being used, and there is no de-emphasis, then if you leave the FIR filter & deemphasis circuits in place the end result should be the same as using OSF_Bypass?
With synchronous mode, will the internal volume control still work?
I see on earlier posts you have used microBNC connectors, which look great for routing high frequency signals between boards (eg. clock and I2S). Where do you get these from?
Regarding a common clock for 44.1Khz and 48Khz, I haven't heard of a common rate evenly divisable but with a high enough clock rate I suppose its possible. I assume you would need to get a specific crystal cut for that though?
For USB isolation, I will use a set of isolators on the I2S & clock lines, and on the DAC I intend using flipflops to reclock the lines to remove any jitter from the isolators (using the low jitter parts from Potato Semiconductor / The GHz TTL/ CMOS IO Interface Logic/ Potato IC). The WCLK line is the most susceptical to jitter, the other lines not so much but will probably reclock them all.
Re: power supplies, I'm still digging into the best approach, and it would be good to know which of the open source regulators (eg. Salas) work best on the ESS chips?
Definitely would like a link to the inner workings of the sabre chips, the datasheet for such a complex device is pretty spartan.
Thanks for the informative posts, quite a few good tips! I assume you posted while watching the boxing day test (I'm relaxing on holidays in Bali at the moment...)
Unfortunately the path I'm taking on the USB side will only be useful for Windows, although if Cypress have equivalent Mac drivers you are welcome to the code to do something similar on the Mac side. I'd prefer UAC2 as well but that isn't going to happen easily or quickly on Windows and as the Cypress drivers do all the heavy lifting on the USB side, my driver code can concentrate on the bits relevant to the DAC and not the USB plumbing.
Regarding sync vs async on the ESS9018, is that controlled by the Jitter_Reduction setting which switches in/out the ASRC.
But the OSF_Bypass still has me a bit stumped and I can't find answers in the various threads (I may have missed it, there is a *lot* of posts to get thru). Are there any benefits in bypassing the oversampling filter when running in synchronous mode (is it even applicable)? In order to use OSF_Bypass, I2S needs to be fed in at 8*Fs and it seems from the datasheet that you have to upsample externally. With the USB scheme I want use this will cause extra complexity so I would prefer to feed the DAC with native sample rate if possible. If the FIR filter is not being used, and there is no de-emphasis, then if you leave the FIR filter & deemphasis circuits in place the end result should be the same as using OSF_Bypass?
With synchronous mode, will the internal volume control still work?
I see on earlier posts you have used microBNC connectors, which look great for routing high frequency signals between boards (eg. clock and I2S). Where do you get these from?
Regarding a common clock for 44.1Khz and 48Khz, I haven't heard of a common rate evenly divisable but with a high enough clock rate I suppose its possible. I assume you would need to get a specific crystal cut for that though?
For USB isolation, I will use a set of isolators on the I2S & clock lines, and on the DAC I intend using flipflops to reclock the lines to remove any jitter from the isolators (using the low jitter parts from Potato Semiconductor / The GHz TTL/ CMOS IO Interface Logic/ Potato IC). The WCLK line is the most susceptical to jitter, the other lines not so much but will probably reclock them all.
Re: power supplies, I'm still digging into the best approach, and it would be good to know which of the open source regulators (eg. Salas) work best on the ESS chips?
Definitely would like a link to the inner workings of the sabre chips, the datasheet for such a complex device is pretty spartan.
I have a different understanding on in/out switching for ASRC.
No register setting is assigned for switching ASRC.
As long as you employs an external independent master clock oscillator, ASRC is always and natively on. My interpretation of "Jitter Reduction On/Off" is "On/Off of the (patent-protected) proprietary value correction function".
On the other hand, only when an external master clock which is synchronous to I2S or DSD signals is injected, the chip becomes "sync".
OK, so to confirm, if MCLK and the bitclock are the same, the chip runs in sync?
This means I have to run the chip at 48*Fs (24 bits = 2.1168 MHz). So I suppose all the talk about having the MCLK as high as possible (>80MHz) is not relevant for synchronous mode as the ASRC is bypassed.
Can someone confirm my understanding of OSF_Bypass in synchronous mode? If I'm running the master clock in sync with the I2S bitrate, then the OSF_bypass (upsampling) can't be switched off but as long as I'm not using de-emphasis or the FIR filter the impact of the upsampling should be minor.
Does the volume control work in sync mode even if the I2S data is 24 bit not 32 bit so that volume is applied with 32 bits to preserve the native signal dynamic range (I assume the data is converted to 32 bits internally - again the datasheet is not specific)
This means I have to run the chip at 48*Fs (24 bits = 2.1168 MHz). So I suppose all the talk about having the MCLK as high as possible (>80MHz) is not relevant for synchronous mode as the ASRC is bypassed.
Can someone confirm my understanding of OSF_Bypass in synchronous mode? If I'm running the master clock in sync with the I2S bitrate, then the OSF_bypass (upsampling) can't be switched off but as long as I'm not using de-emphasis or the FIR filter the impact of the upsampling should be minor.
Does the volume control work in sync mode even if the I2S data is 24 bit not 32 bit so that volume is applied with 32 bits to preserve the native signal dynamic range (I assume the data is converted to 32 bits internally - again the datasheet is not specific)
Hi guys,
In order to complete the USB side of this new design, I need confirmation of a couple of points when running the ESS in synchronous mode. It looks like very few folks have tried this configuration so I'm a little nervous about doing any groundbreaking work in this area....
Because of the need to run 8*Fs with OSF_Bypass enabled, does that mean that the chip cannot run in sync mode with OSF_Bypass enabled (sync = 48*Fs for I2S 24 bit)? So sync mode will always have to have the oversampling circuits enabled (even though you don't need to use the FIR filter or de-emphasis)?
I believe the ESS chip internally uses a 32 bit data path, so if you feed it 24 bit data it will convert to 32 bit?
I have constraints on my async USB solution that won't allow much post processing of the I2S so I need answers about the 2 points above before I can move on with the design. I have re-read the threads again but can't find the answers to the above.
Thanks for your help!
In order to complete the USB side of this new design, I need confirmation of a couple of points when running the ESS in synchronous mode. It looks like very few folks have tried this configuration so I'm a little nervous about doing any groundbreaking work in this area....
Because of the need to run 8*Fs with OSF_Bypass enabled, does that mean that the chip cannot run in sync mode with OSF_Bypass enabled (sync = 48*Fs for I2S 24 bit)? So sync mode will always have to have the oversampling circuits enabled (even though you don't need to use the FIR filter or de-emphasis)?
I believe the ESS chip internally uses a 32 bit data path, so if you feed it 24 bit data it will convert to 32 bit?
I have constraints on my async USB solution that won't allow much post processing of the I2S so I need answers about the 2 points above before I can move on with the design. I have re-read the threads again but can't find the answers to the above.
Thanks for your help!
Bunpei-san,
I have been re-reading your posts in the SD Transport thread. Can you confirm that the ESS9018 can be in sync mode if you use the same clock as the source even if the clock frequency is a derivative of the master (eg. bit clock = 2.1168Mhz for 24bit 44.1Khz and ESS9018 MCLK = 67.7376Mhz, bit clock * 32)?
I have been re-reading your posts in the SD Transport thread. Can you confirm that the ESS9018 can be in sync mode if you use the same clock as the source even if the clock frequency is a derivative of the master (eg. bit clock = 2.1168Mhz for 24bit 44.1Khz and ESS9018 MCLK = 67.7376Mhz, bit clock * 32)?
I think I have answered my question about 32 or 24 bit I2S input. From the datasheet DATA_CLOCK must be 64*Fs, so the I2S word length must be 64 (2 x 32 bit channels) with the unused bits packed with 0.
Bunpei-san,
I have been re-reading your posts in the SD Transport thread. Can you confirm that the ESS9018 can be in sync mode if you use the same clock as the source even if the clock frequency is a derivative of the master (eg. bit clock = 2.8224Mhz for 32bit 44.1Khz and ESS9018 MCLK = 90.3168Mhz, bit clock * 32)? What I don't understand is that after using a hardware divider there will be a delay that means the master clock will be out of sync with the (undivided) master? You could add some delay to the master to compensate, but it won't be exact. I suppose the importance is the jitter on the clock, not a constant delay between the master and derived clocks.
I see from Justin's earlier post http://www.diyaudio.com/forums/digital-line-level/117238-ess-sabre-reference-dac-8-channel-50.html#post1490639 that you should turn off the Jitter correction when running a master clock phase aligned with the source clock, which will bypass the jitter correction mechanism.
Happy New Year!
Bunpei-san,
I have been re-reading your posts in the SD Transport thread. Can you confirm that the ESS9018 can be in sync mode if you use the same clock as the source even if the clock frequency is a derivative of the master (eg. bit clock = 2.8224Mhz for 32bit 44.1Khz and ESS9018 MCLK = 90.3168Mhz, bit clock * 32)? What I don't understand is that after using a hardware divider there will be a delay that means the master clock will be out of sync with the (undivided) master? You could add some delay to the master to compensate, but it won't be exact. I suppose the importance is the jitter on the clock, not a constant delay between the master and derived clocks.
I see from Justin's earlier post http://www.diyaudio.com/forums/digital-line-level/117238-ess-sabre-reference-dac-8-channel-50.html#post1490639 that you should turn off the Jitter correction when running a master clock phase aligned with the source clock, which will bypass the jitter correction mechanism.
Happy New Year!
Last edited:
Hi, deandob,
Based on the descriptions in the datasheet;
BCLK is 64 * Fs and
Serial Normal Mode 100MHz > MCLK > 192 * Fs ( 3 * BCLK)
Serial OSF Bypass Mode > MCLK > 24 *Fs ( 0.5 * BCLK)
I have experiences on synchronous MCLK frequencies;
44.1 kHz series: 11.2896, 22.5792, 45.1584 and 90.3168 MHz
48 kHz series: 24.576, 98.304 MHz
Even on 11.2896 MHz, OSF=ON is feasible for 44.1 kHz audio sources.
Bunpei
Based on the descriptions in the datasheet;
BCLK is 64 * Fs and
Serial Normal Mode 100MHz > MCLK > 192 * Fs ( 3 * BCLK)
Serial OSF Bypass Mode > MCLK > 24 *Fs ( 0.5 * BCLK)
I have experiences on synchronous MCLK frequencies;
44.1 kHz series: 11.2896, 22.5792, 45.1584 and 90.3168 MHz
48 kHz series: 24.576, 98.304 MHz
Even on 11.2896 MHz, OSF=ON is feasible for 44.1 kHz audio sources.
Bunpei
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.