6 ms·

If you want to do it in the digital domain, FPGA is the obvious choice to go with here. It'd be difficult to get enough channels connected to a 'custom' design

If you want to do it in the digital domain, FPGA is the obvious choice to go with here. It'd be difficult to get enough channels connected to a 'custom' design any other way, but yes the learning curve will be steep if you go that route. There is enough bandwidth on a USB 2.0 HS port for many channels of audio, you could just buy a couple decent multichannel USB 2.0 HS audio interfaces. They are pretty readily available with 8 in / 8 out (mono) channels in one box for a few hundred bucks. You can plug these into a RPi and it probably has enough grunt to do the processing using JACK or pipewire or some similar audio router with some custom code to manage it. Full-pipeline latency could be problematic, especially if you need to stay in sync with the TV and whatnot that is pretty noticeable and often can't be compensated. This is probably the simplest way to get something that 'works-ish' though. People use similar (smaller) setups for realtime room/speaker compensation filters and it seems to work alright, and this application isn't too far off from that. In fact, you might want to do that too. There's an analog solution too, your RPi or microcontroller can manage an array of variable gain amplifiers (using a slow / cheap multichannel DAC) or programmable gain amplifiers (directly with I2C or SPI) which form the inputs to a traditional summing mixer circuit. Then you don't need to worry about processing some dozens of megabits of audio data with low-ms of latency and just need to set appropriate gains, but the analog design is a bit more complicated. Still, this is IMO much easier than an ADC -> FPGA -> DAC pipeline. Prototyping SMT parts you can either buy protoboards with the chip mounted and pins for use with a breadboard, SparkFun and AdaFruit make tons of modules like this, or try AliExpress, and you can find devboards for pretty much any microcontroller or FPGA too. If the chip you need to work with doesn't have such a board available, you can get generic breakout boards for most SMT packages and solder the chips on yourself. It's not that difficult, though it takes decent equipment and a bit of practice. Having custom PCBs made is also super cheap now, and that is how I would recommend approaching this, if you're willing to tackle the soldering challenge and don't' mind the somewhat long iteration cycle as you wait for boards to arrive from Asia (or don't mind paying for premium shipping or a more-local manufacturer).

an-unknown 3y ago
> Full-pipeline latency could be problematic, especially if you need to stay in sync with the TV and whatnot […] Since these multichannel audio interfaces are usually intended for real time music production or live stage setups, you should be able to get low two digit milliseconds of latency, at least if you do it on a PC. That should be good enough to keep everything in sync. No idea how much latency you would get on a Raspi though. > There's an analog solution too […] Yes, of course there is, but chances are this will be more expensive if you build it for that many channels and it almost certainly also needs more energy and PCB space. The biggest problem though: the original requirement sounded like every output needs its individual "submix", so the complexity would quickly explode. You also cannot easily add e.g. delay compensation or digital EQ / FIR filter for room compensation if you later figure out this would be useful. You don't have these problems in the digital domain. > Then you don't need to worry about processing some dozens of megabits of audio data with low-ms of latency […] To be fair, if you do this on an FPGA, even small <$10 ones will be fast enough to mix hundreds of channels with one sample latency or if you use different clocks for the ADCs and DACs even less than one sample latency. That's even significantly faster than any "professional audio interface" based solution. > Still, this is IMO much easier than an ADC -> FPGA -> DAC pipeline. I'm not so sure about that. With the purely analog solution, you have to deal with all the analog problems like potential need for calibration of amplifier gains and noise being introduced in every step as well as the layouting/routing/manufacturing/power consumption of the potentially big circuit. With the digital solution, you have to deal with ADCs/FPGA/DACs, which is essentially not much more than "copy the minimal FPGA schematic from some eval board and copy the ADC/DAC schematic from the respective datasheet". In the end it's just a different set of challenges, but I don't think the analog solution is significantly easier to build. > Having custom PCBs made is also super cheap now, and that is how I would recommend approaching this, if you're willing to tackle the soldering challenge […] Don't forget that machine assembly is also super cheap now at least if you order in Asia, which removes almost all of the "soldering challenge" since usually only a hand full of big THT components like connectors will remain for you to solder manually.
- coreyp_1 3y ago
  You are correct. I need submixes for each channel. And, I mis-counted my inputs, and will nix an output, but that still leaves me with a 16x16 mess. I've spent the weekend looking into this. I would love to build my own, but I'm not sure where to start with the FPGAs. What FPGA would you suggest that I check out for this application? I don't mind buying stuff and experimenting, I just need to know which direction to explore! Thanks for your comments! If I can get this to work, I'll definitely open-source my results!
  - error503 3y ago
    If you want to experiment with FPGA, the Lattice iCE40 series is a good starting point. It's not super capable (but will be more than enough for your project), but it was one of the first with a solid open source toolchain and has a strong open source / open hardware community as a result. It's also quite cheap. Check out the iCEBreaker project for a decent board to get going with, and some educational materials: https://www.crowdsupply.com/1bitsquared/icebreaker-fpga https://www.crowdsupply.com/1bitsquared/icebreaker-fpga
- error503 3y ago
  Good points. > The biggest problem though: the original requirement sounded like every output needs its individual "submix", so the complexity would quickly explode. You also cannot easily add e.g. delay compensation or digital EQ / FIR filter for room compensation if you later figure out this would be useful. You don't have these problems in the digital domain. I definitely missed this, that makes it totally untenable in analogue domain as anything other than a ridiculous art project or back when it was the only way to do it. The digital solution is much more flexible and once you get the pipeline running and understand how it all works, much easier to modify. I mention the analogue option only to offer an alternative, possibly more intuitive / easier to get started and experiment with option. Even in the simple mixer case, it's still probably not a viable solution for a real product, the digital stuff is so cheap now. > I don't think the analog solution is significantly easier to build. It's not just building it, but the learning curve. OP seems to have no electronics or DSP knowledge at all. Maybe it's my own background clouding my evaluation here, but bootstrapping even a passthrough ADC -> DSP/FPGA -> DAC pipeline to the point where it works sounds like a near-herculean task for someone without experience of either domain. For practical purposes it more or less requires custom PCBs which is its own learning curve, and even a basic FPGA is going to have non-trivial power, layout, and bitstream storage requirements to get right, which requires reading layout / power / app notes & datasheets. Then you need to learn the vendor's tooling and how to set up PLLs and design a clock scheme for the system, learn an HDL - which tends to be very unintuitive for software folks, with a steep learning curve of its own. Finally, you can eventually get to fooling around with your basic noop pipeline, but that is a loooong way from the word go to thinking about the problem you came in with. It won't be, relatively speaking, any good, but lashing up a simple additive mixer with a couple opamps on a breadboard will get you something to start iterating on. In the end it might not be any easier to get to a final solution, but personally at least I find this kind of iterative improvement much easier than brick wall after brick wall with little to show for it. Especially given they want an 8x8 matrix, frankly I think using existing OTS audio interfaces is the only practical solution unless OP is willing to dedicate a man-year of work to the project. > Don't forget that machine assembly is also super cheap now at least if you order in Asia, which removes almost all of the "soldering challenge" since usually only a hand full of big THT components like connectors will remain for you to solder manually. I almost mentioned this, and I've done it successfully a bunch of times, but it felt like a bit too much learning curve (lol compared to learning HDL).

an-unknown 3y ago

> Full-pipeline latency could be problematic, especially if you need to stay in sync with the TV and whatnot […] Since these multichannel audio interfaces are usually intended for real time music production or live stage setups, you should be able to get low two digit milliseconds of latency, at least if you do it on a PC. That should be good enough to keep everything in sync. No idea how much latency you would get on a Raspi though. > There's an analog solution too […] Yes, of course there is, but chances are this will be more expensive if you build it for that many channels and it almost certainly also needs more energy and PCB space. The biggest problem though: the original requirement sounded like every output needs its individual "submix", so the complexity would quickly explode. You also cannot easily add e.g. delay compensation or digital EQ / FIR filter for room compensation if you later figure out this would be useful. You don't have these problems in the digital domain. > Then you don't need to worry about processing some dozens of megabits of audio data with low-ms of latency […] To be fair, if you do this on an FPGA, even small <$10 ones will be fast enough to mix hundreds of channels with one sample latency or if you use different clocks for the ADCs and DACs even less than one sample latency. That's even significantly faster than any "professional audio interface" based solution. > Still, this is IMO much easier than an ADC -> FPGA -> DAC pipeline. I'm not so sure about that. With the purely analog solution, you have to deal with all the analog problems like potential need for calibration of amplifier gains and noise being introduced in every step as well as the layouting/routing/manufacturing/power consumption of the potentially big circuit. With the digital solution, you have to deal with ADCs/FPGA/DACs, which is essentially not much more than "copy the minimal FPGA schematic from some eval board and copy the ADC/DAC schematic from the respective datasheet". In the end it's just a different set of challenges, but I don't think the analog solution is significantly easier to build. > Having custom PCBs made is also super cheap now, and that is how I would recommend approaching this, if you're willing to tackle the soldering challenge […] Don't forget that machine assembly is also super cheap now at least if you order in Asia, which removes almost all of the "soldering challenge" since usually only a hand full of big THT components like connectors will remain for you to solder manually.

coreyp_1 3y ago
You are correct. I need submixes for each channel. And, I mis-counted my inputs, and will nix an output, but that still leaves me with a 16x16 mess. I've spent the weekend looking into this. I would love to build my own, but I'm not sure where to start with the FPGAs. What FPGA would you suggest that I check out for this application? I don't mind buying stuff and experimenting, I just need to know which direction to explore! Thanks for your comments! If I can get this to work, I'll definitely open-source my results!
- error503 3y ago
  If you want to experiment with FPGA, the Lattice iCE40 series is a good starting point. It's not super capable (but will be more than enough for your project), but it was one of the first with a solid open source toolchain and has a strong open source / open hardware community as a result. It's also quite cheap. Check out the iCEBreaker project for a decent board to get going with, and some educational materials: https://www.crowdsupply.com/1bitsquared/icebreaker-fpga https://www.crowdsupply.com/1bitsquared/icebreaker-fpga
error503 3y ago
Good points. > The biggest problem though: the original requirement sounded like every output needs its individual "submix", so the complexity would quickly explode. You also cannot easily add e.g. delay compensation or digital EQ / FIR filter for room compensation if you later figure out this would be useful. You don't have these problems in the digital domain. I definitely missed this, that makes it totally untenable in analogue domain as anything other than a ridiculous art project or back when it was the only way to do it. The digital solution is much more flexible and once you get the pipeline running and understand how it all works, much easier to modify. I mention the analogue option only to offer an alternative, possibly more intuitive / easier to get started and experiment with option. Even in the simple mixer case, it's still probably not a viable solution for a real product, the digital stuff is so cheap now. > I don't think the analog solution is significantly easier to build. It's not just building it, but the learning curve. OP seems to have no electronics or DSP knowledge at all. Maybe it's my own background clouding my evaluation here, but bootstrapping even a passthrough ADC -> DSP/FPGA -> DAC pipeline to the point where it works sounds like a near-herculean task for someone without experience of either domain. For practical purposes it more or less requires custom PCBs which is its own learning curve, and even a basic FPGA is going to have non-trivial power, layout, and bitstream storage requirements to get right, which requires reading layout / power / app notes & datasheets. Then you need to learn the vendor's tooling and how to set up PLLs and design a clock scheme for the system, learn an HDL - which tends to be very unintuitive for software folks, with a steep learning curve of its own. Finally, you can eventually get to fooling around with your basic noop pipeline, but that is a loooong way from the word go to thinking about the problem you came in with. It won't be, relatively speaking, any good, but lashing up a simple additive mixer with a couple opamps on a breadboard will get you something to start iterating on. In the end it might not be any easier to get to a final solution, but personally at least I find this kind of iterative improvement much easier than brick wall after brick wall with little to show for it. Especially given they want an 8x8 matrix, frankly I think using existing OTS audio interfaces is the only practical solution unless OP is willing to dedicate a man-year of work to the project. > Don't forget that machine assembly is also super cheap now at least if you order in Asia, which removes almost all of the "soldering challenge" since usually only a hand full of big THT components like connectors will remain for you to solder manually. I almost mentioned this, and I've done it successfully a bunch of times, but it felt like a bit too much learning curve (lol compared to learning HDL).