@BrianHG: I have literally no experience with FPGA but I'd actually love to try it! I think you pretty much answered the why you can find analog mixers, and digital mixers, but never a "digitally controlled analog mixer"
Just wondering, why would using an FPGA instead of a traditional MCU be better? Most ADC / DAC work with the I2S protocol, so a simple MCU could get the digital data, mix it as it pleases, and then output it again?
As for the choice of DAC, I remember looking at the PCM1681 before which was quite affordable for 8 channels, then we only need 2. And for the ADC we could use the PCMD3180.
Or use Cirrus chips for better performance.
1 big plus about going digital FPGA,you can do 'Zero-crossing' detection before changing each volume step to eliminate stepping sound when attenuating large steps.
I am not sure what that means?
The reason for not using an MCU/CPU is that they have an input and output buffer, processing cycles and re-clock timing on those audio buffers no matter how small they may be, this furthers you away from the effect of a real-time analog device.
The FPGA you would have running in real time. No buffers, all audio data coming in in parallel and going out in parallel while the FPGA code will have no software cycles in the line. You are literally coding a 32 bit multiplier and adder running with the ADC and DAC clock. This means (we'll use 96khz for the 6 channel cheap chip I chose) 1 sample to load the las one, 1 sample to multiply and sum all the 16x16 matrix, 1 sample to shift out the results.
This means 3 sample delay at 96Khz going through the FPGA, IE, the same delay as an 'analog' 32khz bandwidth pre-amp.
You wont trim your timing through 256 volume control settings and 16adc & 16 dac channels with this streamline timing on any MCU unless you find and or do some special coding of your own.
(Not that for the ADC/DAC, they also have an internal pipeline delay making things a little slower, but with all ADC/DAC filters and processing turned off, you will get something like an additional 8+8 pipeline on to out delay.)
I'm saying your fixed audio pipeline delay will be something like less than 1/4000th of a second after all considerations going with an FPGA solution. Nothing anyone could hear.
With an MCU, you may be talking as short as 1/200th of a second with 2x256 word audio buffers, or, maybe slower with some soft of OS involved. (Which is why many PC audio Codecs have an internal analog mixer for piping auxiliary audio input to the line out when necessary.)
-- Zero crossing --
Unlike a slow mechanical hand manipulated volume control, digital volume controls are instant fast. Say your source audio has a 20hz bass note and the source audio is currently at it's peak +1.3v point in the sine wave. Going from a volume setting of 0% to 100% (or eve going from a volume of 0% to 100%) at this point will result in a flat output changing into an instant vertical spike, full power at the change of volume. You hear these as a pop or click in the sound when moving a volume control at instant speeds. A zero crossing detector just waits for the input audio signal to cross 0v in the sine wave before allowing transition to a new volume level to prevent this kind of stepping sound. This is not needed if you will always be smoothly fading the volume control settings.
The 6 channel chip I recommended is cheap and fast. All you need are 3 of them, all the audio ins come in on one side of each chip and all the audio outs go out the other side with around 16 digital IO to control each. I would make a separate audio board with the audio codecs and get wire those 3 in parallel except what needs to be separate through a ribbon flex cable or IDC header. Make you FPGA or MCU board separate. This way, you may choose a different processor board or even an FPGA development board to drive your analog module.
Whatever you were going to use to control your volume settings, keep on using that and have that device talk to the FPGA, IE send volume settings to the FPGA through your choice of RS232 UART, I2C, SPI, parallel 8 bit with address/data clock, anything you like as an FPGA will eat anything you throw at it. (For simple things, I like to use RS232 since I can use any PC software environment to talk to my FPGA projects with a little USB/TTL RS232 adapter cable.)