Minor fixes to the script I'm using to build the filter co-efficents, rather than any significant changes to the filter.
Script changes:
- Previously rounding frequencies to nearest multiple of 11.025Hz, changed to Fs/1280000. I've found remez converges better if there is a common multiple to all frequencies.
- Corrected 48khz pass band edge to 20kHz. Had copied from old 44.1kHz config so 250Hz lower than necessary.
Filter changes:
- quasiapo is now the "mainline" EQHQ filter.
- 384KHz specific FIR2 added
Script changes:
- Previously rounding frequencies to nearest multiple of 11.025Hz, changed to Fs/1280000. I've found remez converges better if there is a common multiple to all frequencies.
- Corrected 48khz pass band edge to 20kHz. Had copied from old 44.1kHz config so 250Hz lower than necessary.
Filter changes:
- quasiapo is now the "mainline" EQHQ filter.
- 384KHz specific FIR2 added
I have, and none of them are any better than NEWNOS, imo. But of course its all subjective, and one mans feast is another mans poison. I'll continue to follow, and applaud, your work, just wish it was on a better dac.
To put it on the table, my best dac is Ians FIFO/isolator/double clock/PCM-I2S/AYA2014. It easily equalled a $15K commercial dac this weekend and is far superior to the dam, although it costs 3 times what the dam does.
I’ve very quickly compared 'our dac' running the EQHQ_quasiapo filter with my TAG McLaren AV192 processor costing £10,000+ when new a few years back, if that’s anything to go by – thank goodness for eBay! Both are running the same SP/DIF input via an Apogee Big Ben clock. I accept more time listening is ideally needed, immediate impressions are however, there is absolutely nothing to choose between them. My dac is fed by +/- series regulated DC supplies and I’ve fitted 2200uF Black Gates on +/- 5V into the analogue supply op-amps. Output from ladder feeds directly into modified Tube Technology DAC64 valve analogue stage via small decoupling Black Gates.
In my mind now, with all the work Paul has put into the filter design, I think there is little if anything more to gain tweaking filters further until the dac design is updated with new firmware at least, such the filters can be extended. Having heard the improvements in sound ‘seriously designed’ power supplies bring, that’s where I want to look next for the 3V3 FPGA supply and maybe the 4V ladder supply. I was perhaps extravagant buying a 0.05% as a prototype and a 0.01% which is still in its original bag awaiting a one-off rework when I’ve finished tweaking – yeah, right!
What I’ve so enjoyed thus far with this project is benefiting from like-minded folk sharing ideas, knowledge, swapping opinions, and ending up with what looks to be a dac which will at least compete with my TAG kit and hopefully better it one day soon, and finding music in my collection I’d completely forgotten about. Thanks to all... !!!
In my mind now, with all the work Paul has put into the filter design, I think there is little if anything more to gain tweaking filters further until the dac design is updated with new firmware at least, such the filters can be extended. Having heard the improvements in sound ‘seriously designed’ power supplies bring, that’s where I want to look next for the 3V3 FPGA supply and maybe the 4V ladder supply. I was perhaps extravagant buying a 0.05% as a prototype and a 0.01% which is still in its original bag awaiting a one-off rework when I’ve finished tweaking – yeah, right!
What I’ve so enjoyed thus far with this project is benefiting from like-minded folk sharing ideas, knowledge, swapping opinions, and ending up with what looks to be a dac which will at least compete with my TAG kit and hopefully better it one day soon, and finding music in my collection I’d completely forgotten about. Thanks to all... !!!
Loaded up the EQHQ_v2. Compared with the Quassi music seems be a fraction less forward and into the room somehow, it flows, it is perhaps a little easier on the ear, it feels arguably a tiny wee bit more 'grown up'. It is as if the music is doing the talking (eh?) rather than the electronics adding their own character. Comparing with the TAG the Quassi was as near as identical in every way. I'm asking myself, does the v2 sound 'more expensive'? Apologies spouting rubbish trying to describe what I'm hearing and the comparisons I'm making. There is, I believe, a certain magic with v2 which commands my attention. Could the TAG be being bettered? Listening to some jazz and saxophone, allegedly an 'Audiophile recording'. Have checked, it is 16-bit 44k.
No gardening today, it's pouring with rain - any excuse to get out the soldering iron, or perhaps another cup of coffee and relax back into the sofa is the better option? Happy days....
No gardening today, it's pouring with rain - any excuse to get out the soldering iron, or perhaps another cup of coffee and relax back into the sofa is the better option? Happy days....
Out of interest, favourite filters have evolved in following order, latest to earliest...
1. EQHQ_v2
2. EQHQ_quasiappo
3. Sox_HiAtt
4. 384_C130_MP
5. NQ_C960_140dp
6. NewNOS / TotalCrap
Some small measure of the improvements we've seen with the hours and hours of work put into filter design - a huge thank you once again to all involved!!!
1. EQHQ_v2
2. EQHQ_quasiappo
3. Sox_HiAtt
4. 384_C130_MP
5. NQ_C960_140dp
6. NewNOS / TotalCrap
Some small measure of the improvements we've seen with the hours and hours of work put into filter design - a huge thank you once again to all involved!!!
Hey Andrew, thanks for the comments.
Interesting to hear that the EQHQ filters are giving the TAG a run for it's money.
I was having a look at the Stereophool reviews of the MSB DAC's and it appears they are using linear phase adopising filters (as in they fully attenuate before nyquist) for the filter 1 position, which was preferred by the reviewers. Longer filters should get us much closer to the ideal of full attenuation at 22.05kHz while also pushing the passband edge higher.
Another minor revision to the filter, so now v2r1
- Stop band shaping removed as was not doing anything beneficial at this level of attenuation. This requires minor tweaks to filter settings.
- 48KHz filter pass band edge raised by 3Hz to allow design to converge.
- Filter order specified as "even", which forces filters with an odd number of taps
- Pass band edge frequency of 44.1KHz filter raised to 19107Hz
- Stop band edge frequency of 44.1KHz filter raised to 22750Hz.
- Stop band shaping removed as was not doing anything beneficial at this level of attenuation. This requires minor tweaks to filter settings.
- 48KHz filter pass band edge raised by 3Hz to allow design to converge.
- Filter order specified as "even", which forces filters with an odd number of taps
- Pass band edge frequency of 44.1KHz filter raised to 19107Hz
- Stop band edge frequency of 44.1KHz filter raised to 22750Hz.
FIR2 constraints
Seems that I need to explain what is going on with the FIR2 filters...
FIR2 is used primarily to eliminate images around Nyquist of FIR1. Obviously you can ignore this but assuming you want FIR2 to perform it's intended task effectively you have constraints.
The first constrain is that highest stop band frequency for FIR2 is limited by the point where the x1 sample rate filters mirror. I take this to be the stop band edge of the FIR1 filter, so:
lower edge of first mirror image = 352800-22750
= 330050Hz
For all the other sampling rates the lower edge of the first mirror image is significantly higher.
The second constraint I put on FIR2 is that it should not interfere with the filter curve of the highest non bypass filter, so in this case 176.4KHz.
This is more a case of juggling with the pass band edge and plotting the response curves of the filters to ensure there is minimal interaction.
The third limitation is the constraints of number of taps, pass band ripple and stop band attenuation, which all place a limit on FIR2 filter steepness, and therefore limit how steep you can make the 176.4KHz FIR1 without FIR2 becoming the dominant filter.
In the current filter FIR2 for x44.1 based rates is at 115 out of a possible 120 taps. There is limited scope to increase the edge of the pass band and therefore increase the steepness of the filter without reducing attenuation or increasing pass band ripple, so this becomes the ultimate limit on behaviour of the filter at 176.4KHz.
Seems that I need to explain what is going on with the FIR2 filters...
FIR2 is used primarily to eliminate images around Nyquist of FIR1. Obviously you can ignore this but assuming you want FIR2 to perform it's intended task effectively you have constraints.
The first constrain is that highest stop band frequency for FIR2 is limited by the point where the x1 sample rate filters mirror. I take this to be the stop band edge of the FIR1 filter, so:
lower edge of first mirror image = 352800-22750
= 330050Hz
For all the other sampling rates the lower edge of the first mirror image is significantly higher.
The second constraint I put on FIR2 is that it should not interfere with the filter curve of the highest non bypass filter, so in this case 176.4KHz.
This is more a case of juggling with the pass band edge and plotting the response curves of the filters to ensure there is minimal interaction.
The third limitation is the constraints of number of taps, pass band ripple and stop band attenuation, which all place a limit on FIR2 filter steepness, and therefore limit how steep you can make the 176.4KHz FIR1 without FIR2 becoming the dominant filter.
In the current filter FIR2 for x44.1 based rates is at 115 out of a possible 120 taps. There is limited scope to increase the edge of the pass band and therefore increase the steepness of the filter without reducing attenuation or increasing pass band ripple, so this becomes the ultimate limit on behaviour of the filter at 176.4KHz.
Attachments
To FIR2:
An easy to implement improvement of the situation (for Soren) would be to load filters as matched FIR1-FIR2 pairs. Then e.g. you would not need to think about the 178 FIR1 when designing the FIR2 for 44.1.
Moreover that would make sense in case you want to use different types of filters for different frequencies, e.g. a NOS FIR1 for the higher frequencies would call for a NOS FIR2, but if you use Non-NOS for low frequencies this would be a FIR2 mismatch.
An easy to implement improvement of the situation (for Soren) would be to load filters as matched FIR1-FIR2 pairs. Then e.g. you would not need to think about the 178 FIR1 when designing the FIR2 for 44.1.
Moreover that would make sense in case you want to use different types of filters for different frequencies, e.g. a NOS FIR1 for the higher frequencies would call for a NOS FIR2, but if you use Non-NOS for low frequencies this would be a FIR2 mismatch.
I am sure it can be done such that if only one FIR2 is given, it would be used for everything (would also ensure backward comparability).
The matched FIR pair loading feature would be necessary as soon real IFIR filters (i.e. only FIR1 together with FIR 2 give a flat passband) would be used, unless you want to download the fillers for every sample rate change manually.
I'm talking about filter creators managing the production of .skr filters not handling it the DAC. I'm not that excited by the prospect of dealing with incremental updates to txt files with 40 different filter sections, let alone 60.
Anyway it's all academic until Soren releases an update that enables these Wishlist features.
And its not by any means certain that any particular feature you've requested will make it into the firmware.
So perhaps we wait and see what Søren gives us...
Anyway it's all academic until Soren releases an update that enables these Wishlist features.
And its not by any means certain that any particular feature you've requested will make it into the firmware.
So perhaps we wait and see what Søren gives us...
Last edited:
Maybe Søren can answer this...
The filter description field seems to be included in the processed .skr but it's not exactly clear what - if anything - this is used currently for.
So two questions:
Will this field be used to provide filter information when the user selectable filters are introduced, or is it just to help id what the filter is?
and,
Is there a specific format that needs to used for the fields?
cheers
Paul
The filter description field seems to be included in the processed .skr but it's not exactly clear what - if anything - this is used currently for.
So two questions:
Will this field be used to provide filter information when the user selectable filters are introduced, or is it just to help id what the filter is?
and,
Is there a specific format that needs to used for the fields?
cheers
Paul
Last edited:
Obviously comma delimited text fields, with fields for:
- Fir Type
- Sampling Rate,
- Passband response
- Stopband Response
Just have to get the formatting for the description sorted out and I'll be right.
Last edited:
It seems that the assumption that 168dB stop band attenuation is sufficient was a slight misstep. This has resulted in the return of the loud rate change pop. Increasing attenuation to greater than 28bit/168dB reduces the POP to a pop, so there is definitely something to be gained in this regard.
It really makes sense, in that 168dB/28bit is at the LSB level, whereas going beyond this drops below LSB which is doubleplusgood imo.
Also managed to get the info string formatting sorted out well enough... not sure it makes much difference at this stage how ever. Anyway my filter script now outputs a complete 1021filt.txt file ready to process, without any further intervention. It will be trivial to add handling for additional fir2 if needed. That removes most of the reservations I have about manually updating files.
It really makes sense, in that 168dB/28bit is at the LSB level, whereas going beyond this drops below LSB which is doubleplusgood imo.
Also managed to get the info string formatting sorted out well enough... not sure it makes much difference at this stage how ever. Anyway my filter script now outputs a complete 1021filt.txt file ready to process, without any further intervention. It will be trivial to add handling for additional fir2 if needed. That removes most of the reservations I have about manually updating files.
Yes, just filter info, ascii text with no formatting. Planning to be able to printout in uManager.
With exately the same musik playing? I have not noticed influence of filters (however I did not chenagged them that frequently, as you), but a heavy dependence on what is actully played.