Well, there's math, and then there's cars...😀
By 2x4 I mean 2 channels in, 4 channels out..., not (1x4)x2..but (1x2)x2
(and by this notation I mean 1 channel goes to 2, and there are right and left, for a total of four outputs)
As I noted above, the MiniDSP MiniSHARC will support 8 stereo channels, so it will indeed do 2x8 [=(1x8)X2]. The issue is only that at 96 KHz, you can only support 2131 taps (the system requires a minimum of 8 taps per channel). So, if you are using all 8 channels at 96 KHz, you will only have 266 taps per channel/filter.
I'll work up a simulation of different filters with different tap counts to try to see what the impact of that is.
As noted, it is certainly possible to stack the MiniSHARCs, and use them in 2X4 mode, or even 2x2 mode to get higher tap counts per channel.
Scott
Last edited:
OK, so I built a little FIR filter using Excel (it was faster than trying to do this in some filter tool).
I then ran it using different tap counts (basically adjusted the hamming window width), and determined a rough frequency response.
Here are the results. The filter is a 300 Hz cutoff LPF driven by a sine wave sampled at 96 KHz. The blue line is 2000 taps. As you can see this filter does a pretty decent job. However, you can also see that as the tap count goes down, the quality of the resulting filter also goes down. This is because with so many samples, a smaller number of taps either means you are narrowing up the window (what I did) or you are spreading the taps out and thus sampling the time domain transform of the filter response more crudely (I have not tried this yet. I'll do it in a different model tomorrow).
You can easily see that at 96 KHz, this approach suffers greatly at low tap counts. I am sure there is some clean mathematical relationship between the effective filter order, the number of taps and the sample rate. I'll go dig out my digital filter text boos and re-discover what that is...
Cheers,
Scott
I then ran it using different tap counts (basically adjusted the hamming window width), and determined a rough frequency response.
Here are the results. The filter is a 300 Hz cutoff LPF driven by a sine wave sampled at 96 KHz. The blue line is 2000 taps. As you can see this filter does a pretty decent job. However, you can also see that as the tap count goes down, the quality of the resulting filter also goes down. This is because with so many samples, a smaller number of taps either means you are narrowing up the window (what I did) or you are spreading the taps out and thus sampling the time domain transform of the filter response more crudely (I have not tried this yet. I'll do it in a different model tomorrow).
You can easily see that at 96 KHz, this approach suffers greatly at low tap counts. I am sure there is some clean mathematical relationship between the effective filter order, the number of taps and the sample rate. I'll go dig out my digital filter text boos and re-discover what that is...
Cheers,
Scott
Last edited:
shallow slopes (in FIR) and enough channels (again 8ch out !) and not to much processing power ressources are still possible ( although adsp215xx (or other sharc+ : dual with arm) would be really awesome...) , especially when 48khz sampling is enough (to me it is..).
I did a more sophisticated analysis, and found that the way I was adjusting the taps was wrong. I was narrowing the hamming window to reduce the number of time bins, but that had the effect of eliminating the outlying components of the impulse response. The result was the filter was softer and softer as the tap count went down.
I redid this using a halving approach, so the baseline was a 2000 tap filter, and then I took every other tap to make a 1000 tap filter, and so on.
Interestingly, I found there was almost NO difference in filter performance as the tap count went down, other than some bumps in the stop band. These may be worse than the graph below since I am not using that fine a filter sweep, so it is possible that the bumps could be somewhat larger (I have seen that FIR bumps and nulls can be very closely spaced).
Her is the graph, of the same filter wilt various tap counts. As you can see, from 2000 taps to 32 taps there is little difference.
Interesting.
What this means is that we should be able to provide 8 outputs with a single SHARC. The core change to what we are currently making is that it would have 4 more DACS and 4 more output amplifiers. Given the complexity of the digital board with two dual channel DACs, I'd probably do a second dual DAC board that would stack onto of the existing DAC section of the digital board, and then just use two analog boards, one with no ADC. Probably a pretty easy upgrade.
Once I have the four channel unit working, I'll look at this.
Cheers,
Scott
I redid this using a halving approach, so the baseline was a 2000 tap filter, and then I took every other tap to make a 1000 tap filter, and so on.
Interestingly, I found there was almost NO difference in filter performance as the tap count went down, other than some bumps in the stop band. These may be worse than the graph below since I am not using that fine a filter sweep, so it is possible that the bumps could be somewhat larger (I have seen that FIR bumps and nulls can be very closely spaced).
Her is the graph, of the same filter wilt various tap counts. As you can see, from 2000 taps to 32 taps there is little difference.
Interesting.
What this means is that we should be able to provide 8 outputs with a single SHARC. The core change to what we are currently making is that it would have 4 more DACS and 4 more output amplifiers. Given the complexity of the digital board with two dual channel DACs, I'd probably do a second dual DAC board that would stack onto of the existing DAC section of the digital board, and then just use two analog boards, one with no ADC. Probably a pretty easy upgrade.
Once I have the four channel unit working, I'll look at this.
Cheers,
Scott
Last edited:
With FIR filters a high number of taps is necessary when try to correct low frequencies, if you are trying to create a high pass filter or similar you can get away with a lot less taps.
If you do look at catering for 4 way active systems you can use a different approach to using FIR filters for everything.
With mixed IIR and FIR EQ you can use a lot less processing power. Using IIR EQ for the crossover slopes and parametric EQ's takes very little processing even for 8 individual channels. Use the FIR as stereo on the input to allow for phase correction or room correction that way you get the best of both worlds. Also by only using FIR to correct phase and not amplitude you can avoid pre-ringing which is the main downside to FIR filters.
Najda users have been asking the designer to allow mixed IIR and FIR EQ for years now and are still waiting. If you could do it you might have a product that would be very useful.
If you do look at catering for 4 way active systems you can use a different approach to using FIR filters for everything.
With mixed IIR and FIR EQ you can use a lot less processing power. Using IIR EQ for the crossover slopes and parametric EQ's takes very little processing even for 8 individual channels. Use the FIR as stereo on the input to allow for phase correction or room correction that way you get the best of both worlds. Also by only using FIR to correct phase and not amplitude you can avoid pre-ringing which is the main downside to FIR filters.
Najda users have been asking the designer to allow mixed IIR and FIR EQ for years now and are still waiting. If you could do it you might have a product that would be very useful.
Yeah, that's a great approach. The key value of the FIR filter is to be able to control phase, so if we use IIRs for the crossovers, and use FIRs for the amplitude and phase equalization, that could be very sweet.
I'll get the current system running, and then start experimenting with that.
I must say, that Nadja board is pretty cheap!
Last edited:
Mix IIR and FIR but for the LF filters downsample first... Is mixed rate processing possible using SHARC, btw? I know some products (stereophile's recommended component btw) which use this technology with moderately low processing power chips mainly used in MP3 players.
Last edited:
No the SHARC does everything at one rate. My approach is to use an ASRC to convert all inputs to 24/96, and then process everything at 24/96. That avoids and rate synchronism issues, and simplifies the overall architecture and programming.
By way of one example, there is only a single BCLK and LRCK for the SHARC I2S output. Everything comes out synced to those clocks, and they are obviously running at 24/96.
96 KHz sampling is obviously overkill for 150 Hz, but I'd rather not have to sort out rate issues, and this approach assures bit perfect, and perfectly synchronous results.
By way of one example, there is only a single BCLK and LRCK for the SHARC I2S output. Everything comes out synced to those clocks, and they are obviously running at 24/96.
96 KHz sampling is obviously overkill for 150 Hz, but I'd rather not have to sort out rate issues, and this approach assures bit perfect, and perfectly synchronous results.
Hello everyone. It' been a while since I posted here. Been very busy on this project.
After reading through the various threads and white papers on digital attenuation, we decided to go with a digitally controlled external analog attenuator. For now we're using the TI PGA2310. I may experiment with the ESS 32 bit internal DAC at some point too, and maybe try a comparison. Doing the attenuator after the DAC prevents mucking up the dynamic range. We have 24 bits to work with, but I'd rather not be running that and a 16 or less bit equivalent for normal listening levels. Using the post-attenuator, we can load the DAC at 100%, and get all 24 bits of resolutions and then lose a little into the analog noise floor at high attenuation levels.
The PGA 2310 is an interesting device. It uses a 16 bit three-wire serial digital control. This is actually two series connected 8-bit controls, so you get 256 1/2 dB steps. The digital control words are clocked into the device serially, and then committed to the device (i.e. the attenuation value gets set) by a third line. The first 8 bits control the volume of one channel, and the second 8-bits control the other channel.
This approach also allows us to control the relative attenuation value for each channel independently, so we can use it for volume (all bits change by the same amount), L/R balance (offset A and B channels) or as an HF/LF balance adjustment.
I am using a PIC controller to read digital rotary (I-Q) encoders for volume, balance and EQ (and also source selection.. ). The changes to the encoder knobs get converted to four volume values in the PIC, and I can then offset them for balance, or shift them up and down to control volume. For each step of the encoder the PIC computes the new values and then clocks the new set of bits out to the attenuators.
Using this approach, I am also able to receive a volume request from the Raspberry Pi controller over I2C (I am using a PIC with an I2C interface), and provide a volume reading back to the RPI(for example to show the volume on a volume slide bard on a table or phone).
So, I can turn a knob on the box and change the volume, and that will show up on the RPi display, or I can change the volume by sliding the controller on the RPi display and the volume on the box changes. I also worked out a log step scheme so we can ramp the volume down to fade when changing sources, etc. Really liking how easy the PIC is to work with..once you get over the basic learning curve!
S
After reading through the various threads and white papers on digital attenuation, we decided to go with a digitally controlled external analog attenuator. For now we're using the TI PGA2310. I may experiment with the ESS 32 bit internal DAC at some point too, and maybe try a comparison. Doing the attenuator after the DAC prevents mucking up the dynamic range. We have 24 bits to work with, but I'd rather not be running that and a 16 or less bit equivalent for normal listening levels. Using the post-attenuator, we can load the DAC at 100%, and get all 24 bits of resolutions and then lose a little into the analog noise floor at high attenuation levels.
The PGA 2310 is an interesting device. It uses a 16 bit three-wire serial digital control. This is actually two series connected 8-bit controls, so you get 256 1/2 dB steps. The digital control words are clocked into the device serially, and then committed to the device (i.e. the attenuation value gets set) by a third line. The first 8 bits control the volume of one channel, and the second 8-bits control the other channel.
This approach also allows us to control the relative attenuation value for each channel independently, so we can use it for volume (all bits change by the same amount), L/R balance (offset A and B channels) or as an HF/LF balance adjustment.
I am using a PIC controller to read digital rotary (I-Q) encoders for volume, balance and EQ (and also source selection.. ). The changes to the encoder knobs get converted to four volume values in the PIC, and I can then offset them for balance, or shift them up and down to control volume. For each step of the encoder the PIC computes the new values and then clocks the new set of bits out to the attenuators.
Using this approach, I am also able to receive a volume request from the Raspberry Pi controller over I2C (I am using a PIC with an I2C interface), and provide a volume reading back to the RPI(for example to show the volume on a volume slide bard on a table or phone).
So, I can turn a knob on the box and change the volume, and that will show up on the RPi display, or I can change the volume by sliding the controller on the RPi display and the volume on the box changes. I also worked out a log step scheme so we can ramp the volume down to fade when changing sources, etc. Really liking how easy the PIC is to work with..once you get over the basic learning curve!
S
Last edited:
- Status
- Not open for further replies.