-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
Beta Test: Earful -- a hearing test App
- Thread starter pkane
- Start date
OP
- Thread Starter
- #42
Thank you, @pkane , it is working for me now!(I'm too tired to run through the test tonight, but I verified that v1.0.4 works on my computer.)
Good to hear, @Hugo9000 ! Thanks for testing. I speeded up signal generation by about 3x compared to the previous version, mostly by eliminating a lot of floating point computations. My suspicion is that the large number of floating point computations was causing the slow-down with older processors, or ones without a floating point co-processor.
I see but on my i5 6600K, with all the possible instructions sets available, was struggling while on the Celeron N4100 with very low performance and limited istructions sets available all went smooth.
Back on topic.
I was able to take a quick measurements on the IEMs, sticking the UMIK-1 on top of the memory foam and have a decent sealing for reading the SPL. On my test I have around 90dB(A) SPL with the singnal at 0dBFS which translates into 11dB SPL at ~1100Hz on my graphs/results.
I also did an RTA measure with pink fullrange noise on the IEMs with the same method; it is not compliant with our hearing capabilities but it is useful to show the IEMs linearity and for the graph itself, I suppose. I'll share it later.
OP
- Thread Starter
- #44
That I can't explain. Four cores being used at 100% with a fast processor seems like an impossibility with Earful. I guess there may be some hidden bug/infinite loop I'm not aware of that causes this. In any case, in my testing with the latest changes, CPU utilization is down significantly compared to where it was, even with a fast processor:
Before optimizations:
After:
My experience on the i5 6600K is better but it still uses ~35% of CPU (with affinity on one core it reaches 100% usage easily while playing a test tone; with affinity on two cores it stays as said around 35% CPU usage) with 192kHs in WASAPI exclusive. I also tried with 44.1kHz always in WASAPI (exclusive or shared) and I have the same CPU load as with 192kHz test tones.
Note aside. I used it OCed at 4400MHz.
I encountered another issues: when moving the slider from-to the last 3/2 points it reset the values back to -60 (or -70 when I set the lowest value/Start vol to -120). Once happend that when I loaded my results and moving the slider throguh the data, it all went back to the value I set on the Start vol.
Back on my measurements for some reasons it set the dB SPL improperly (it happened often) in my first try so I check it again; looking at the ISO curve too to be sure I could have negative values too, and at around 1100Hz I now have a value of -9 dB SPL indeed.
Here is the RTA of my IEMs on the UMIK-1 while pushing the foam tip on the mic for a proper sealing:
Note aside. I used it OCed at 4400MHz.
I encountered another issues: when moving the slider from-to the last 3/2 points it reset the values back to -60 (or -70 when I set the lowest value/Start vol to -120). Once happend that when I loaded my results and moving the slider throguh the data, it all went back to the value I set on the Start vol.
Back on my measurements for some reasons it set the dB SPL improperly (it happened often) in my first try so I check it again; looking at the ISO curve too to be sure I could have negative values too, and at around 1100Hz I now have a value of -9 dB SPL indeed.
Here is the RTA of my IEMs on the UMIK-1 while pushing the foam tip on the mic for a proper sealing:
Hugo9000
Addicted to Fun and Learning
I used my Sennheiser HD 660S, no EQ. I'm "over 50" (lol), and can't hear anything over 15 kHz. I increased the total steps to 64, just to get a little more detail on the upper frequency curve. The highest tone I could hear with 64 steps was 14393 Hz. The next step was 16061 Hz, and I don't think any volume adjustment would allow me to discern tones in that range, so I didn't think it was worthwhile increasing gain on my Atom and starting over. I think when I was 45 I could still hear 16 kHz. At the bottom of the range, I couldn't hear the 20, 22, or 24 Hz tones with the gain setting I was using. It was already quite a bit higher than I normally set it, so I didn't want to go higher still. My 660s are weak on sub-bass, anyway. With my HD 58X I could hear down to 20 Hz on the same settings with a quick test.
I'll probably try one of my closed-back headphones next, either my KEF Space One or NAD Viso HP50. I do have Equalizer APO and the auto-EQ corrections (Oratory settings, I think for all but the KEF) for most of my headphones, so I could try testing with EQ as well.
Here are the results with Sennheiser HD 660S and no EQ:
I'll probably try one of my closed-back headphones next, either my KEF Space One or NAD Viso HP50. I do have Equalizer APO and the auto-EQ corrections (Oratory settings, I think for all but the KEF) for most of my headphones, so I could try testing with EQ as well.
Here are the results with Sennheiser HD 660S and no EQ:
OP
- Thread Starter
- #47
Not sure I understand how to reproduce this. Can you please describe the sequence, one step at a time?
BTW, I just noticed that the audio library I'm using is creating more threads than I expected when playing using WASAPI. These threads are not using any CPU when I look at them (all sleeping) but their number keeps growing. I'll investigate, perhaps this is what's causing the excessive CPU consumption on different hardware.
OP
- Thread Starter
- #48
Negative SPL values are not unreasonable in this case. In fact, the ISO 226 standard curves show this, also (look at the lowest line which is the threshold of hearing at 0 Phons reaching to about -10dB SPL around 3-4KHz):
Here is what I do: I open Earful (it sets the default settings, max vol -20dBFS, min vol -60dBFS and -0,5 vol step), then load my curve and because of the default settings (max volume at -60dBFS) the last two datas have a different value (which is not -60dBFS tho but -20dBFS), so I adjust the max volume to 0dBFS and I go through the data with the slider and when I reach the last two data points they just and go on a random valume (in my case something like -37dBFS) and if you then change them again to 0dBFS and go back on the third to last and move to the second to to last it will go back down again. It also happens something similar if you just adjust the max volume before loading my data (with 0dBFS on the last two points; and with this I mean the 31th and 32th points, with the default settings of 32 points) then load it and go throught all the data til the last two points and they somehow will just go down to a different value (same edit: It displays the 0dBFS correctly but when you reach the position it just go lower, at -37dBFS in my case).
EDIT: and sometimes the Clear All button doesn't clear all the datas properly (mainly on the first point).
Yes, I was going to tell you that. I kept seeing number of threads going up and down while playing audio on Earful with WASAPI output.
OP
- Thread Starter
- #50
Got it! The data does get clipped when loading against the maximum volume setting to avoid exceeding it. I'll see if I can fix it so it gets properly displayed when you increase the the max setting. For now, you'll have to reload the data after adjusting maximum volume, assuming it was previously clipped.
The first data point after clearing data is set to the current volume on the volume slider. I'll fix this, as that's probably not what you'd expect, especially if you have a large subwoofer and the volume setting happened to be at 0dBFS
I found the issue with the extra threads. That's fixed now. I'll upload the updated version soon. Hope it resolves the performance issue with your tower computer.
Again, thanks a lot for all the testing and bug reporting!
Yes indeed but the issues is after adjusting the max vol and trying to get them back to 0dBFS.
And if you do it first, adjusting the max volume, and loading the curve it displays correctly but once you go on the point iself it sets to a different value. I hope I am not persistent; I just want to be sure you got it right ahah
Let's blow some woofersThe first data point after clearing data is set to the current volume on the volume slider. I'll fix this, as that's probably not what you'd expect, especially if you have a large subwoofer and the volume setting happened to be at 0dBFS
I found the issue with the extra threads. That's fixed now. I'll upload the updated version soon. Hope it resolves the performance issue with your tower computer.
Again, thanks a lot for all the testing and bug reporting!
You are welcome and I'll wait your update and test it.
If I have the opportunity I'll give a try with my AKG K712 Pro tonight.
PS: what about the screenshot option inside the program? And can you please show the number of the position on the right of the Current position: tag over the slider (because the slider is kinda misleading, at 32 it looks like is a 30
)?
OP
- Thread Starter
- #52
Earful is now updated to version 1.0.5 with the following changes:
- Fixed many audio threads created when moving around the chart
- Added a screen shot button
- Added current step counter display
- Fixed clearing the first data point when data is cleared by setting volume slider to starting volume
- Added saving current settings on exit and reloading on start
Just downloaded and have to report I still have problems with the data points/slider like before. Plus, but I didn't check before the fix, if you have cleared all the data and set one of the points and go back or forward then all the data points will be set to the one you firstly set (which could result in a bad experience for your ears or for your loudspeakers depending on the medium ).
The screenshot button works as expected instead (getting the graph sizes and limits as you see it; maybe on later interaction you can work on a fixed width and ratio to make it easily comparable between each tester, with X dB/decades REW-alike or some other scheme).
Again issues with the dBFS and dB SPL conformity; I am back on 11dB SPL at ~1100Hz with my previous data test instead of the minus value. But on a math standpoint it is correct this way/iteration: 90dB SPL at 0dBFS results in 11db SPL at -79dBFS. So I don't know what happened before and I checked both times the math unless I can't even do additions/subtractions anymore 
Looking forward for the threads fix by the way.
).The screenshot button works as expected instead (getting the graph sizes and limits as you see it; maybe on later interaction you can work on a fixed width and ratio to make it easily comparable between each tester, with X dB/decades REW-alike or some other scheme).
Again issues with the dBFS and dB SPL conformity; I am back on 11dB SPL at ~1100Hz with my previous data test instead of the minus value. But on a math standpoint it is correct this way/iteration: 90dB SPL at 0dBFS results in 11db SPL at -79dBFS. So I don't know what happened before and I checked both times the math
unless I can't even do additions/subtractions anymore Looking forward for the threads fix by the way.
Hugo9000
Addicted to Fun and Learning
This version puts my CPU below 1%, so that's a huge improvement for me!
I went ahead and did another full test, using my Sennheiser HD 660S again. I normally have my Windows volume at 100% and have my Atom set at 12 O'Clock on low gain. I left it at 12 O'Clock, but switched to high gain, and I was able to hear all the way down to 20 Hz. I was also shocked to find that I could actually hear 16 kHz! Not very well, of course. LOL I took a screenshot showing that frequency, and my threshold was at -24 dBFS with the high gain and volume setting I used this time. I listen almost exclusively to classical music, and there is really almost nothing going on at such frequencies so in the scheme of things, who cares, but I guess it's a sign that I've taken decent care of my hearing through the years haha!
Some other parts of the curve are different from my earlier results, but it might be from getting some rest, a quieter environment for session 2, or just that I was more careful about zeroing in on my absolute threshold at each test point. Or perhaps it's a result of high gain and a different volume knob setting and the headphone response, or a combination of all of the above lol.
As I was writing this reply, I remembered that this version had a screenshot feature that I didn't try, so I reopened the program. Although I had clicked "Clear All" before I closed it last, it opened with the curves from my last session, but moved the 20 Hz point back down to the starting volume of -60 dB (that's how it's intended to work, yes?).
I don't have a way to calibrate SPL, unfortunately, so I don't know how useful my results ultimately are.
Thanks so much for your work on this program, it's cool to see that my hearing is better than I realized, and extends pretty high for an older person haha! (I'm only 51, so who knows how much my hearing will deteriorate in the next few years. I think I've read that there is often a fairly large change in the early- to mid-50s and then steadily worse.)
I went ahead and did another full test, using my Sennheiser HD 660S again. I normally have my Windows volume at 100% and have my Atom set at 12 O'Clock on low gain. I left it at 12 O'Clock, but switched to high gain, and I was able to hear all the way down to 20 Hz. I was also shocked to find that I could actually hear 16 kHz! Not very well, of course. LOL I took a screenshot showing that frequency, and my threshold was at -24 dBFS with the high gain and volume setting I used this time. I listen almost exclusively to classical music, and there is really almost nothing going on at such frequencies so in the scheme of things, who cares, but I guess it's a sign that I've taken decent care of my hearing through the years haha!
Some other parts of the curve are different from my earlier results, but it might be from getting some rest, a quieter environment for session 2, or just that I was more careful about zeroing in on my absolute threshold at each test point. Or perhaps it's a result of high gain and a different volume knob setting and the headphone response, or a combination of all of the above lol.
As I was writing this reply, I remembered that this version had a screenshot feature that I didn't try, so I reopened the program. Although I had clicked "Clear All" before I closed it last, it opened with the curves from my last session, but moved the 20 Hz point back down to the starting volume of -60 dB (that's how it's intended to work, yes?).
I don't have a way to calibrate SPL, unfortunately, so I don't know how useful my results ultimately are.
Thanks so much for your work on this program, it's cool to see that my hearing is better than I realized, and extends pretty high for an older person haha!
(I'm only 51, so who knows how much my hearing will deteriorate in the next few years. I think I've read that there is often a fairly large change in the early- to mid-50s and then steadily worse.)
OP
- Thread Starter
- #55
Which problem was this? The glitching? I'm thinking that one really has to do with your hardware/device driver combination. There's now no extra threads and the CPU utilization is so low as to be barely noticeable.
The clipping due to the change in maximum volume setting is not fixed in this version. It'll take some effort to fix due to how the maximum volume is implemented. I'll keep it on the to-do list, but it'll have to wait a bit until I'm ready to rewrite some of the internal logic.
Don't think I'm able to reproduce this. I clear the data, then set any of the points to say -20dB then move forward/backward and none of the other points change from the start volume setting (-60dB). Is there some step I'm missing?
That's already in v1.0.5. Only one thread is created for audio playback at any time. This was fixed with an update to the latest version of the audio library.[/QUOTE]
OP
- Thread Starter
- #56
This version puts my CPU below 1%, so that's a huge improvement for me!
Excellent!
Actually, no. The first point should be whatever was in the measurement in the previous session. I'll fix it -- it defaults to the starting volume setting on start-up, and that caused it to get reset from the correct previous value.
That is the fun part with Earful: you can save your results and compare them a few years from now. I did that with the results I had from a couple of years ago, and interestingly, my hearing mostly didn't change, and I'm a number of years older than you are
My bad for not explaining myself properly. It is just about the datas on the graph that keep cheanging when it shoudln't .
It is related to the above. Try setting one in the middle and back or forward in a fast way yo the next/previous points and see what happens.
Could it also be that I am on the comma version and some data is in decimals with a comma separator and not a point?
I will look into it again then. I still have 33% CPU usage.
Gonna turn off my tower, turn on the laptop, attach everything to it, download the latest verion of Earful, install it and give it a go with the K712 Pro.
OP
- Thread Starter
- #58
Nope, still can't make it happen. I even switched to comma as the decimal indicator. You're saying you have to go quickly between points? Do you use the slider or the arrows when this happens?
Both. The slider glitches and some points are untouched while with the arrows on the left all the points are set on the same value being firstly set (can't recall exacly now, my tower is shut down and I am about to go to sleep; didn't even finish to test my headphones cause I wanted to go for the 64 points).
Very important note tho. WASAPI exclusive or well, the option to tick and enable it, doesn't work. It says in shared mode. Just checked while playing a tone on your program and watching a YT video.
Last edited:
OP
- Thread Starter
- #60
Sounds like the exclusive WASAPI might be an issue with your driver. I can launch two copies of Earful, the one that has exclusive access to the driver is the one that plays, the other one stops. When both are in shared mode, both tones are heard.
Does your Windows setting allow for exclusive mode for this driver? That has to be turned on before it'll work from any app:
Last edited:
Similar threads
