Dual Fader Brick
Because the first system that I am designing around this new Eurobrick modular architecture is primarily a mixing console, the most important brick will be the B10D1F2 dual fader module. It will have the following features:
- 2 × 100mm Bourns PSM motorized faders with touch sense
- 2 × 64mm dual 64-segments RGB bargraphs
- 10 × illuminated buttons
- 1 × 1.91" 536 × 240 AMOLED display
- 1 × 3 Eurobrick footprint (60mm × 180mm)
In other words, this brick will provide everything for controlling two stereo channels, even though it might be used for mono channels as well (in this case, only one side of the dual bargraphs will be illuminated).
Each stereo channel will have its own:
- Eurobrick grid connector
- ATmega328 microcontroller
- Control PCB (for dual bargraphs, 5 buttons, and fader)
The AMOLED display will be shared across both stereo channels and will have its own Eurobrick grid connector and its own dedicated microcontroller (not sure whether an ATmega328 will suffice for that application, but we can figure that out later).
The reason for having 5 buttons is to emulate what the Rupert Neve SwiftMix module of the legendary 5088 high voltage and discrete mixer is doing. These buttons are:
- SELECT
- MUTE
- SOLO
- REC
- MODE
Because this brick is highly space-constrained, the bargraphs cannot run across the full 100mm of travel of the motorized faders (and doing so might have been confusing anyway). Instead, they will use only 64mm (1mm per LED), leaving about 90mm for the five buttons. The MODE button will be located below the bargraph, while the other four buttons will be located above it, right below the AMOLED display, which itself will be placed at the top of the brick, above the two faders.
The AMOLED display will be mounted on top of the faders' motors, which means that the faders will be mounted in such a way that the motors stand at the top of the brick. The brick's cover will have to provide proper bezels for keeping everything in place...
The design is also quite constrained width-wise, because the faders are 14mm wide. In order to provide enough width for the two channel PCBs, the brick will have 2mm-thick walls on the longitudinal side, and these walls will only widen where mounting screws are installed (for the cover and for the grid). This means that the channel PCBs cannot be larger than 14mm. With the 8mm wide VQFN (56) TLC5954 LED drivers (4 per mono channel, 8 on a PCB, 16 in total within the brick), it will be a tight fit, but it should work.
The Bourns PSM motorized fader was selected against several alternatives from Alps and Penny+Giles (owned by Curtiss-Wright) for the following reasons:
- Very narrow width (14mm)
- Touch Sense Track
- Extra long life (1,000,000 cycles)
- Reasonable cost ($22.52 when buying 250 of them)
As a point of comparison, some cheaper alternatives only last about 30,000 cycles, and 100,000 cycles are considered "long life" by most manufacturers. Also, sets of 5 low-cost Behringer motorized faders usually retail for about $100. And a top-of-the-line (but much bigger) PGFM9000 will set you back $60 when buying 100 of them...
The Touch Sense Track feature is really nice: it allows the system to know when a fader is touched by the user, even if the fader is not actually moved. Some rotary encoders support this feature as well, and we're currently trying to find an illuminated one that supports it. It is not clear that we could find suitable illuminated buttons that do, and it is very unlikely that we will find micro rotary encoders that do either, but we will try to make sure that every standard brick has at least one control element that does. This will allow us to "activate" the brick on touch, thereby displaying all its information on the 5" touchscreen to which it is related.
The philosophy of this design is to provide dedicated hardware controls for everything that should have one (5 buttons per audio channel for example), but to share everything that could or should be shared. For example, on an analog mixing console like the Rupert Neve 5088, every channel has a dedicated controller with 2 large buttons, 21 small ones, and 10 encoders. Across a 16 or 24 channel setup, that's a lot of duplicated controls.
Instead, my setup will share all these controls for all channels via a set of three bricks called "Channel". The user will therefore use his/her left hand to adjust a channel's level with its fader, use the same hand to select it by clicking on the SELECT button, then use the right hand to adjust its parameters through the Channel module. But having the faders motorized will make it possible to easily switch through 8 "pages" of 16 mono channels, thereby getting access to the 64 mono input and 64 mono output channels that will be offered by an 8-grid setup (as shown on the reference design).
In order to support all this, the different controls and ports will have the following features:
# Buttons
- Push
- RGB Illumination
- Touch Sense (hopefully)
# Encoders
- Encoding
- Push
- RGB Illumination
- Touch Sense
# 3.5mm Ports
- RGB Illumination (through a separate LED)
- Touch Sense (hopefully)
All these requirements (and a few others) are outlined on this sheet. This means that some complex bricks will require some kind of multiplexing for the ATmega328 to properly handle all this, or a more advanced microcontroller will have to be used. That being said, we will stick to the megaAVR family of microcontrollers in order to simplify developments.
Because the first system that I am designing around this new Eurobrick modular architecture is primarily a mixing console, the most important brick will be the B10D1F2 dual fader module. It will have the following features:
- 2 × 100mm Bourns PSM motorized faders with touch sense
- 2 × 64mm dual 64-segments RGB bargraphs
- 10 × illuminated buttons
- 1 × 1.91" 536 × 240 AMOLED display
- 1 × 3 Eurobrick footprint (60mm × 180mm)
In other words, this brick will provide everything for controlling two stereo channels, even though it might be used for mono channels as well (in this case, only one side of the dual bargraphs will be illuminated).
Each stereo channel will have its own:
- Eurobrick grid connector
- ATmega328 microcontroller
- Control PCB (for dual bargraphs, 5 buttons, and fader)
The AMOLED display will be shared across both stereo channels and will have its own Eurobrick grid connector and its own dedicated microcontroller (not sure whether an ATmega328 will suffice for that application, but we can figure that out later).
The reason for having 5 buttons is to emulate what the Rupert Neve SwiftMix module of the legendary 5088 high voltage and discrete mixer is doing. These buttons are:
- SELECT
- MUTE
- SOLO
- REC
- MODE
Because this brick is highly space-constrained, the bargraphs cannot run across the full 100mm of travel of the motorized faders (and doing so might have been confusing anyway). Instead, they will use only 64mm (1mm per LED), leaving about 90mm for the five buttons. The MODE button will be located below the bargraph, while the other four buttons will be located above it, right below the AMOLED display, which itself will be placed at the top of the brick, above the two faders.
The AMOLED display will be mounted on top of the faders' motors, which means that the faders will be mounted in such a way that the motors stand at the top of the brick. The brick's cover will have to provide proper bezels for keeping everything in place...
The design is also quite constrained width-wise, because the faders are 14mm wide. In order to provide enough width for the two channel PCBs, the brick will have 2mm-thick walls on the longitudinal side, and these walls will only widen where mounting screws are installed (for the cover and for the grid). This means that the channel PCBs cannot be larger than 14mm. With the 8mm wide VQFN (56) TLC5954 LED drivers (4 per mono channel, 8 on a PCB, 16 in total within the brick), it will be a tight fit, but it should work.
The Bourns PSM motorized fader was selected against several alternatives from Alps and Penny+Giles (owned by Curtiss-Wright) for the following reasons:
- Very narrow width (14mm)
- Touch Sense Track
- Extra long life (1,000,000 cycles)
- Reasonable cost ($22.52 when buying 250 of them)
As a point of comparison, some cheaper alternatives only last about 30,000 cycles, and 100,000 cycles are considered "long life" by most manufacturers. Also, sets of 5 low-cost Behringer motorized faders usually retail for about $100. And a top-of-the-line (but much bigger) PGFM9000 will set you back $60 when buying 100 of them...
The Touch Sense Track feature is really nice: it allows the system to know when a fader is touched by the user, even if the fader is not actually moved. Some rotary encoders support this feature as well, and we're currently trying to find an illuminated one that supports it. It is not clear that we could find suitable illuminated buttons that do, and it is very unlikely that we will find micro rotary encoders that do either, but we will try to make sure that every standard brick has at least one control element that does. This will allow us to "activate" the brick on touch, thereby displaying all its information on the 5" touchscreen to which it is related.
The philosophy of this design is to provide dedicated hardware controls for everything that should have one (5 buttons per audio channel for example), but to share everything that could or should be shared. For example, on an analog mixing console like the Rupert Neve 5088, every channel has a dedicated controller with 2 large buttons, 21 small ones, and 10 encoders. Across a 16 or 24 channel setup, that's a lot of duplicated controls.
Instead, my setup will share all these controls for all channels via a set of three bricks called "Channel". The user will therefore use his/her left hand to adjust a channel's level with its fader, use the same hand to select it by clicking on the SELECT button, then use the right hand to adjust its parameters through the Channel module. But having the faders motorized will make it possible to easily switch through 8 "pages" of 16 mono channels, thereby getting access to the 64 mono input and 64 mono output channels that will be offered by an 8-grid setup (as shown on the reference design).
In order to support all this, the different controls and ports will have the following features:
# Buttons
- Push
- RGB Illumination
- Touch Sense (hopefully)
# Encoders
- Encoding
- Push
- RGB Illumination
- Touch Sense
# 3.5mm Ports
- RGB Illumination (through a separate LED)
- Touch Sense (hopefully)
All these requirements (and a few others) are outlined on this sheet. This means that some complex bricks will require some kind of multiplexing for the ATmega328 to properly handle all this, or a more advanced microcontroller will have to be used. That being said, we will stick to the megaAVR family of microcontrollers in order to simplify developments.
Last edited:
Who will be writing the DSP? For many of the functions this device might have, it would seem to be competing with hardware VST and VSTI plugin processors, kind of with the user control interface integrated into modules rather than using separate MIDI-based devices for that. UAD has had a pretty successful business model, for one example, but its success largely seems to be based on the quality of the plugins written by a Stanford PhD.
Also, emulating the sound of classic hardware devices has proven to be tricky. Many musicians and recording engineers have developed skill at listening for subtle nuances of sound quality. Over the years DSP modeling of instruments and recording gear has improved, but the models can use up a lot of DSP resources very quickly if they are very high quality.
Also, emulating the sound of classic hardware devices has proven to be tricky. Many musicians and recording engineers have developed skill at listening for subtle nuances of sound quality. Over the years DSP modeling of instruments and recording gear has improved, but the models can use up a lot of DSP resources very quickly if they are very high quality.
Excellent points!
I will try to write some of it myself, but it will be a steep learning curve. I'm a fast learner though...
And anyone is free to participate. The entire project (hardware + software) is open source.
Yes, good emulation requires large amounts of DSP power, and this is precisely why I want to use these powerful (and expensive) Xilinx SoCs. I really doubt that any audio processing could max out the largest Xilinx SoCs though, but I would love to be proven wrong, because it would make the design much less overkill than it seems right now... In other words, it's a game where we win either way...
Also, I live in Palo Alto, and many of my friends are Stanford PhDs. So, if I can pull off the hardware side of the project, I'm not too worried about finding the right people to write the DSP code. And if we start doing that with deep learning, there is no shortage of PhD students who will want to take a crack at it. But one thing at a time: hardware first!
I will try to write some of it myself, but it will be a steep learning curve. I'm a fast learner though...
And anyone is free to participate. The entire project (hardware + software) is open source.
Yes, good emulation requires large amounts of DSP power, and this is precisely why I want to use these powerful (and expensive) Xilinx SoCs. I really doubt that any audio processing could max out the largest Xilinx SoCs though, but I would love to be proven wrong, because it would make the design much less overkill than it seems right now... In other words, it's a game where we win either way...
Also, I live in Palo Alto, and many of my friends are Stanford PhDs. So, if I can pull off the hardware side of the project, I'm not too worried about finding the right people to write the DSP code. And if we start doing that with deep learning, there is no shortage of PhD students who will want to take a crack at it. But one thing at a time: hardware first!
Last edited:
What is this system for?
What we are designing here is a mix between an audio interface, a mixing console, and a modular synthesizer. Some might wonder why we're combining all these into a single device. Wouldn't it be better to focus on a single thing instead? Well, this is a fair question, and I would like to offer two complementary answers:
First, the main purpose of the project is to design and build a showcase application for this new Eurobrick standard that was introduced in this thread. This standard is useful not just for modular synthesizers, but for any kind of control surface, and not just for audio processing, but for any kind of data processing (one could build a really cool control surface for Photoshop for example). Therefore, we like to believe that showcasing this new format through a system that is both an audio interface, a mixing console, and a modular synthesizer is actually pretty cool.
Second, while the Eurobrick standard is not limited to audio processing, one of its key features (hybrid ports) is specifically designed for it, and can only be showcased when combining audio interfacing, patching, and synthesis.
As a refresher, the purpose of hybrid ports is to bridge the gap between the analog and digital domains when patching audio and CV (Control Voltage) inputs and outputs by using physical 3.5mm jacks. When using a Eurorack modular synthesizer, these mono jacks carry actual audio or CV signals. But with a Eurobrick system, stereo jacks are used instead, and carry either:
- The actual CV signal on one channel and its signature on the other
- Just the signature of an audio channel
Therefore, the synthesis, mixing, and controlling components need to be tightly integrated together. Of course, all this could be done by cobbling together existing components, but this would come at a significant cost, and it would lead to the development of a very large system that would not be portable. Instead, we want our system to be relatively small (960mm × 480mm × 100mm), portable (can be broken down into 8 pieces and can be powered by battery), and affordable (an 8 + 8 grid should have a BoM below $2,000, while this fully-loaded 64 + 64 setup with the biggest FPGAs and 20K+ DSP slices should retail for less than $50K).
Finally, this project is first and foremost designed as a learning tool for me. By training, I am a software engineer, but what I really like is to learn new things. For example, I recently spent two months in a community college in order to learn how to use a mill and a lathe (both manual and CNC). And while I am far from being able to design my own analog circuits, I am starting to develop some familiarity with their digital counterparts (as long as we don't step into high-frequency realms).
So, if this project does not seem to make sense from a practical or commercial standpoint, it's probably because it does not, but that is beside the point. Instead, the goal is to design the most over-the-top showcase for a new form factor that hopefully will find many applications for much more practical use cases. And all along the way, I should be able to satisfy my thirst for learning.
Last note: the project is called OTO (音), which means "sound" in Japanese.
I just *love* the fact that both romanji and kanji writings are so symmetrical!
What we are designing here is a mix between an audio interface, a mixing console, and a modular synthesizer. Some might wonder why we're combining all these into a single device. Wouldn't it be better to focus on a single thing instead? Well, this is a fair question, and I would like to offer two complementary answers:
First, the main purpose of the project is to design and build a showcase application for this new Eurobrick standard that was introduced in this thread. This standard is useful not just for modular synthesizers, but for any kind of control surface, and not just for audio processing, but for any kind of data processing (one could build a really cool control surface for Photoshop for example). Therefore, we like to believe that showcasing this new format through a system that is both an audio interface, a mixing console, and a modular synthesizer is actually pretty cool.
Second, while the Eurobrick standard is not limited to audio processing, one of its key features (hybrid ports) is specifically designed for it, and can only be showcased when combining audio interfacing, patching, and synthesis.
As a refresher, the purpose of hybrid ports is to bridge the gap between the analog and digital domains when patching audio and CV (Control Voltage) inputs and outputs by using physical 3.5mm jacks. When using a Eurorack modular synthesizer, these mono jacks carry actual audio or CV signals. But with a Eurobrick system, stereo jacks are used instead, and carry either:
- The actual CV signal on one channel and its signature on the other
- Just the signature of an audio channel
Therefore, the synthesis, mixing, and controlling components need to be tightly integrated together. Of course, all this could be done by cobbling together existing components, but this would come at a significant cost, and it would lead to the development of a very large system that would not be portable. Instead, we want our system to be relatively small (960mm × 480mm × 100mm), portable (can be broken down into 8 pieces and can be powered by battery), and affordable (an 8 + 8 grid should have a BoM below $2,000, while this fully-loaded 64 + 64 setup with the biggest FPGAs and 20K+ DSP slices should retail for less than $50K).
Finally, this project is first and foremost designed as a learning tool for me. By training, I am a software engineer, but what I really like is to learn new things. For example, I recently spent two months in a community college in order to learn how to use a mill and a lathe (both manual and CNC). And while I am far from being able to design my own analog circuits, I am starting to develop some familiarity with their digital counterparts (as long as we don't step into high-frequency realms).
So, if this project does not seem to make sense from a practical or commercial standpoint, it's probably because it does not, but that is beside the point. Instead, the goal is to design the most over-the-top showcase for a new form factor that hopefully will find many applications for much more practical use cases. And all along the way, I should be able to satisfy my thirst for learning.
Last note: the project is called OTO (音), which means "sound" in Japanese.
I just *love* the fact that both romanji and kanji writings are so symmetrical!
None of that explained why those SoCs are so expensive. I get that you think they can do lots of things but I'm looking at this from the point of view of "it's a silicon chip" no different from other silicon chips. Why is it so expensive?
Some have a very high failure rate, some require expensive precision laser trimming. Some go through batches of extreme testing to ensure stability of performance at the top and bottom of their recommended operating conditions.
To me this just looks like a big case of charge a fortune just because you can. Or am I missing something?
Some have a very high failure rate, some require expensive precision laser trimming. Some go through batches of extreme testing to ensure stability of performance at the top and bottom of their recommended operating conditions.
To me this just looks like a big case of charge a fortune just because you can. Or am I missing something?
Oh, I see... sorry for the confusion.
I think you're right: this is basic market economics. Relatively low demand from high-end customers who really need that stuff and have a lot of money to pay for it (telco, aerospace, military), served by relatively low supply controlled by two main vendors (Xilinx and Altera, now owned by Intel).
I have no particular intelligence regarding yield, but I must assume that it is relatively low, in part because of the relatively large number of SKUs and the high level of integration. Also, the R&D costs must be astronomical. For example, when Xilinx developed its latest Vivado software suite, thousands of engineers were involved... In fact, knowing that, I am surprised that these chips are not *more* expensive...
With that in mind, I really hope that Intel does not drop the ball on Altera, because if they do, we'll end up with a single-source market, which will make matters even worse. But I am confident that Xilinx will do the right thing, because they must in order to survive against the upcoming onslaught of cheap RISC V massively parallel processors: there, you're looking at 10,000 64-bit floating point cores in a single 30W chip, making all these DSPs seem very slow in comparison.
Unfortunately, none of the vendors working on these (that I know of) are adding the I/Os that are really needed to take advantage of this insane amount of computing power for real-time signal processing. Instead, they all come from an enterprise IT background, and I/O is something they tend to leave to the networking vendors. This is where Xilinx still has a card to play. I'm just not sure for how long though... And I would not discount NVIDIA either, especially now that they own Mellanox (the Infiniband guys): having a ton of GPU cores directly connected to an Infiniband fabric could do wonders for many applications. Unfortunately, these cannot be used for audio processing, because they do not do anything special to reduce jitter, and latency is totally unpredictable.
I think you're right: this is basic market economics. Relatively low demand from high-end customers who really need that stuff and have a lot of money to pay for it (telco, aerospace, military), served by relatively low supply controlled by two main vendors (Xilinx and Altera, now owned by Intel).
I have no particular intelligence regarding yield, but I must assume that it is relatively low, in part because of the relatively large number of SKUs and the high level of integration. Also, the R&D costs must be astronomical. For example, when Xilinx developed its latest Vivado software suite, thousands of engineers were involved... In fact, knowing that, I am surprised that these chips are not *more* expensive...
With that in mind, I really hope that Intel does not drop the ball on Altera, because if they do, we'll end up with a single-source market, which will make matters even worse. But I am confident that Xilinx will do the right thing, because they must in order to survive against the upcoming onslaught of cheap RISC V massively parallel processors: there, you're looking at 10,000 64-bit floating point cores in a single 30W chip, making all these DSPs seem very slow in comparison.
Unfortunately, none of the vendors working on these (that I know of) are adding the I/Os that are really needed to take advantage of this insane amount of computing power for real-time signal processing. Instead, they all come from an enterprise IT background, and I/O is something they tend to leave to the networking vendors. This is where Xilinx still has a card to play. I'm just not sure for how long though... And I would not discount NVIDIA either, especially now that they own Mellanox (the Infiniband guys): having a ton of GPU cores directly connected to an Infiniband fabric could do wonders for many applications. Unfortunately, these cannot be used for audio processing, because they do not do anything special to reduce jitter, and latency is totally unpredictable.
Design Principles
A critical design element of the OTO platform is its relatively-simple hub-and-spoke architecture, coupled with a clean separation-of-concerns. These two concepts (hub-and-spoke and separation-of-concerns) deserve some explanations.
Separation-of-Concerns
Let's start with the second one, because we'll need it to explain the first one. As explained in this earlier post (under the less appropriate "separation of duty" terminology), audio processing and control processing will be handled by two totally-separate subsystems:
- Audio processing will be handled by the ADC, DAC, and SoM boards
- Control processing will be handled by the Single-Board-Computer
This strict separation of concern will allow the system to provide deterministic latency for signal processing, while keeping the development of the user interface relatively simple (developing a real-time user interface is no walk in the park).
Hub-and-Spoke Architecture
Both subsystems (audio and control) have their own hub-and-spoke architectures, instead of relying on a more scalable but more complex network architecture.
Starting with the control subsystem, the main idea is that one of the single board computers (SBC, a Khadas Edge for now) will act as master and will be connected to up to seven similarly-configured slaves through seven USB 3.0 ports. This simple architecture will remove the need for a Gigabit Ethernet switch, while increasing bandwidth (each USB 3.0 port is capable of delivering 5Gbps, but not all of them at the same time, because everything will go through a single 5Gbps port on the master side through a 7-port USB hub).
While each SBC will be responsible for controlling up to 12 OTO bricks (through 12 USB 3.0 ports), the full state of the system will be centralized by the master SBC. The latter will run a local HTTP server which will be used to serve this information back to all slave SBCs. That way, the development of custom user interfaces displayed through the 5" touchscreens attached to each and every SBC should be greatly simplified (if you know how to build a web app, you should be able to build a custom UI component for the system, using your favorite web stack).
While this architecture won't easily scale to more than 8 or 16 grids (128 + 128 audio channels!) because of the limitations of the USB protocol, it should not be a more problem for most users (obviously). And the relatively high bandwidth and low latency offered by the USB protocol should be plenty enough for the control signals that it needs to carry, keeping in mind that no audio signals will flow through it at that level.
For its part, the audio subsystem will share a similar architecture, with the FPGA of one System-on-Module (SoM) acting as master for the mixing of multiple audio channels. This FPGA will be directly connected to up to 8 ADC boards and up to 8 DAC boards over USB. When a lot of audio channels are needed, up to 8 grids will be used (64 inputs + 64 outputs), but if these channels do not require a lot of processing, a single low-cost SoM could be used (starting at around $200 for 240 DSP Slices). Of course, if more power is needed, a simple upgrade will consist in using a more powerful SoM (going up to $1,700 for 3,528 DSP Slices). And if even more DSP power is needed, more SoMs could be added, with a total of 8 of them (with the initial USB topology, with plans for 16 in a second revision).
When adding more SoMs, these will be used to offload filters and effects from the master SoM to the slave SoMs, having the latter directly connected to their respective ADC and DAC boards. With that hub-and-spoke topology, the master SoM will be used for the mixing of audio signals, while the slave SoMs will be used for the filters and effects applied to the individual audio inputs and outputs. The latter will also be handled by the XMOS chips found on each ADC and DAC boards. For reference purposes, these are the most powerful chips currently offered by XMOS, with 2,000 MIPS of compute power on each and every chip. That being said, we won't spend a lot of time trying to make our filters and effects run on the XMOS chips, because the DSPs of the FPGAs will be much more efficient at this. Instead, we will use the XMOS chips mostly as a USB Audio glue and as an easy way to provide support for protocols like S/PDIF and ADAT.
Once again, this hub-and-spoke architecture won't scale beyond 8 or 16 grids, but there is very little need for it. Beyond that, we will defer to external systems, taking advantage of the 2 AVB Gigabit Ethernet ports and the 2 Dante Gigabit Ethernet ports offered by each grid module, thereby giving us a total of 16 + 16 Gigabit Ethernet ports with support for both protocols across an 8-grid setup (twice as much with the planned 16-grid version).
A critical design element of the OTO platform is its relatively-simple hub-and-spoke architecture, coupled with a clean separation-of-concerns. These two concepts (hub-and-spoke and separation-of-concerns) deserve some explanations.
Separation-of-Concerns
Let's start with the second one, because we'll need it to explain the first one. As explained in this earlier post (under the less appropriate "separation of duty" terminology), audio processing and control processing will be handled by two totally-separate subsystems:
- Audio processing will be handled by the ADC, DAC, and SoM boards
- Control processing will be handled by the Single-Board-Computer
This strict separation of concern will allow the system to provide deterministic latency for signal processing, while keeping the development of the user interface relatively simple (developing a real-time user interface is no walk in the park).
Hub-and-Spoke Architecture
Both subsystems (audio and control) have their own hub-and-spoke architectures, instead of relying on a more scalable but more complex network architecture.
Starting with the control subsystem, the main idea is that one of the single board computers (SBC, a Khadas Edge for now) will act as master and will be connected to up to seven similarly-configured slaves through seven USB 3.0 ports. This simple architecture will remove the need for a Gigabit Ethernet switch, while increasing bandwidth (each USB 3.0 port is capable of delivering 5Gbps, but not all of them at the same time, because everything will go through a single 5Gbps port on the master side through a 7-port USB hub).
While each SBC will be responsible for controlling up to 12 OTO bricks (through 12 USB 3.0 ports), the full state of the system will be centralized by the master SBC. The latter will run a local HTTP server which will be used to serve this information back to all slave SBCs. That way, the development of custom user interfaces displayed through the 5" touchscreens attached to each and every SBC should be greatly simplified (if you know how to build a web app, you should be able to build a custom UI component for the system, using your favorite web stack).
While this architecture won't easily scale to more than 8 or 16 grids (128 + 128 audio channels!) because of the limitations of the USB protocol, it should not be a more problem for most users (obviously). And the relatively high bandwidth and low latency offered by the USB protocol should be plenty enough for the control signals that it needs to carry, keeping in mind that no audio signals will flow through it at that level.
For its part, the audio subsystem will share a similar architecture, with the FPGA of one System-on-Module (SoM) acting as master for the mixing of multiple audio channels. This FPGA will be directly connected to up to 8 ADC boards and up to 8 DAC boards over USB. When a lot of audio channels are needed, up to 8 grids will be used (64 inputs + 64 outputs), but if these channels do not require a lot of processing, a single low-cost SoM could be used (starting at around $200 for 240 DSP Slices). Of course, if more power is needed, a simple upgrade will consist in using a more powerful SoM (going up to $1,700 for 3,528 DSP Slices). And if even more DSP power is needed, more SoMs could be added, with a total of 8 of them (with the initial USB topology, with plans for 16 in a second revision).
When adding more SoMs, these will be used to offload filters and effects from the master SoM to the slave SoMs, having the latter directly connected to their respective ADC and DAC boards. With that hub-and-spoke topology, the master SoM will be used for the mixing of audio signals, while the slave SoMs will be used for the filters and effects applied to the individual audio inputs and outputs. The latter will also be handled by the XMOS chips found on each ADC and DAC boards. For reference purposes, these are the most powerful chips currently offered by XMOS, with 2,000 MIPS of compute power on each and every chip. That being said, we won't spend a lot of time trying to make our filters and effects run on the XMOS chips, because the DSPs of the FPGAs will be much more efficient at this. Instead, we will use the XMOS chips mostly as a USB Audio glue and as an easy way to provide support for protocols like S/PDIF and ADAT.
Once again, this hub-and-spoke architecture won't scale beyond 8 or 16 grids, but there is very little need for it. Beyond that, we will defer to external systems, taking advantage of the 2 AVB Gigabit Ethernet ports and the 2 Dante Gigabit Ethernet ports offered by each grid module, thereby giving us a total of 16 + 16 Gigabit Ethernet ports with support for both protocols across an 8-grid setup (twice as much with the planned 16-grid version).
Submodular Architecture
While looking for the right encoders and 3.5mm stereo jacks, we've realized that we could further factorize our standard bricks. Indeed, 12 of the most popular bricks could be built out of just 5 submodules:
- 2 large encoders (E2)
- 3 large encoders (E3)
- 4 small encoders (E4)
- 3 ports (E3)
- 4 ports (E4)
This gave us the idea that such bricks should be assembled from these submodules, with one PCB per submodule. Some PCBs would be parallel to the brick's cover (encoders), while others would be perpendicular (ports). Doing so would reduce the number of SKUs from 12 down to 5, and would make it a lot easier for anyone to create custom bricks by simply machining a custom cover.
With that in mind, we've selected the following components:
- EC09E1524417 small encoder
- PEL12T large encoder
- STX-3150-3N-1 stereo jack
- SSF-LXH5147LGD LED circuit board indicator
The 4-LED circuit board indicator will be used to indicate the port's type:
1. Audio Input
2. Audio Output
3. CV Input
4. CV Output
When not in use, the corresponding LED (one out of four) will be turned on, steadily. When in use, it will blink in relation to the signal's level.
Fortunately, we've managed to find components that are small enough to fit 4 encoders or 4 ports alongside the length of a 1 × 1 brick. To do so, we will need to modify our standard aluminum profile though: alongside the horizontal axis, walls will be 5mm thick, as originally planned; but alongside the vertical axis, they will be 3mm thick only. This will make it possible to put 4 × stereo jacks (8.2mm) and 4 × 4-LED circuit board indicators (4.7mm) side by side (51.6mm). With 60mm × 60mm bricks, this will leave 2.4mm to play with (60 - 2×3 - 51.6), which should be plenty enough. In fact, we might make the vertical walls only 2mm thick if we can convince ourselves that they will preserve sufficient mechanical properties.
None of these encoders and jacks provide a touch sense interface though. Therefore, we will need to implement this feature at the brick level when using a conductive cover. Some more research work will be required in this area.
Also, we still need to specify the interconnect between the control PCBs and the interconnect PCB (the one providing the interconnect with the underlying grid PCB). With the extremely-limited amount of real-estate available within high-density bricks like a 4 × 4 matrix of 16 ports, we will probably have to use a set of Flexible Printed Circuit (FPC) connectors.
With such a design, we're probably better off mounting our microcontroller on the upper part of the grid PCB, while installing all the control-specific components on the encoder and port PCBs. With that in mind, we've decided to switch from the ATmega328 to the ATxmega32A4U. This will remove the need for a separate USB chip, and it will give us more IOs and more built-in ADC channels. Most importantly, these ADC channels will be 12-bit wide instead of 10-bit wide, which is quite nice.
This sheet provides an up-to-date list of all the discrete components that we are planning to use.
Finally, we've started to work on the regulators and power supplies. At present time, we're looking at the TPS7A4700 and LT3045/LT3094, and we're giving serious consideration to the idea of using pre-assembled components from LDOVR. In a perfect world, each mono audio input channel and each mono output channel would have its own LT-DPPSU dual polarity LT3045/LT3094 ultra low noise power supply...
While looking for the right encoders and 3.5mm stereo jacks, we've realized that we could further factorize our standard bricks. Indeed, 12 of the most popular bricks could be built out of just 5 submodules:
- 2 large encoders (E2)
- 3 large encoders (E3)
- 4 small encoders (E4)
- 3 ports (E3)
- 4 ports (E4)
This gave us the idea that such bricks should be assembled from these submodules, with one PCB per submodule. Some PCBs would be parallel to the brick's cover (encoders), while others would be perpendicular (ports). Doing so would reduce the number of SKUs from 12 down to 5, and would make it a lot easier for anyone to create custom bricks by simply machining a custom cover.
With that in mind, we've selected the following components:
- EC09E1524417 small encoder
- PEL12T large encoder
- STX-3150-3N-1 stereo jack
- SSF-LXH5147LGD LED circuit board indicator
The 4-LED circuit board indicator will be used to indicate the port's type:
1. Audio Input
2. Audio Output
3. CV Input
4. CV Output
When not in use, the corresponding LED (one out of four) will be turned on, steadily. When in use, it will blink in relation to the signal's level.
Fortunately, we've managed to find components that are small enough to fit 4 encoders or 4 ports alongside the length of a 1 × 1 brick. To do so, we will need to modify our standard aluminum profile though: alongside the horizontal axis, walls will be 5mm thick, as originally planned; but alongside the vertical axis, they will be 3mm thick only. This will make it possible to put 4 × stereo jacks (8.2mm) and 4 × 4-LED circuit board indicators (4.7mm) side by side (51.6mm). With 60mm × 60mm bricks, this will leave 2.4mm to play with (60 - 2×3 - 51.6), which should be plenty enough. In fact, we might make the vertical walls only 2mm thick if we can convince ourselves that they will preserve sufficient mechanical properties.
None of these encoders and jacks provide a touch sense interface though. Therefore, we will need to implement this feature at the brick level when using a conductive cover. Some more research work will be required in this area.
Also, we still need to specify the interconnect between the control PCBs and the interconnect PCB (the one providing the interconnect with the underlying grid PCB). With the extremely-limited amount of real-estate available within high-density bricks like a 4 × 4 matrix of 16 ports, we will probably have to use a set of Flexible Printed Circuit (FPC) connectors.
With such a design, we're probably better off mounting our microcontroller on the upper part of the grid PCB, while installing all the control-specific components on the encoder and port PCBs. With that in mind, we've decided to switch from the ATmega328 to the ATxmega32A4U. This will remove the need for a separate USB chip, and it will give us more IOs and more built-in ADC channels. Most importantly, these ADC channels will be 12-bit wide instead of 10-bit wide, which is quite nice.
This sheet provides an up-to-date list of all the discrete components that we are planning to use.
Finally, we've started to work on the regulators and power supplies. At present time, we're looking at the TPS7A4700 and LT3045/LT3094, and we're giving serious consideration to the idea of using pre-assembled components from LDOVR. In a perfect world, each mono audio input channel and each mono output channel would have its own LT-DPPSU dual polarity LT3045/LT3094 ultra low noise power supply...
Last edited:
I guess that's half of the problem with silicon like this. Relatively low demand globally but where the demand is it's absolutely crucial that the chip can do it.
My thoughts would be that it's the R&D costs behind the chip that are mainly responsible for it's high final price. Even with the limited demand we're still talking thousands of chips bring made which is plenty for basic economy of scale. It's built on a 20nm process, which should be relatively high yield, although it is certainly smaller than most chips.
If you get free access to all of the software that those thousands of engineers pioneered, as well as whom engineered the chip, then it does make more sense for the chip to have a higher than expected end cost.
Still destroying one or two during prototyping is not my idea of a fun time. Roll on aerospace/military budgets.
My thoughts would be that it's the R&D costs behind the chip that are mainly responsible for it's high final price. Even with the limited demand we're still talking thousands of chips bring made which is plenty for basic economy of scale. It's built on a 20nm process, which should be relatively high yield, although it is certainly smaller than most chips.
If you get free access to all of the software that those thousands of engineers pioneered, as well as whom engineered the chip, then it does make more sense for the chip to have a higher than expected end cost.
Still destroying one or two during prototyping is not my idea of a fun time. Roll on aerospace/military budgets.
Yeah, pretty much. The die sizes can be rather large, but not as large as the largest server CPUs or GPUs, I think. Supposedly an Intel/Altera Stratix 10 has around 30 billion transistors. I'm sure R&D is a huge portion of the cost given the IP cores and toolchains each vendor supports. The market for these is anywhere you can't get the performance you need off-the-shelf.
I concur with your analysis. Also, not destroying chips during prototyping is one of the many reasons why designers use pre-assembled modules. Another reason is the complexity of designing the power supply subsystem for these chips.
Unfortunately, the Vivado software suite is not free...
Indeed. Or where the development of a custom ASIC would not be an option because of budget constraints or time-to-market requirements.
What do you think? Why did AKM take the NE5534? Because this is the best and lowest noise op amp that ever was and will ever be.
Do you get royalties from sales of NE5534 or something?
You might have an unhealthy obsession with NE5534... lol.
Seriously though, AKM has switched to OPA1612 on their highest performance AK4499 evaluation board. NE5534 hasn't been the absolute best option for a while in many circuits.
I couldn't find this directly on the new Cirrus website, but here is a pretty good app note on designing the input buffer:
https://d3uzseaevmutz1.cloudfront.net/pubs/appNote/an241-1.pdf
OPA1611/OPA1612 would substitute anywhere you're ok with using a bipolar input op-amp that has low voltage noise and higher current noise. If you think you might want a FET input, you could use something like OPA1642 or OPA1656. I'd have to look at the exact circuit, but OPA1612 usually can drop in where an NE5534 is being used.
I'd definitely recommend taking a look at OPA1632 or a similar fully-differential op-amp for the difference amplifier, assuming you are going to use something like the 3 op-amp classic instrumentation amplifier circuit. This will give you differential outputs with one part and also let you set the output common mode voltage to the ADC's VCOM voltage though the use of the VOCM pin. There are plenty of AD and TI app notes showing FDAs used to drive differential input ADCs.
See Figure 14 in the OPA1632 datasheet for a basic example.
http://www.ti.com/lit/ds/symlink/opa1632.pdf
Last edited:
For clocks, I don't think you need anything beyond a good quality LVCMOS output XO. It's hard to beat the performance and convenience of oscillators like the NDK2520SD or Crystek CCHD-957. Honestly, you probably don't even need to go that far. I haven't measured any parts or sampled across lots, but I actually think generic clocks like the Kyocera K series may be close to as good as the NDK and Crystek parts. There was one member here a few years ago who measured one and it was surprisingly close to the specs for the NDK. I've also used that clock as a reference clock for a SerDes PLL for a high speed link without any signal integrity problems.
Just to clarify - I'm sure someone will point out you can design something with lower phase noise with discrete parts and specially selected or expensive SC cut crystals - but I don't think there's any real measured evidence to suggest you need to go to that length, even for a statement product.
As far as reclocking, if you are talking about synchronous reclocking where you feed D flip-flops with the MCLK to reclock the I2S bit clock, data, and word clock lines, I don't think you need to do it. Modern converters are all clocked from MCLK directly and the I2S data is probably clocked into shift registers / buffers. I don't see how levels of jitter that don't violate the setup and hold timing or something crazy like that could have an impact on those signals since they aren't the conversion clock.
The only thing you should try to do is ensure your converter clock is the "master". That means USB, AES67, etc. interfaces that work in asynchronous mode (XMOS can). If you have an input where that can't happen and the master clock arrives with the data (AES, SPDIF), then you can consider using an ASRC chip like SRC4192 to bridge clock domains. Otherwise you need a PLL and VCXO or something like the Cirrus CS2100 chip. I am not sure about the tradeoffs of using an ASRC vs something like the CS2100.
Just to clarify - I'm sure someone will point out you can design something with lower phase noise with discrete parts and specially selected or expensive SC cut crystals - but I don't think there's any real measured evidence to suggest you need to go to that length, even for a statement product.
As far as reclocking, if you are talking about synchronous reclocking where you feed D flip-flops with the MCLK to reclock the I2S bit clock, data, and word clock lines, I don't think you need to do it. Modern converters are all clocked from MCLK directly and the I2S data is probably clocked into shift registers / buffers. I don't see how levels of jitter that don't violate the setup and hold timing or something crazy like that could have an impact on those signals since they aren't the conversion clock.
The only thing you should try to do is ensure your converter clock is the "master". That means USB, AES67, etc. interfaces that work in asynchronous mode (XMOS can). If you have an input where that can't happen and the master clock arrives with the data (AES, SPDIF), then you can consider using an ASRC chip like SRC4192 to bridge clock domains. Otherwise you need a PLL and VCXO or something like the Cirrus CS2100 chip. I am not sure about the tradeoffs of using an ASRC vs something like the CS2100.
Last edited:
Channel Module
I have been working on the Channel module of the reference setup with the goal of replicating the functionality offered by the mono and stereo input channels of the Rupert Neve 5088. The reference setup gives us 3 × OTO units to play with, which is quite tight, but thanks to the submodular design introduced yesterday, it should be possible, using the following bricks:
1 × B12E2 (two large encoders and 12 small buttons)
1 × B8E4 (2+2 large encoders and 4+4 small buttons)
1 × B8E5 (2+3 large encoders and 4+4 small buttons)
The beauty of the design is that we should be able to use the same module for both mono and stereo inputs, with some controls being disabled in mono mode. And while we've not specified everything, we're pretty confident that we could use the same module for group channels as well. Also, we have decided not to include the "Channel Solo" and "Channel Mute" buttons, because these are already provided by the Dual Fader Brick (alongside SELECT, REC, and MODE).
Now, we need to source the right part for our small buttons, which should be illuminated.
I have been working on the Channel module of the reference setup with the goal of replicating the functionality offered by the mono and stereo input channels of the Rupert Neve 5088. The reference setup gives us 3 × OTO units to play with, which is quite tight, but thanks to the submodular design introduced yesterday, it should be possible, using the following bricks:
1 × B12E2 (two large encoders and 12 small buttons)
1 × B8E4 (2+2 large encoders and 4+4 small buttons)
1 × B8E5 (2+3 large encoders and 4+4 small buttons)
The beauty of the design is that we should be able to use the same module for both mono and stereo inputs, with some controls being disabled in mono mode. And while we've not specified everything, we're pretty confident that we could use the same module for group channels as well. Also, we have decided not to include the "Channel Solo" and "Channel Mute" buttons, because these are already provided by the Dual Fader Brick (alongside SELECT, REC, and MODE).
Now, we need to source the right part for our small buttons, which should be illuminated.
Boards
In order to get a better understanding of all the things we have to build, we have made a list of all the individual printed circuit boards that will need to be designed, fabricated, tested, and debugged. 19 of them will be needed to implement all our bricks and the full stack of a 2 × 6 OTO grid. We have our work cut out for us...
In order to get a better understanding of all the things we have to build, we have made a list of all the individual printed circuit boards that will need to be designed, fabricated, tested, and debugged. 19 of them will be needed to implement all our bricks and the full stack of a 2 × 6 OTO grid. We have our work cut out for us...
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.