• Welcome to ASR. 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!

Phonalyser: free open-source analyzer - THD, SNR/ENOB, frequency response, scope (+ QA40x support)

ENOB still differs (actually it's not dBFS/dBV more)

Might be from Peak versus RMS calculation, REW had the same bug years before and John corrected it, if I recall it correctly.
 
Ok, so far I have all fixed. I wait for some retest from other users and will prepare release 1.1.1
 
Is there a way to calibrate the input side to 0 dBFS?

Ivan specs Cosmos ADCiso at 0.5 dBFS and when I use the 4.5 Volts hardware range, the 0 dBFS voltage on my unit is actually 4.632 V (4.633 V already clips the input)

When I feed the 4.632 V in (With the standard 4.5 V range in the devices.yaml -file) , Phonalyser shows the signal as -0.44 dBFS and 12.63 dBV (Which is 4.28 V):

1785302150212.png


Both MultiTone Analyzer and REW show 0 dBFS signal with the same voltage:

1785302343318.png
1785302369749.png


When I edit the 4.5 V range in the settings to match the 0 dBFS voltage...

1785302554775.png


... it only changes the label in the devices.yaml -file:

1785302711231.png


And when I manually edit the range to 4.632 with Notepad...

1785302927332.png


... it still shows -0.44 dBFS with 4.632 V input signal, but now it changes to 12.88 dBV, which is 4.405 V. (It was 12.63 dBV before editing the devices.yaml -file)

1785303007032.png



Is there a way to get Phonalyser to show 0 dBFS and 13.31 dBV? (Or is it 13.32 dBV when rounded correctly...)
 
Last edited:
Is there a way to calibrate the input side to 0 dBFS?

Ivan specs Cosmos ADCiso at 0.5 dBFS and when I use the 4.5 Volts hardware range, the 0 dBFS voltage on my unit is actually 4.632 V (4.633 V already clips the input)

When I feed the 4.632 V in (With the standard 4.5 V range in the devices.yaml -file) , Phonalyser shows the signal as -0.44 dBFS and 12.63 dBV (Which is 4.28 V):

View attachment 547858

Both MultiTone Analyzer and REW show 0 dBFS signal with the same voltage:

View attachment 547859 View attachment 547860

When I edit the 4.5 V range in the settings to match the 0 dBFS voltage...

View attachment 547861

... it only changes the label in the devices.yaml -file:

View attachment 547862

And when I manually edit the range to 4.632 with Notepad...

View attachment 547863

... it still shows -0.44 dBFS with 4.632 V input signal, but now it changes to 12.88 dBV, which is 4.405 V. (It was 12.63 dBV before editing the devices.yaml -file)

View attachment 547864


Is there a way to get Phonalyser to show 0 dBFS and 13.31 dBV? (Or is it 13.32 dBV when rounded correctly...)
The text for ranges in audio preferences is only the label, which doesn't make sense to edit - it simple corresponds to the labels on DIP switches on Cosmos ADC bottom.
The values which you have changed manually (left: 4.632, right: 4632) actually better to calibrate. The calibration procedure is described in help, but is actually very simple.
This is help of web version but it is very similar to java DAC calibration & ADC calibration
You put on the Cosmos input left or right signal and measure it RMS, signal should be > 0.5V RMS. Start oscilloscope, wait as statistic is collected (default 5s) and you see in measurement table average Vrms for selected channel (L/R channel buttons in the top left corner switch channel for measurement table) if it differs from what you have measured - open Utility tab under scope and click calibration button
1785306406974.png
in opened calibration dialog you enter measured with multimeter RMS voltage and it will be saved automatic for selected channel selected range (if sound card has selectable ranges like Cosmos). The same procedure must be done for DAC: you generate some signal, measure output voltage RMS using multimeter and calibrate generator. It has same button on the bottom of the pane. After calibration all measured voltage and dBV values will correspond reality.

P.S. In version 1.1.1 dBFS values will be possible to enter in all amplitude fields in generator, frequency response and tune notch.
 
The text for ranges in audio preferences is only the label, which doesn't make sense to edit - it simple corresponds to the labels on DIP switches on Cosmos ADC bottom.
The values which you have changed manually (left: 4.632, right: 4632) actually better to calibrate. The calibration procedure is described in help, but is actually very simple.
This is help of web version but it is very similar to java DAC calibration & ADC calibration
You put on the Cosmos input left or right signal and measure it RMS, signal should be > 0.5V RMS. Start oscilloscope, wait as statistic is collected (default 5s) and you see in measurement table average Vrms for selected channel (L/R channel buttons in the top left corner switch channel for measurement table) if it differs from what you have measured - open Utility tab under scope and click calibration button View attachment 547869 in opened calibration dialog you enter measured with multimeter RMS voltage and it will be saved automatic for selected channel selected range (if sound card has selectable ranges like Cosmos). The same procedure must be done for DAC: you generate some signal, measure output voltage RMS using multimeter and calibrate generator. It has same button on the bottom of the pane. After calibration all measured voltage and dBV values will correspond reality.

P.S. In version 1.1.1 dBFS values will be possible to enter in all amplitude fields in generator, frequency response and tune notch.

Thanks!

After the calibrarion the line is now: (I only calibrated the left channel and edited the label back to 4.5V)

- { label: "4.5V", fsVrms: { left: 4.633475147401744, right: 4.5 }, calibrated: true }

The oscilloscope -view is now:

1785308595933.png


But the FFT -view is still -0.45 dBFS and 12.87 dBV:

1785308661069.png


It changed only from -0.44 dBFS to -0.45 dBFS and from 12.88 dBV to 12.87 dBV, so I could have manually edit the devices.yaml -file to get the same results.

What I am doing wrong?
 
Thanks!

After the calibrarion the line is now: (I only calibrated the left channel and edited the label back to 4.5V)

- { label: "4.5V", fsVrms: { left: 4.633475147401744, right: 4.5 }, calibrated: true }

The oscilloscope -view is now:

View attachment 547877

But the FFT -view is still -0.45 dBFS and 12.87 dBV:

View attachment 547878

It changed only from -0.44 dBFS to -0.45 dBFS and from 12.88 dBV to 12.87 dBV, so I could have manually edit the devices.yaml -file to get the same results.

What I am doing wrong?
Do you use a sine wave? Measured in scope 4.628 corresponds ~13.308dBV. ADC full scale is 4.633... -> 13.318dBV. So the FFT should show -0.01 dBFS and 13.31 dBV.
FFT shows about 0.44dB less. What I can imagine is following reasons:
  • you have used in FFT frequency locked loop (FLL) and as generator frequency ligns to FFT bin exactly on ADC )FFT) side it can be that already collected averages gets power leakage from fundamental and it can differs from real values somtimes very string > 6-8dB and more. After FLL aligns freuqency software analyse if fundamental magnitude has significant changed and suggested (blinking text in top right corner) to reset FFT statistic (red counter-clockwise arror): "⚠ Level shifted during alignment — reset statistics"
  • as I don't see real signal on scope and spectrum on FFT I can imagine, that the signal is so noise or THD is so big, that 0.44dB of tthe signal is spreaded to noise/harmonics.
  • and I have made following experiment: Generator - 1kHz, FFT siz 16k, windows Hann, samplerate 384k - one bin is therefore ~11.7 Hz. If generator frequency is not snapped on FFT bin and lands somwhere between bins in my case 33%/66%. Correspondinf FFT bins are 996.09Hz and 1007.8Hz. I get measured fundamental 0.65dB less as it is in reality. Scope shows 2V RMS 6dBV and FFT 5.37dBV
Maybe I have lost something else. But I would suggest first reset FFT statistic first.

So my suggestion for precise FFT measurement: in generator check "Snap frequency on FFT bin", in FFT - "Get fundamental from generator" & "Align generator": FLL.
And after ΔF lands in sub PPM range:
1785311033031.png


Calibration in oscilloscope can still varying from FFT by 0.01-0.1dB if signal is noisy or distorted, cause multimeter ans scope measure whole signal, where FFT measure pure frequency bin. Therefore calibration on ADC side is only possile if signal > 0.5V with premise, that noise or distortions are so small, and can't strong impact calibration process. Arbitrar multimeter can relative good measure RMS only for pure sine wave.
 
Do you use a sine wave? Measured in scope 4.628 corresponds ~13.308dBV. ADC full scale is 4.633... -> 13.318dBV. So the FFT should show -0.01 dBFS and 13.31 dBV.
FFT shows about 0.44dB less. What I can imagine is following reasons:
  • you have used in FFT frequency locked loop (FLL) and as generator frequency ligns to FFT bin exactly on ADC )FFT) side it can be that already collected averages gets power leakage from fundamental and it can differs from real values somtimes very string > 6-8dB and more. After FLL aligns freuqency software analyse if fundamental magnitude has significant changed and suggested (blinking text in top right corner) to reset FFT statistic (red counter-clockwise arror): "⚠ Level shifted during alignment — reset statistics"
  • as I don't see real signal on scope and spectrum on FFT I can imagine, that the signal is so noise or THD is so big, that 0.44dB of tthe signal is spreaded to noise/harmonics.
  • and I have made following experiment: Generator - 1kHz, FFT siz 16k, windows Hann, samplerate 384k - one bin is therefore ~11.7 Hz. If generator frequency is not snapped on FFT bin and lands somwhere between bins in my case 33%/66%. Correspondinf FFT bins are 996.09Hz and 1007.8Hz. I get measured fundamental 0.65dB less as it is in reality. Scope shows 2V RMS 6dBV and FFT 5.37dBV
Maybe I have lost something else. But I would suggest first reset FFT statistic first.

So my suggestion for precise FFT measurement: in generator check "Snap frequency on FFT bin", in FFT - "Get fundamental from generator" & "Align generator": FLL.
And after ΔF lands in sub PPM range: View attachment 547896

Calibration in oscilloscope can still varying from FFT by 0.01-0.1dB if signal is noisy or distorted, cause multimeter ans scope measure whole signal, where FFT measure pure frequency bin. Therefore calibration on ADC side is only possile if signal > 0.5V with premise, that noise or distortions are so small, and can't strong impact calibration process. Arbitrar multimeter can relative good measure RMS only for pure sine wave.

Yes, I use the 1 kHz sine. I don't think it's too noisy, THD+N is around -119 dB with REW and Multitone and around -116 dB with Phonalyser (With -0.5 dBFS, with 0 dBFS I'm using now for testing, it's slightly worse, but still better than -110 dB. I use the reduced voltage on the DAC and use the Cosmos Scaler to pump the voltage to the 0 dBFS of Cosmos ADC, only for testing now. THD+N gets of course better when using the full signal of the DAC and no Scaler, but the signal won't reach the 0 dBFS of Cosmos ADC that way...).

I was using the "Snap frequency to nearest FFT bin" already before. I reseted FFT statistic and activated the "Get fundamental from generator" -selection. It made it closer to 0 dBFS, but it resynced many times and the phase noise around the fundamental increased:

1785312492410.png


This is without the "Get fundamental from generator": <EDIT>: Made a new measurement with 32 averages to avoid the "Over 55-averages" -bug to show correct noise and scaled it again to match better the previous graph with phase noise </EDIT>

1785313871448.png
 
Last edited:
Yes, I use the 1 kHz sine. I don't think it's too noisy, THD+N is around -119 dB with REW and Multitone and around -116 dB with Phonalyser (With -0.5 dBFS, with 0 dBFS I'm using now for testing, it's slightly worse, but still better than -110 dB. I use the reduced voltage on the DAC and use the Cosmos Scaler to pump the voltage to the 0 dBFS of Cosmos ADC, only for testing now. THD+N gets of course better when using the full signal of the DAC and no Scaler, but the signal won't reach the 0 dBFS of Cosmos ADC that way...).

I was using the "Snap frequency to nearest FFT bin" already before. I reseted FFT statistic and activated the "Get fundamental from generator" -selection. It made it closer to 0 dBFS, but it resynced many times and the phase noise around the fundamental increased:

View attachment 547901

This is without the "Get fundamental from generator": <EDIT>: Made a new measurement with 32 averages to avoid the "Over 55-averages" -bug to show correct noise and scaled it again to match better the previous graph with phase noise </EDIT>

View attachment 547903
Decisive here is not "Get fundamental ..." it shows only ΔF. It makes no more. Decisive is "Align generator" - it changes DDS frequency slightly to align precisely with FFT.
Suspecting is wide fundamental lobe skirt (what you marked with red circle). You use relative narrow window BH7 and such wide skirt can mean only huge power leackage.
It can happen if very first FFT frame was made on signal with discontinuity and further collection don't pass the comparison gate and will be rejected. Also suspected is that you have multiple re-sync. Please wait on next version. I have fixed some backend problems and now soundcard exclusive mode should work. I have a lot of new features and a lot of fixes in it.
I have almost everything implemented and I'am in test phase now. I hope to end of the week new release, now maybe 1.2.0 (due to one big feature), will be released.
 
I found it!

Somehow the sampling rate of the Cosmos ADC was changed to 48 kHz in the Phonalyser settings, even it was 44.1 kHz on the Control Panel. I must have rolled the mouse wheel by accident when hovering above the sample rate selection.

It still shows the increased phase noise around the fundamental time to time (No every time although) when using the "Get fundamental from generator" -selection, but now the levels are ok:

1785316929008.png


The 0.02 dB difference comes from the temperature difference of the devices between the measurements. (This was without the "Get fundamental from generator" -selection)

Thanks for the support and I'm sorry for the unnecessary trouble for you!
 
Last edited:
Please wait on next version. I have fixed some backend problems and now soundcard exclusive mode should work. I have a lot of new features and a lot of fixes in it.
I have almost everything implemented and I'am in test phase now. I hope to end of the week new release, now maybe 1.2.0 (due to one big feature), will be released.

Sounds great! I will definitely test it.
 
I found it!

Somehow the sampling rate of the Cosmos ADC was changed to 48 kHz in the Phonalyser settings, even it was 44.1 kHz on the Control Panel. I must have rolled the mouse wheel by accident when hovering above the sample rate selection.

It still shows the increased phase noise around the fundamental time to time (No every time although) when using the "Get fundamental from generator" -selection, but now the levels are ok:

View attachment 547909

The 0.02 dB difference comes from the temperature difference of the devices between the measurements. (This was without the "Get fundamental from generator" -selection)

Thanks for the support and I'm sorry for the unnecessary trouble for you!
I should thank you for testing the app. I can't be 100% confident, that everything works correct. Therefore I try to understand for your posts and posts other user what is maybe wrong.
 
Sooo, finally I have made next release 1.2.0.

I want made bugfix release 1.1.1, but it contains now multiple new features, therefore 1.2.0.
Can be usable for all - I have implemented headless server, which consumes about 27MB RAM. It can be run on all platforms:
  • Windows x86, x64
  • Linux x64, aarch64
  • Macos x64, aarch64
Each server has embedded web app and can be used on any more powerfull machine from Google Chrome. But also Java GUI can communicate with the server.

Java GUI can see all server in network segment, while server uses multicust beacon. Web clients except embedded must be connected to server once manually.

Server uses HTTP & WebSocket and can be proxied or be used behind reverse proxy.

To use in internet it is not secure. There is not HTTPS and/or authentication. I plan to add it later.
Besides that I think I have implemented almost all wiches and fixes you asked.

New version is accessible Phonalyser 1.2.0

Project page: https://dgo42.github.io/Phonalyser/
MS Store as usual in 1-2 days after
 
Sooo, finally I have made next release 1.2.0.

I want made bugfix release 1.1.1, but it contains now multiple new features, therefore 1.2.0.
Can be usable for all - I have implemented headless server, which consumes about 27MB RAM. It can be run on all platforms:
  • Windows x86, x64
  • Linux x64, aarch64
  • Macos x64, aarch64
Each server has embedded web app and can be used on any more powerfull machine from Google Chrome. But also Java GUI can communicate with the server.

Java GUI can see all server in network segment, while server uses multicust beacon. Web clients except embedded must be connected to server once manually.

Server uses HTTP & WebSocket and can be proxied or be used behind reverse proxy.

To use in internet it is not secure. There is not HTTPS and/or authentication. I plan to add it later.
Besides that I think I have implemented almost all wiches and fixes you asked.

New version is accessible Phonalyser 1.2.0

Project page: https://dgo42.github.io/Phonalyser/
MS Store as usual in 1-2 days after

Thanks!

Windows 10 doesn't support unsigned MSIX packages (You can bypass the requirement on Windows 11). I managed to get the plain Java version to run, but it could be useful to get the traditional installer too, just like it was on V1.1.0
 
WASAPI still only offers 16-bit output depth:

1786169968274.png


I managed to get the 32-bit depth working by manually editing the preferences.yaml -file from:

1786170289589.png


to:

1786170331921.png


With WASAPI there is no more the "More than 55 averages" -bug, which I had with JavaSound. With WASAPI Phonalyser calculates 128 avarages (And more...) correctly now.

And now the average-counter is working correctly too! 128 averages is 128 now, not 127...
 
The output amplitude control now has a dBFS -scale (Thanks for that and it works too!), but it reverts back to Volts every time when you shut down and start up Phonalyser again.

The tooltip doesn't advertise the new feature at all:
1786171737277.png

And when you enter manually 0 dBFS to the text field, it changes it to -0 dBFS when you hit ENTER (Doesn't affect the measurent, though) and when you use the up and down arrows, it goes like:

...
-2 dBFS
-1 dBFS
-0 dBFS
0 dBFS

When you click your mouse somewhere else, it keeps the 0 dBFS setting now, but I think that the -0 dBFS value is unnecessary.
 
Last edited:
Windows 10 doesn't support unsigned MSIX packages (You can bypass the requirement on Windows 11). I managed to get the plain Java version to run, but it could be useful to get the traditional installer too, just like it was on V1.1.0
MSIX is built to sign it in MS Store and it is already available: https://apps.microsoft.com/detail/9nr1w5dkw71m
WASAPI still only offers 16-bit output depth:
It's maybe due to csjsound library not available. Please try select JavaSound and look on available devices it you see devices with "EXCL: " prefix. If not - csjsound library is not in path for java app.
And when you enter manually 0 dBFS to the text field, it changes it to -0 dBFS when you hit ENTER (Doesn't affect the measurent, though) and when you use the up and down arrows, it goes like:

...
-2 dBFS
-1 dBFS
-0 dBFS
0 dBFS

When you click your mouse somewhere else, it keeps the 0 dBFS setting now, but I think that the -0 dBFS value is unnecessary.
I will take a look. It was so much fixes, that this small issue I have overlooked...
Thank you for report
 
WASAPI still only offers 16-bit output depth:
One more question: please switch to JavaSound backend and check what sample rates and bit depth will be provided for that DAC. If you see correct values - than I know what going wrong with WASAPI
Also found what is -0dBFS :). App stores always Vrms and for field it converts it to dBFS. Sure there is always convertion error and using rounding during convertion keep the sign :facepalm:. I change this behavior - I made first rounding and the format value for field - then - will gone.
 
Last edited:
One more question: please switch to JavaSound backend and check what sample rates and bit depth will be provided for that DAC. If you see correct values - than I know what going wrong with WASAPI

Also found what is -0dBFS :). App stores always Vrms and for field it converts it to dBFS. Sure there is always convertion error and using rounding during convertion keep the sign :facepalm:. I change this behavior - I made first rounding and the format value for field - then - will gone.

Here it is:

1786184976389.png

1786185023505.png

1786185106889.png
 
I suggested this already before, but would it be hard to make these units (N, THD, THD+N etc.) switchable to dB too?

1786185454867.png
 
Back
Top Bottom