Standalone Bricks
One of the things that I like about the new design is the fact that some bricks could be used in a standalone fashion. For that purpose, we would build a very simple 1 × 1 OTO grid, which one could think of as a brick dock. For example, a simple stereo DAC brick would contain:
- A Sitara chip (in the bottom part)
- A small XMOS chip for the interface between the DAC and the Sitara
- A DAC chip like the AKM4497 or AKM4499
- Two balanced outputs
And mounted on a dock, it would give you a fully-functional DAC, with a powerful built-in DSP. This would create an entry-level setup for the OTO system. Dock excluded, it should measure 60mm × 60mm × 60mm, with the dock adding 15mm to 20mm in height.
If we cannot get access to early versions of the AKM4499 chip, we will start with the AKM4497, and get some inspiration from the SMSL M300 DAC. When you look at this picture and check the device's dimensions, you realize that we should have no problem fitting the whole DAC on a single 55mm × 50mm PCB, because we do not need the coaxial inputs and outputs, nor the optical input, buttons, display, and all the components driving them (especially the STC microcontroller used for the display).
Things will get a bit more tricky if we want this DAC to provide two discrete mono channels driven by two discrete AKM4499 chips. Then, we will need to stack two PCBs, and we won't be able to solder the XLR connectors directly on either of these PCBs, but we would not have been able to do that for the stereo DAC brick either anyway.
Therefore, the XLR connectors will have to be mounted on a separate PCB (what we called a "stick"), and I am starting to think that the output buffers should be mounted on these PCBs as well, alongside the connectors, or on a separate PCB mounted underneath. This latter scenario would give us the following stack:
1. Connectors PCB
2. Output Buffers PCB
3. Left Channel DAC PCB
4. Right Channel DAC PCB
5. Top-to-Bottom Interconnect PCB
6. Bottom-to-Top Interconnect PCB
7. System-on-Module PCB
8. Brick-to-Grid Interconnect PCB
9. Grid (aka Dock) PCB
This seems like a lot, but this is the price to pay for the level of modularity that we are trying to achieve. This example also shows that having two USB ports served by the bottom-to-top interconnect will be necessary. Since we also need a USB port for the brick-to-grid interconnect, and since all the MCs and SoCs that we want to use for the brick bottoms only provide a single USB 3.0 port, we will have to add a 3 or 4-port USB hub chip on the PCB that will host our System-on-Module (SoM).
For the latter, we have two options:
1. Mounting the SoM on the brick-to-grid interconnect PCB
2. Mounting the SoM on the Bottom-to-Top interconnect PCB
Option #2 is the preferred one, for the following reason: a SoM like the phyCORE-AM57x has the SoC on one side of the PCB and the connectors on the other. As a result, if we mount the SoM on the bottom-to-top interconnect PCB, the SoC will face downward, away from whatever is contained within the brick's top, and isolated from it by three PCBs (#5, #6, and #7), each with their own solid ground planes. As a result, this configuration should provide better shielding for the sensitive ADC and DAC components that are installed within the brick's top.
Now, we need to further specify all these interconnects, both in terms of electrical signals and mechanical connections.
One of the things that I like about the new design is the fact that some bricks could be used in a standalone fashion. For that purpose, we would build a very simple 1 × 1 OTO grid, which one could think of as a brick dock. For example, a simple stereo DAC brick would contain:
- A Sitara chip (in the bottom part)
- A small XMOS chip for the interface between the DAC and the Sitara
- A DAC chip like the AKM4497 or AKM4499
- Two balanced outputs
And mounted on a dock, it would give you a fully-functional DAC, with a powerful built-in DSP. This would create an entry-level setup for the OTO system. Dock excluded, it should measure 60mm × 60mm × 60mm, with the dock adding 15mm to 20mm in height.
If we cannot get access to early versions of the AKM4499 chip, we will start with the AKM4497, and get some inspiration from the SMSL M300 DAC. When you look at this picture and check the device's dimensions, you realize that we should have no problem fitting the whole DAC on a single 55mm × 50mm PCB, because we do not need the coaxial inputs and outputs, nor the optical input, buttons, display, and all the components driving them (especially the STC microcontroller used for the display).
Things will get a bit more tricky if we want this DAC to provide two discrete mono channels driven by two discrete AKM4499 chips. Then, we will need to stack two PCBs, and we won't be able to solder the XLR connectors directly on either of these PCBs, but we would not have been able to do that for the stereo DAC brick either anyway.
Therefore, the XLR connectors will have to be mounted on a separate PCB (what we called a "stick"), and I am starting to think that the output buffers should be mounted on these PCBs as well, alongside the connectors, or on a separate PCB mounted underneath. This latter scenario would give us the following stack:
1. Connectors PCB
2. Output Buffers PCB
3. Left Channel DAC PCB
4. Right Channel DAC PCB
5. Top-to-Bottom Interconnect PCB
6. Bottom-to-Top Interconnect PCB
7. System-on-Module PCB
8. Brick-to-Grid Interconnect PCB
9. Grid (aka Dock) PCB
This seems like a lot, but this is the price to pay for the level of modularity that we are trying to achieve. This example also shows that having two USB ports served by the bottom-to-top interconnect will be necessary. Since we also need a USB port for the brick-to-grid interconnect, and since all the MCs and SoCs that we want to use for the brick bottoms only provide a single USB 3.0 port, we will have to add a 3 or 4-port USB hub chip on the PCB that will host our System-on-Module (SoM).
For the latter, we have two options:
1. Mounting the SoM on the brick-to-grid interconnect PCB
2. Mounting the SoM on the Bottom-to-Top interconnect PCB
Option #2 is the preferred one, for the following reason: a SoM like the phyCORE-AM57x has the SoC on one side of the PCB and the connectors on the other. As a result, if we mount the SoM on the bottom-to-top interconnect PCB, the SoC will face downward, away from whatever is contained within the brick's top, and isolated from it by three PCBs (#5, #6, and #7), each with their own solid ground planes. As a result, this configuration should provide better shielding for the sensitive ADC and DAC components that are installed within the brick's top.
Now, we need to further specify all these interconnects, both in terms of electrical signals and mechanical connections.
Last edited:
Brick Size
With our new design, we might want to reconsider the size of a standard 1 × 1 brick. So far, we had settled on 60mm × 60mm, but the availability of a much more powerful SoC with lots of interfaces on every brick suggests that we might want to go for something slightly bigger.
Also, our original design relied on a Single-Board-Computer (SBC) to which we would attach a 5" touchscreen. But with our new design, the SBC is gone, and we need an alternative for the touchscreens. Of course, the cheapest and most powerful touchscreen that one can buy today is a fully-fledged Android phone like the Redmi Go, which retails for a ridiculously-low $65. This phone is 70.1mm wide. For its part, the larger iPhone XS Max is 77.4mm wide. Therefore, an 80mm × 80mm unit size should allow us to dock virtually any smartphone in portrait mode.
Using low-cost smartphones for the large displays of the control surface brings many benefits:
- Built-in controller (no control load on the SoC)
- Built-in battery (we want the whole setup to be battery-powered)
- Very high resolution (720 × 1280, 296ppi)
- Excellent human-machine interface (Android)
- Easy to upgrade or replace
With that in mind, a good way to dock these smartphones would be to create a 1 × 1 smartphone brick with a USB C docking connector and 12 encoders (4 columns × 3 rows). In a typical setup, a row of smartphone docks would stand behind the main control surface and in front of the Audio and CV ports. But because these ports will now be mounted vertically on the horizontal top surface of our bricks, they will be easier to access than if they were mounted horizontally on the vertical rear panel of the control surface, as is usually the case with many mixing consoles. Fortunately, the smartphones will stand vertically (at a slight angle) in front of the connectors, therefore hiding the plugs and cables from view, but the smartphones can easily be removed in order to provide easy access to all the cables. Of all the configurations that we have considered so far, this is the most attractive.
80mm × 80mm is also perfect for the Apple Magic Keyboard and Trackpad, which are 279mm × 115mm and 160mm × 115mm respectively. This means that they would take 4 × 2 and 2 × 2 units respectively, leading ample room (45mm) for two rows of encoders on the rear.
Most importantly, these larger dimensions should make it a lot easier to mount all the board-to-board connectors that we will need for the top and bottom parts of our bricks. And if we shoot for perfect 80mm cubes for solo bricks with their docks, it might give us enough vertical space to mount 4 ADC or DAC PCBs within a brick's top, thereby allowing us to provide four mono audio inputs or outputs on a single 1 × 1 brick, which would be awesome.
With our new design, we might want to reconsider the size of a standard 1 × 1 brick. So far, we had settled on 60mm × 60mm, but the availability of a much more powerful SoC with lots of interfaces on every brick suggests that we might want to go for something slightly bigger.
Also, our original design relied on a Single-Board-Computer (SBC) to which we would attach a 5" touchscreen. But with our new design, the SBC is gone, and we need an alternative for the touchscreens. Of course, the cheapest and most powerful touchscreen that one can buy today is a fully-fledged Android phone like the Redmi Go, which retails for a ridiculously-low $65. This phone is 70.1mm wide. For its part, the larger iPhone XS Max is 77.4mm wide. Therefore, an 80mm × 80mm unit size should allow us to dock virtually any smartphone in portrait mode.
Using low-cost smartphones for the large displays of the control surface brings many benefits:
- Built-in controller (no control load on the SoC)
- Built-in battery (we want the whole setup to be battery-powered)
- Very high resolution (720 × 1280, 296ppi)
- Excellent human-machine interface (Android)
- Easy to upgrade or replace
With that in mind, a good way to dock these smartphones would be to create a 1 × 1 smartphone brick with a USB C docking connector and 12 encoders (4 columns × 3 rows). In a typical setup, a row of smartphone docks would stand behind the main control surface and in front of the Audio and CV ports. But because these ports will now be mounted vertically on the horizontal top surface of our bricks, they will be easier to access than if they were mounted horizontally on the vertical rear panel of the control surface, as is usually the case with many mixing consoles. Fortunately, the smartphones will stand vertically (at a slight angle) in front of the connectors, therefore hiding the plugs and cables from view, but the smartphones can easily be removed in order to provide easy access to all the cables. Of all the configurations that we have considered so far, this is the most attractive.
80mm × 80mm is also perfect for the Apple Magic Keyboard and Trackpad, which are 279mm × 115mm and 160mm × 115mm respectively. This means that they would take 4 × 2 and 2 × 2 units respectively, leading ample room (45mm) for two rows of encoders on the rear.
Most importantly, these larger dimensions should make it a lot easier to mount all the board-to-board connectors that we will need for the top and bottom parts of our bricks. And if we shoot for perfect 80mm cubes for solo bricks with their docks, it might give us enough vertical space to mount 4 ADC or DAC PCBs within a brick's top, thereby allowing us to provide four mono audio inputs or outputs on a single 1 × 1 brick, which would be awesome.
Last edited:
Setup Revisited
Here is what the reference setup would look like with the new architecture. The surface is 16 × 10, or 1280mm × 800mm, and would contain up to 160 Sitara chips, for a total of 15,360,000 DMIPS.
The rear section of the surface includes 128 full-size XLR connectors, 64 for audio inputs and 64 for audio outputs. Standing at a slight angle in front of them are 16 smartphones, each mounted on a docking brick with 12 encoders.
The middle section is mostly made of OTO replicas of the Mutable Instruments modules, plus 48 Audio/CV ports and 16 MIDI ports on the left, and a LinnStrument 128-pad board on the right.
The front section has the usual 16 faders with stereo bargraphs, as well as the jog wheel, keyboard, and trackpad. But in front of these are 8 smartphones mounted flat on the surface. These are used to provide direct feedback for the 16 audio channels (mono or stereo) and the 64 encoders mounted on the back of the jog wheel, keyboard, and trackpad.
I am starting to really like it...
Here is what the reference setup would look like with the new architecture. The surface is 16 × 10, or 1280mm × 800mm, and would contain up to 160 Sitara chips, for a total of 15,360,000 DMIPS.
The rear section of the surface includes 128 full-size XLR connectors, 64 for audio inputs and 64 for audio outputs. Standing at a slight angle in front of them are 16 smartphones, each mounted on a docking brick with 12 encoders.
The middle section is mostly made of OTO replicas of the Mutable Instruments modules, plus 48 Audio/CV ports and 16 MIDI ports on the left, and a LinnStrument 128-pad board on the right.
The front section has the usual 16 faders with stereo bargraphs, as well as the jog wheel, keyboard, and trackpad. But in front of these are 8 smartphones mounted flat on the surface. These are used to provide direct feedback for the 16 audio channels (mono or stereo) and the 64 encoders mounted on the back of the jog wheel, keyboard, and trackpad.
I am starting to really like it...
Brick Powering
One of the challenges of the new architecture is that each brick might embed a complete SoM, which requires a specific power-up sequence. But because we do not want to add on/off switches to each and every brick (turning a 160-brick setup on would not be fun), we need a way to turn the bricks on automatically. This could be achieved using the circuit outlined on this excellent application note. As a sidenote, I should mention that I am finding the documentation provided by PHYTEC to be first class, which is quite encouraging.
One of the challenges of the new architecture is that each brick might embed a complete SoM, which requires a specific power-up sequence. But because we do not want to add on/off switches to each and every brick (turning a 160-brick setup on would not be fun), we need a way to turn the bricks on automatically. This could be achieved using the circuit outlined on this excellent application note. As a sidenote, I should mention that I am finding the documentation provided by PHYTEC to be first class, which is quite encouraging.
Moving Storage to the Edge
Much like we've moved processing to the edge by putting a full SoC within each and every brick, we should consider moving storage to the edge as well. To do so, we could mount an mSATA connector on our carrier board. This would allow us to put a storage device like the Samsung PM851 1TB into each and every brick, for a total of 160TB on our reference setup. Why mSATA instead of M.2 NVME? Because mSATA devices are much cheaper, and for audio applications, we really do not need the extra bandwidth: in the most extreme scenario, a 1 × 1 OTO brick will provide 16 × TA5 connectors, for a total of 32 audio inputs. With a 32-bit signal at 1.536MHz, this would require just under 1.6Gbps of bandwidth (32 × 32-bit × 1.536MHz). Therefore, the 6Gbps of bandwidth offered by mSATA will be plenty enough.
Much like we've moved processing to the edge by putting a full SoC within each and every brick, we should consider moving storage to the edge as well. To do so, we could mount an mSATA connector on our carrier board. This would allow us to put a storage device like the Samsung PM851 1TB into each and every brick, for a total of 160TB on our reference setup. Why mSATA instead of M.2 NVME? Because mSATA devices are much cheaper, and for audio applications, we really do not need the extra bandwidth: in the most extreme scenario, a 1 × 1 OTO brick will provide 16 × TA5 connectors, for a total of 32 audio inputs. With a 32-bit signal at 1.536MHz, this would require just under 1.6Gbps of bandwidth (32 × 32-bit × 1.536MHz). Therefore, the 6Gbps of bandwidth offered by mSATA will be plenty enough.
I wasn't trying to say that it was the same thing as a USB audio endpoint running in async mode. Why do you keep misunderstand and convoluting the points I'm trying to make. The point being that jitter on the bit-clock, LR clock and data line are important to the end performance of the DAC.
To me master mode is you provide a master clock, via a low jitter master oscillator, to a specific chip, in this case say the Xilinx DSP.
The Xilinx chip then generates the LR clock, bit clock and new master clock at a specific rate, say 256fs/512fs.
Those clocks are then used to supply every other device on the board. All the other devices are configured as slaves and are slaved to the Xilinx master.
A device acting as a master requires only a master clock and then generates everything else.
A device acting as a slave requires the master clock, LR clock and bit clock to operate. A DAC additionally has the data line provided and an ADC produces it.
That's what the difference between master and slave is to me.
I did not realise the XMOS/CMedia chips could be configured to operate like this.
Well I've already mentioned it above I believe. Nothing wrong with it, but realistically it should only simplify sending data from the USB device to the DSP as these are the only multichannel parts (yes the ADC is an 8 channel part and the DAC 4 channel, but they are all going to be used in mono mode right?).
Sure you can daisy chain the data line from ADC to ADC or DAC to DAC but that's still a trace to each DAC/ADC for the data line. Depending on the board layout and the way the DSP is to be used, plus whether or not there are enough I/O pins on the DSP (there should be it's got a bazillion pins), it could either be simpler to use TDM from the DSP to the other devices, or simple I2S.
Of course you'll need to pay attention to the maximum data rate allowed for TDM. I didn't think you could do 8x 192/24 down a single line?
USB Topology
For the past couple of days, I have been working on the USB topology of our reference setup. Because of its size and the goal of keeping USB 3.x throughout, it's actually quite a bit harder than anticipated, but I think we're onto something.
Here is an outline of the constraints that we are trying to deal with:
- 20 grids of 2 × 4 OTO units
- 160 × OTO units in total (each with a Sitara SoM)
- USB 3.1 SuperSpeed to each and every OTO unit
- Single USB-C interface to host DAW
- Shallow USB hub hierarchy
- USB-C cables for connecting grids to each others
- USB 4 future-proofing
Right from the start, we had to deal with the fact that all OTO units cannot be connected to the same USB bus, which is limited to 127 devices. Furthermore, this limit is actually much lower when considering compound devices and the fact that our host DAW will have quite a few USB devices on its own.
Therefore, we've decided to go for a five-tier architecture, by embedding a System-on-Module (SoM) within each grid, and by creating 5 clusters of 4 grids:
1 DAW (not part of the reference setup)
1 Master Grid (connected to the DAW)
1+4 Primary Slaves (the Master acts as a Primary Slave)
1+3 Secondary Slave per Primary Slave (a Primary Slave acts as Secondary Slave)
8 Bricks per Secondary Slave (8 Bricks per Grid)
The SoM embedded within each grid will be the same phyCORE-AM57x SoM used for top-of-the-line bricks, just so that we can get some leverage out of our R&D efforts. These SoMs will be used to mix the audio signals produced by the bricks of their respective grids. From there, the SoMs embedded within primary slave grids will also be used to mix the signals produced by secondary slave grids. Finally, the master grid's SoM will be used to mix the signals produced by primary slave grids, before everything is sent to the DAW.
Following careful analysis of all the USB hub chips offered by Cypress, Microchip, and TI, we've concluded that we should use the Cypress EZ-USB HX3PD, because it is the only one that can give us 3 USB-C downstream ports.
Unfortunately, this USB hub chip won't be sufficient, because the phyCORE-AM57x SoM gives us a single USB 3.0 port. Therefore, we will need to add a couple more USB ports to our SoM, by using the Cypress EZ-PD CCG4M. This will allow us to provide everything needed by the master grid's SoM, and therefore everything needed by the SoMs of our primary slaves and secondary slaves.
Thanks to the EZ-PD CCG4M, each SoM will have 3 multi-role USB 3.x ports. From there, we will attach an EZ-USB HX3PD hub to each of them. This chip is a bit complex and can provide 7 downstream USB ports, but only 3 of them can be of the USB-C type, and only 5 of them can be of the 3.0 SuperSpeed kind.
With that in mind, we will use our 3 USB 3.x ports in the following fashion:
Port #1
- 1 upstream USB-C port connected to the host DAW
- 2 downstream USB-C ports connected to primary slaves
Port #2
- 3 downstream USB-C ports connected to primary slaves (2 would be sufficient)
Port #3
- 3 downstream USB-C ports connected to secondary slaves
- 2 downstream USB 3.0 ports connected to two EZ-USB HX3PD chips
From there, these two EZ-USB HX3PD chips will be used to connect to the grid's 8 OTO bricks using USB 3.0 ports.
With such a topology, a brick will be 3 hubs away from the DAW.
For the past couple of days, I have been working on the USB topology of our reference setup. Because of its size and the goal of keeping USB 3.x throughout, it's actually quite a bit harder than anticipated, but I think we're onto something.
Here is an outline of the constraints that we are trying to deal with:
- 20 grids of 2 × 4 OTO units
- 160 × OTO units in total (each with a Sitara SoM)
- USB 3.1 SuperSpeed to each and every OTO unit
- Single USB-C interface to host DAW
- Shallow USB hub hierarchy
- USB-C cables for connecting grids to each others
- USB 4 future-proofing
Right from the start, we had to deal with the fact that all OTO units cannot be connected to the same USB bus, which is limited to 127 devices. Furthermore, this limit is actually much lower when considering compound devices and the fact that our host DAW will have quite a few USB devices on its own.
Therefore, we've decided to go for a five-tier architecture, by embedding a System-on-Module (SoM) within each grid, and by creating 5 clusters of 4 grids:
1 DAW (not part of the reference setup)
1 Master Grid (connected to the DAW)
1+4 Primary Slaves (the Master acts as a Primary Slave)
1+3 Secondary Slave per Primary Slave (a Primary Slave acts as Secondary Slave)
8 Bricks per Secondary Slave (8 Bricks per Grid)
The SoM embedded within each grid will be the same phyCORE-AM57x SoM used for top-of-the-line bricks, just so that we can get some leverage out of our R&D efforts. These SoMs will be used to mix the audio signals produced by the bricks of their respective grids. From there, the SoMs embedded within primary slave grids will also be used to mix the signals produced by secondary slave grids. Finally, the master grid's SoM will be used to mix the signals produced by primary slave grids, before everything is sent to the DAW.
Following careful analysis of all the USB hub chips offered by Cypress, Microchip, and TI, we've concluded that we should use the Cypress EZ-USB HX3PD, because it is the only one that can give us 3 USB-C downstream ports.
Unfortunately, this USB hub chip won't be sufficient, because the phyCORE-AM57x SoM gives us a single USB 3.0 port. Therefore, we will need to add a couple more USB ports to our SoM, by using the Cypress EZ-PD CCG4M. This will allow us to provide everything needed by the master grid's SoM, and therefore everything needed by the SoMs of our primary slaves and secondary slaves.
Thanks to the EZ-PD CCG4M, each SoM will have 3 multi-role USB 3.x ports. From there, we will attach an EZ-USB HX3PD hub to each of them. This chip is a bit complex and can provide 7 downstream USB ports, but only 3 of them can be of the USB-C type, and only 5 of them can be of the 3.0 SuperSpeed kind.
With that in mind, we will use our 3 USB 3.x ports in the following fashion:
Port #1
- 1 upstream USB-C port connected to the host DAW
- 2 downstream USB-C ports connected to primary slaves
Port #2
- 3 downstream USB-C ports connected to primary slaves (2 would be sufficient)
Port #3
- 3 downstream USB-C ports connected to secondary slaves
- 2 downstream USB 3.0 ports connected to two EZ-USB HX3PD chips
From there, these two EZ-USB HX3PD chips will be used to connect to the grid's 8 OTO bricks using USB 3.0 ports.
With such a topology, a brick will be 3 hubs away from the DAW.
Edit - it seems like there is a slave mode setting for the ADC/DAC input/output blocks on the CMedia part but I wonder how it works. Does the device auto detect the incoming sampling frequency and then fix the rate it's operating at in the operating system? Or do you select the sampling frequency/bit depth in the operating system and then have the hardware switch clocks to match.
I just looked at the google document for this. I thought this was going to be an 8 channel out 8 channel in thing, but it looks like that's only 1/8th of it and that the final product will be 64x in and out?
Yes indeed, the project has evolved quite a bit. The main goal is to develop a modular platform for sound synthesis, recording, processing, mastering, and rendering. This is crazy ambitious, but the core components that we have to develop are actually much simpler than originally anticipated. By using this modular OTO architecture, the main audio components that we have to create are:
- A single-channel mono audio ADC based on the AK5578EN
- A single-channel mono audio DAC based on the AK4499EQ
Each of these two components will have:
- one PCB for the ADC or DAC chip and a small XMOS chip (70mm × 70mm)
- one PCB for the XLR connector and its buffer (70mm × 35mm)
- one PCB for the power supply (70mm × 35mm)
The first version of the DAC might be based on the AK4497 if we cannot get access to the AK4499EQ chip.
This will allow us to create 1 x 1 OTO "reference" bricks that have either two mono audio inputs or two mono audio outputs. From there, we will create the 4-input and 4-output bricks shown on the reference setup by simply cramming more PCBs within (possibly taller) bricks.
DAC Brick
Now that the new architecture had some time to settle down, we're getting ready to work on the ADC and DAC bricks. We will start with the DAC, because it is the one that seems to be generating the most interest. The current outline for this board is this:
- Single mono audio channel
- NZ2520SDA 45.1584 MHz oscillator
- NZ2520SDA 49.152 MHz oscillator
- XUF216-512-TQ128 XMOS interface
- AK4499EQ ADC
- OPA1612 operational amplifiers
- USB Audio 2.0 port
- USB-C Power Delivery port
- XLR output connector
- 8-layer ADC PCB
- 4-layer XMOS PCB
- 4-layer LDO PCBs
This article has some interesting info about the AK4499EQ.
The XMOS PCB will be inspired by this DIYINHK board.
Note: the OPA1612 might be replaced by the RT6862D if we manage to source it.
Now that the new architecture had some time to settle down, we're getting ready to work on the ADC and DAC bricks. We will start with the DAC, because it is the one that seems to be generating the most interest. The current outline for this board is this:
- Single mono audio channel
- NZ2520SDA 45.1584 MHz oscillator
- NZ2520SDA 49.152 MHz oscillator
- XUF216-512-TQ128 XMOS interface
- AK4499EQ ADC
- OPA1612 operational amplifiers
- USB Audio 2.0 port
- USB-C Power Delivery port
- XLR output connector
- 8-layer ADC PCB
- 4-layer XMOS PCB
- 4-layer LDO PCBs
This article has some interesting info about the AK4499EQ.
The XMOS PCB will be inspired by this DIYINHK board.
Note: the OPA1612 might be replaced by the RT6862D if we manage to source it.
Last edited:
For most purposes AK4499EQ needs 22/24MHz clocks. 45/49 is only needed for the highest sample rate PCM and is incompatible with DSD. Running the clocks though a low-jitter divider most of the time might permit use of 45/49MHz clocks, if 768kHz PCM is really important to have.
AK4499 also needs fairly sophisticated Reference Voltage power supplies, similar to Jung-Didden. One supply for each channel.
You really need to see the evaluation board schematic before starting on that part of the project.
Note: Before replacing OPA1612 with RT6862D, better to make sure it is a wise idea. ToneBoard is not my idea of a model Sabre design, except a very cheap one. Others may disagree.
Last edited:
That's a tough one... Not sure which way to go.
Indeed... Still waiting on that one.
I totally agree. This should be tried before committing to it. It should be a relatively easy experiment though. And the Khadas Tone Board is not a very advanced DAC indeed, but the OpAmps seem to have made a huge difference, so I got really curious about them.
Thanks a lot for your help, much appreciated.
What does only play, the new minidsp multichannel I/O streamer would be the better choice...
Hp
MCHStreamer - USB Audio Swiss-Army knife
but without master clock feeding, what has to be done by yourself
Hp
MCHStreamer - USB Audio Swiss-Army knife
but without master clock feeding, what has to be done by yourself
Hp
Got it! Thanks. What do you particularly like about it?
Board Stacking and XLR Connectors
Our DAC brick will include multiple PCBs, and one of the challenges is to decide which components go on which PCB. Looking at the Wee DAC, it seems possible to put the operational amplifiers on the XLR output board, but I have always assumed that it is probably better to put them as close to the DAC chip as possible. If that is the case, what can be done to preserve the output signal between the operational amplifiers mounted on the DAC board and the XLR connector(s) mounted on another board?
Our DAC brick will include multiple PCBs, and one of the challenges is to decide which components go on which PCB. Looking at the Wee DAC, it seems possible to put the operational amplifiers on the XLR output board, but I have always assumed that it is probably better to put them as close to the DAC chip as possible. If that is the case, what can be done to preserve the output signal between the operational amplifiers mounted on the DAC board and the XLR connector(s) mounted on another board?
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.