Some might know me as someone slightly obsessed with PEQ (and doing some reviews where I try and measure all the various EQ presets available on a device ). That obsession led me to develop devicePEQ and try to better understand how PEQ is implemented on various hardware devices. But it was timing consuming, so I have a developed new tool that makes the process of verifying the PEQ implementations a much more systematic and accurate process and as you will see later in this post I have already discovered a few issues with some of the most popular 'hardware PEQ' implementations.
Rather than a separate application that people have to install, I thought this might be nice as a web application, so its located here =>
- it looks like this when you access the page:
Note: A side affect of using a browser was the access to the audio interfaces was more limited, so I first implement a way to use the REW API ( with an REW 'pro' license) but in the past week I implemented a 'built-in' implementation that only works in Chrome, Edge and other 'Chromium' based browsers. This new implementation will ask for some permissions to allow the page access the audio devices connected to your computer. It does try to remember these permissions and which audio devices where selected and it tries to be 'intelligent' about the device selection, picking the most appropriate ones available.
The process works as follows:
1. Connect your PEQ device under test
This need to be devices that my devicePEQ tool has a 'protocol' configured for ( which is most usb-c devices with PEQ and I do support other mechanisms). If I recognise the device I will print out the details and for devices which I have already build some 'compensation' for I will detail the compensation here ( an allow you to turn off the compensation to see the 'issues'):
You can see I had to apply 2 compensations for this specific Audio device - more details on this in the findings later.
2. Configure (if required) the correct audio 'Capture' interfaces (or the connection to REW and configure those within REW) and other settings.
It tries pick the right interface and save these for next time ( but you can always change them):
If you decide to use REW instead it looks like this where you can just verify that the REW API works:
3. Generate a baseline measurement - I reset the device PEQ to have 'no PEQ applied' and then test that the audio is correct and I will give errors if something is wrong and I read the bitrate during this process, I also gather the configured bitrate in this process.
Note: REW is obviously better if you are having problems so switch over to REW is you cannot take a baseline measurement with the built in audio capture.
If you are testing an usb-c enabled IEM (or headphone - they are coming) - you can also view this baseline FR:
4. Generate a 'test plan' ( I mostly use the 'constraints' I have configured in devicePEQ for the device under test so suitable min / max Q, dB and the ranges of values to generate the tests for)
You can toggle certain tests and edit the values if you want to try something other values - in this case there were 34 test generated:
5. Run the test plan: I do block access to the page while an individual test is running:
If something fails - you can view the FR differences and this is where I found a few issues that I will talk about next.
Note: I run a series of 'curve fitting' algorithms on the measured output, analysing the theoretical curve and comparing with the actual one measured and while I do allow some errors ( e.g. RMSE of 0.3% ) it does a reasonable good job of finding issues where the PEQ applied was not implemented exactly. But it is early days and I will hopefully refine these algorithms more over the next few months.
If you feel something was wrong you can also re-run failed tests e.g. you touched device or the cable during a test and changed something.
6. I then show the results - if something failed I show something like this:
If a device passes you get a nice notification:
How many pass? I will provide a more detailed list later but many of the simpler 'usb-c' dongles fail this test for reasons I will explain below. Will you hear those issues probably not unless you like high qValue filters but I thought it would be useful to at least show some of my initial findings. I have only tested about 10% of the PEQ devices I have currently, though I did try random devices with different protocols - so I imagine I have found most of the common problems, and I have implemented software 'compensations' where I can for these problems but I don't have a full list of devices which need those compensations.
And before I go further, I should thank many of the companies that sent me PEQ devices to test (and occasionally review), including FiiiO, CrinEar, Moondrop Labs, Tanchjim, EPZ, Topping, JDS Labs, Fosi Audio, JCally, WiiM, Luxsin and many others. And special thanks to TTGZ / Walkplay for explaining some of their product catalog, allowing me to 'group' similar devices easier.
Some initial findings using this tool. I found 3 'common' issues across a number of popular devices:
1. Incorrect FR applied to the filter:
This was something I had noticed even before I wrote this tool, I had seen this issue (when it was very obvious) with the manual EQ FR captures I used to include in reviews, e.g. some early KTMicro devices ( from Tanchjim and probably others ) applied the wrong FR depending on sample rate of the device you apply the filter, so if you saved the PEQ on a device that was running 96khz but ran it against a device with 48khz the value of the FR would be applied wrong. Another example was the companion app to a ANC headphone that showed older FR values even though the firmware had changed fixed EQ values etc.
But this new tool uncovered more subtle problems with FR e.g.
So, setting very high q values and measuring the differences in the curves:
I added a Zoom in feature to get a closer look at the error:
And I wrote an 'Insights' section to provide some analysis of what the problem might be ( this area is definitely one where I will be expanding as it only recognises a few specific cases at the moment):
So, in this case the problem is that FR where the filter is applied is slightly wrong e.g. 10000hz => 9775hz - I added some 'software' compensation in devicePEQ for this issue.
2. Sample rate calculation issue
This issue is sort of a side affect of most of the simpler usb-c dongle that have limited processing and for those devices a pre-calculate biquad filter is pushed. So, the walkplay protocol has a placeholder for pushing both the PEQ filters but also a set of biquad coefficients for the filters (but only for one sample rate). But I believe due to Nyquest theorem the calculations need to take into account the sample rate at runtime to get the correct curve at higher frequencies. Some devices actually push all possible biquad coefficients for all the sample rates the device supports, but these simpler usb-c dongle don't and I believe many default to 96Khz. The problem is if you assume the sample rate on one device (e.g. your PC) but use the dongle on a different device (with a different agreed sample rate) these filter shapes will be slightly wrong as you can see below:
I have a compensation calculation that tries to solve this issue but its not 100% accurate - though I will make some further attempts at having better compensation in the next few weeks.
Note: The newer 'walkplay' devices like the Protocol Max and the Tanchjim Space Pro - actually ignore the biquad pushed and recalcuate it dynamically based negioated sample rates each time the device connects, this is the best method. Most 'newer' protocols actually only take the PEQ filters and do the calculations on the hardware device itself so there is no confusion.
3. Different implements of LS and HS filters
This probably isn't a bug but I found some of the higher end FiiO devices that I have like the QX13 were failing while some of their cheaper devices like the Snowsky Melody passed all the tests. When I investigated the problem was that FiiO hardware teams are implementing either standard 'Q' values in the LS/HS filters or alternatively
So I went back to FiiO own 'control' application and tried these devices and separately measure the differences in the curves:
So, this is because FiiO higher end devices (like the QX13) implement 'RJB Q' filters instead of traditional 'Q' filters - but they don't distinguish in their software so I never noticed. I did send a email back to FiiO about this but I haven't heard anything back yet.
More details on these 2 alternative algorithms for Q values:
www.andyc.diy-audio-engineering.org
Note: I have seen this same confusion over the algorithm used for Q Values in many other devices, so as I detect the algorithm a device needs I will apply this same compensation that I have now in devicePEQ for the QX13.
Anyway, I will try and keep this thread up to date with other findings as I have only tested a small fraction of the devices I have with PEQ, so I imagine I will find other issues but I thought it would be good to at least introduce this tool and see if other people might find it useful.
Some background on devicePEQ in case people are interested
Note: I probably should do a full post someday describing how it works and the various devices and protocols supported, but for now here is very high level intro:
So what is devicePEQ?
It is a open source JS libary which was built it integrate into online measurements databases - it is the tool used by Crinacle on https://graph.hangout.audio and on many of the 'Squig.link’ implementations of Cringraph open source headphone / iem measurement databases.
What does it do?
It allows the user of the online measurement DB to read and write ( pull and push ) PEQ filters directly onto devices which have hardware implementations of PEQ. The idea was I want to make PEQ more popular and I felt part of the problem is often people hate exporting and importing files or even worse having to type lots of numbers manually into their hardware PEQ 'companion' App.
What devices does it support?
The Majority of USB PEQ devices ( e.g Crinear Protocol Max, Tanchjim Space Pro, Truthear KeyX, FiiO JA11, JCally JM12, Walkplay HiMax), some desktop devices (like FiiO K17, Topping DX5 MK2), some bluetooth TWS and Headphones and even some Network devices (including limited support for the WiiM devices and the Luxsin X9). I will be adding more devices. It has many features but typically it tries to recognise the device when it connects and detects the protocol to use (replicating the 'native' protocol of the device) and has a database of 'constaints' for each device ( number of PEQ filters, maxQ values etc).
I am using devicePEQ in this tool as the way to communicate to the 'device under test' !!
Rather than a separate application that people have to install, I thought this might be nice as a web application, so its located here =>
- it looks like this when you access the page:
Note: A side affect of using a browser was the access to the audio interfaces was more limited, so I first implement a way to use the REW API ( with an REW 'pro' license) but in the past week I implemented a 'built-in' implementation that only works in Chrome, Edge and other 'Chromium' based browsers. This new implementation will ask for some permissions to allow the page access the audio devices connected to your computer. It does try to remember these permissions and which audio devices where selected and it tries to be 'intelligent' about the device selection, picking the most appropriate ones available.
The process works as follows:
1. Connect your PEQ device under test
This need to be devices that my devicePEQ tool has a 'protocol' configured for ( which is most usb-c devices with PEQ and I do support other mechanisms). If I recognise the device I will print out the details and for devices which I have already build some 'compensation' for I will detail the compensation here ( an allow you to turn off the compensation to see the 'issues'):
You can see I had to apply 2 compensations for this specific Audio device - more details on this in the findings later.
2. Configure (if required) the correct audio 'Capture' interfaces (or the connection to REW and configure those within REW) and other settings.
It tries pick the right interface and save these for next time ( but you can always change them):
If you decide to use REW instead it looks like this where you can just verify that the REW API works:
3. Generate a baseline measurement - I reset the device PEQ to have 'no PEQ applied' and then test that the audio is correct and I will give errors if something is wrong and I read the bitrate during this process, I also gather the configured bitrate in this process.
Note: REW is obviously better if you are having problems so switch over to REW is you cannot take a baseline measurement with the built in audio capture.
If you are testing an usb-c enabled IEM (or headphone - they are coming) - you can also view this baseline FR:
4. Generate a 'test plan' ( I mostly use the 'constraints' I have configured in devicePEQ for the device under test so suitable min / max Q, dB and the ranges of values to generate the tests for)
You can toggle certain tests and edit the values if you want to try something other values - in this case there were 34 test generated:
5. Run the test plan: I do block access to the page while an individual test is running:
If something fails - you can view the FR differences and this is where I found a few issues that I will talk about next.
Note: I run a series of 'curve fitting' algorithms on the measured output, analysing the theoretical curve and comparing with the actual one measured and while I do allow some errors ( e.g. RMSE of 0.3% ) it does a reasonable good job of finding issues where the PEQ applied was not implemented exactly. But it is early days and I will hopefully refine these algorithms more over the next few months.
If you feel something was wrong you can also re-run failed tests e.g. you touched device or the cable during a test and changed something.
6. I then show the results - if something failed I show something like this:
If a device passes you get a nice notification:
How many pass? I will provide a more detailed list later but many of the simpler 'usb-c' dongles fail this test for reasons I will explain below. Will you hear those issues probably not unless you like high qValue filters but I thought it would be useful to at least show some of my initial findings. I have only tested about 10% of the PEQ devices I have currently, though I did try random devices with different protocols - so I imagine I have found most of the common problems, and I have implemented software 'compensations' where I can for these problems but I don't have a full list of devices which need those compensations.
And before I go further, I should thank many of the companies that sent me PEQ devices to test (and occasionally review), including FiiiO, CrinEar, Moondrop Labs, Tanchjim, EPZ, Topping, JDS Labs, Fosi Audio, JCally, WiiM, Luxsin and many others. And special thanks to TTGZ / Walkplay for explaining some of their product catalog, allowing me to 'group' similar devices easier.
Some initial findings using this tool. I found 3 'common' issues across a number of popular devices:
1. Incorrect FR applied to the filter:
This was something I had noticed even before I wrote this tool, I had seen this issue (when it was very obvious) with the manual EQ FR captures I used to include in reviews, e.g. some early KTMicro devices ( from Tanchjim and probably others ) applied the wrong FR depending on sample rate of the device you apply the filter, so if you saved the PEQ on a device that was running 96khz but ran it against a device with 48khz the value of the FR would be applied wrong. Another example was the companion app to a ANC headphone that showed older FR values even though the firmware had changed fixed EQ values etc.
But this new tool uncovered more subtle problems with FR e.g.
So, setting very high q values and measuring the differences in the curves:
I added a Zoom in feature to get a closer look at the error:
And I wrote an 'Insights' section to provide some analysis of what the problem might be ( this area is definitely one where I will be expanding as it only recognises a few specific cases at the moment):
So, in this case the problem is that FR where the filter is applied is slightly wrong e.g. 10000hz => 9775hz - I added some 'software' compensation in devicePEQ for this issue.
2. Sample rate calculation issue
This issue is sort of a side affect of most of the simpler usb-c dongle that have limited processing and for those devices a pre-calculate biquad filter is pushed. So, the walkplay protocol has a placeholder for pushing both the PEQ filters but also a set of biquad coefficients for the filters (but only for one sample rate). But I believe due to Nyquest theorem the calculations need to take into account the sample rate at runtime to get the correct curve at higher frequencies. Some devices actually push all possible biquad coefficients for all the sample rates the device supports, but these simpler usb-c dongle don't and I believe many default to 96Khz. The problem is if you assume the sample rate on one device (e.g. your PC) but use the dongle on a different device (with a different agreed sample rate) these filter shapes will be slightly wrong as you can see below:
I have a compensation calculation that tries to solve this issue but its not 100% accurate - though I will make some further attempts at having better compensation in the next few weeks.
Note: The newer 'walkplay' devices like the Protocol Max and the Tanchjim Space Pro - actually ignore the biquad pushed and recalcuate it dynamically based negioated sample rates each time the device connects, this is the best method. Most 'newer' protocols actually only take the PEQ filters and do the calculations on the hardware device itself so there is no confusion.
3. Different implements of LS and HS filters
This probably isn't a bug but I found some of the higher end FiiO devices that I have like the QX13 were failing while some of their cheaper devices like the Snowsky Melody passed all the tests. When I investigated the problem was that FiiO hardware teams are implementing either standard 'Q' values in the LS/HS filters or alternatively
So I went back to FiiO own 'control' application and tried these devices and separately measure the differences in the curves:
So, this is because FiiO higher end devices (like the QX13) implement 'RJB Q' filters instead of traditional 'Q' filters - but they don't distinguish in their software so I never noticed. I did send a email back to FiiO about this but I haven't heard anything back yet.
More details on these 2 alternative algorithms for Q values:
Parametric Equalizer "Q" Definitions and Bandwidth
For audio PEQ filters, the difference between various definitions of the 'Q' parameter and their relationship to the half-gain bandwidth is discussed.
www.andyc.diy-audio-engineering.org
Note: I have seen this same confusion over the algorithm used for Q Values in many other devices, so as I detect the algorithm a device needs I will apply this same compensation that I have now in devicePEQ for the QX13.
Anyway, I will try and keep this thread up to date with other findings as I have only tested a small fraction of the devices I have with PEQ, so I imagine I will find other issues but I thought it would be good to at least introduce this tool and see if other people might find it useful.
Some background on devicePEQ in case people are interested
Note: I probably should do a full post someday describing how it works and the various devices and protocols supported, but for now here is very high level intro:
So what is devicePEQ?
It is a open source JS libary which was built it integrate into online measurements databases - it is the tool used by Crinacle on https://graph.hangout.audio and on many of the 'Squig.link’ implementations of Cringraph open source headphone / iem measurement databases.
What does it do?
It allows the user of the online measurement DB to read and write ( pull and push ) PEQ filters directly onto devices which have hardware implementations of PEQ. The idea was I want to make PEQ more popular and I felt part of the problem is often people hate exporting and importing files or even worse having to type lots of numbers manually into their hardware PEQ 'companion' App.
What devices does it support?
The Majority of USB PEQ devices ( e.g Crinear Protocol Max, Tanchjim Space Pro, Truthear KeyX, FiiO JA11, JCally JM12, Walkplay HiMax), some desktop devices (like FiiO K17, Topping DX5 MK2), some bluetooth TWS and Headphones and even some Network devices (including limited support for the WiiM devices and the Luxsin X9). I will be adding more devices. It has many features but typically it tries to recognise the device when it connects and detects the protocol to use (replicating the 'native' protocol of the device) and has a database of 'constaints' for each device ( number of PEQ filters, maxQ values etc).
I am using devicePEQ in this tool as the way to communicate to the 'device under test' !!
