Hi folks,
I've searched the forum but didn't find an edaquate answer to my question.
Is there someone who can tell me the difference between Linux and Windows when it comes to audio quality?
I don't know if it's just placebo effect or reality, but I do think that there is a (slightly, depends) better quality on Linux in combination with good hard- and software of course.
But I want to be sure, so guys, help me with your experience and (hopefully) explanations.
Sincerely,
Telepath
If it is about delivering the bits unaltered to a DAC, no reason to expect any difference.
If it is about active manipulation of the data e.g. resampling, they do differ
http://archimago.blogspot.com/2015/11/measurements-windows-10-audio-stack.html
Hi folks,
I've searched the forum but didn't find an edaquate answer to my question.
Is there someone who can tell me the difference between Linux and Windows when it comes to audio quality?
I don't know if it's just placebo effect or reality, but I do think that there is a (slightly, depends) better quality on Linux in combination with good hard- and software of course.
But I want to be sure, so guys, help me with your experience and (hopefully) explanations.
Sincerely,
Telepath
There is absolutely no difference between Linux & Windows in audio quality if you do all of the audio processing yourself. If you depend upon the internal libarires, then as they say 'Your Miliage will Vary.' For my DolbyA compatible decoder project, I use Linux for development, and compile the user's version for Windows on a Windows' box.
Talking about performance and responsiveness (not audio quality):
For low level, very aggressive development, Linux is a LOT faster for the developer, but for using pre-built libraries/GUI things/etc, then Windows tends to be better. For extreme responsiveness under load -- Linux is pretty damned good. I actually wrote the FreeBSD VM system many years ago, and because of the incredibly efficient allocation of memory resources, I could run Xwindows in 4MB (yes, MEGA, not GIGA.) The 'unix' clones like Linux (and nowadays lesso FreeBSD) are amazing. FreeBSD wins on low overhead for simple applications. Windows is a big monstrosity that really needs to be pruned down to be most effiicent.
All in all -- the most important thing about performance isn't so much the OS, but the libraries, how the code is written, and the kinds of CPUs (and nowadays if you have an SSD.)
However, to answer the original question -- if all of the HW is the same, and you use EXACTLY the same code, and do all of hte processing software yourself -- Linux and Windows are the same quality.
John
Hi folks,
I've searched the forum but didn't find an edaquate answer to my question.
Is there someone who can tell me the difference between Linux and Windows when it comes to audio quality?
I don't know if it's just placebo effect or reality, but I do think that there is a (slightly, depends) better quality on Linux in combination with good hard- and software of course.
But I want to be sure, so guys, help me with your experience and (hopefully) explanations.
Sincerely,
Telepath
There is absolutely no difference between Linux & Windows in audio quality if you do all of the audio processing yourself. If you depend upon the internal libarires, then as they say 'Your Miliage will Vary.' For my DolbyA compatible decoder project, I use Linux for development, and compile the user's version for Windows on a Windows' box.
Talking about performance and responsiveness (not audio quality):
For low level, very aggressive development, Linux is a LOT faster for the developer, but for using pre-built libraries/GUI things/etc, then Windows tends to be better. For extreme responsiveness under load -- Linux is pretty damned good. I actually wrote the FreeBSD VM system many years ago, and because of the incredibly efficient allocation of memory resources, I could run Xwindows in 4MB (yes, MEGA, not GIGA.) The 'unix' clones like Linux (and nowadays lesso FreeBSD) are amazing. FreeBSD wins on low overhead for simple applications. Windows is a big monstrosity that really needs to be pruned down to be most effiicent.
All in all -- the most important thing about performance isn't so much the OS, but the libraries, how the code is written, and the kinds of CPUs (and nowadays if you have an SSD.)
However, to answer the original question -- if all of the HW is the same, and you use EXACTLY the same code, and do all of hte processing software yourself -- Linux and Windows are the same quality.
John
Thank you!
So, do write it down, it isn't important if I use Windows or Linux?
I really like "deadbeef", which looks like a real lossless audio player for me.
I am currently using Windows 7 with Foobar2k, but I heard that the audiomixer for windows is shit.
Because of this I started this topic.
If you don't like the mixer, bypass it
https://www.foobar2000.org/components/view/foo_out_wasapi
I recall having said it before but I'll say it again. That archimago's Windows resampler test is somehow done incorrectly.
Here's my results of resampling 19 & 20 kHz sine signals from 44.1 kHz to 96 kHz using the Windows resampler:
Through analog loopback:
(https://i.imgur.com/YzfzUt2.png)
(https://i.imgur.com/VY5JYgF.png)
And purely digitally:
(https://i.imgur.com/pfgGwcX.png)
(https://i.imgur.com/s4hWfGh.png)
Edit: For completeness' sake here's white noise through the sampler too:
Analog:
(https://i.imgur.com/StKLq8z.png)
Digital:
(https://i.imgur.com/k8c9IZB.png)
Surprisingly good results for the noise as its true peaks are 6 dB above full scale so it will distort a lot without lowering amplitude.
Conclusion is that the resampler in Windows 10 is superb.
Attached is the 19 & 20 kHz sine file I made and used:
The main gripe of GNU/Linux is that pulseaudio took over but it's not production ready yet. It often decides it's time to get out of control and starts glitching, sometimes even completely obliterating the sound when only harsh noise comes out. (Or maybe it's also caused by bugs in drivers for my card; damned vendors care about Windows first and Linux support is an afterthought if done at all, afaik most drivers are reverse engineered by community)
But when all this drama doesn't happen, there should be no audible difference at all. The only thing that could cause audible differences (without completely breaking stuff) is resampling and both (can) do it good enough to be transparent.
Thanks for all the clarifications. I just placebo heared, that with a latence modified arch linux kernel, deadbeef audio player and a good lossless material, the sound quality is better than on Windows.
Windows 7 has a "not so good" audio mixer, of course its possible to bypass, but Idk, I am not satisfied with the out of the box sound on Windows.
Windows 10 is a whole different thing, but when it comes to audio I thought linux would be better.
Thanks for your engagement and clarifications.
The main gripe of GNU/Linux is that pulseaudio took over but it's not production ready yet.
There are still distros where you can choose not to use it.
The main gripe of GNU/Linux is that pulseaudio took over but it's not production ready yet. It often decides it's time to get out of control and starts glitching, sometimes even completely obliterating the sound when only harsh noise comes out. (Or maybe it's also caused by bugs in drivers for my card; damned vendors care about Windows first and Linux support is an afterthought if done at all, afaik most drivers are reverse engineered by community)
I think this is very likely a driver issue. I have not had a single issue with Pulseaudio in years, on multiple machines with onboard audio, USB DACs, S/PDIF output, DisplayPort/HDMI output, you name it.
Back when I
did have issues, that was on a pretty old Arch installation where I had manually installed PulseAudio on top of ALSA and manually kinda-sorta made everything work. On subsequent installs of Ubuntu, Mint and Neon, everything has just worked perfectly out of the box, and the only tweak I've done has been to change the resampling method.
Just as a reminder, let’s leave commentary about sound quality that is not derived from proper scientifically contolled tests out of the discussion please.
Refer to rule #8 in our terms of service if there are any questions.
I think this is very likely a driver issue. I have not had a single issue with Pulseaudio in years, on multiple machines with onboard audio, USB DACs, S/PDIF output, DisplayPort/HDMI output, you name it.
Perhaps I am extremely unlucky. Sounds sometimes breaks down both for built-in soundcard on the mobo, and an external USB DAC (which main function is to record guitar but I tested how it could work for output because I can).
By the way do you think it's worth it to try replacing the kernel with some kind of "realtime" versions as described here https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel to see if it makes the problem less frequent at least?
There are still distros where you can choose not to use it.
Idk if this is a good investment of time to try different distros now, I have too low IQ (and so I chose the "easiest" way because of that) so it'll probably take too much time. Maybe I'll do some testing from live images without installing, AFAIK they should work exactly as the "real thing".
Just as a reminder, let’s leave commentary about sound quality that is not derived from proper scientifically contolled tests out of the discussion please.
This one isn't about quality though; when sound completely disappears or becomes replaced with noise very vaguely resembling what it should have been. Am I right?
What reample-method is used in your /etc/pulseaudio/daemon.conf file? If you use speex-float-NUMBER then don't use 10 or 9 if your computer is not to fast because it can cause dropouts. Another option is to try the tsched method that you can find if you search for "pulseaudio tsched".
Perhaps I am extremely unlucky. Sounds sometimes breaks down both for built-in soundcard on the mobo, and an external USB DAC (which main function is to record guitar but I tested how it could work for output because I can).
By the way do you think it's worth it to try replacing the kernel with some kind of "realtime" versions as described here https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel to see if it makes the problem less frequent at least?
That does sound very strange, and I'm afraid it's not something where I am aware of an easy solution. Maybe it's some sort of hardware conflict, maybe something particular to your hardware. I'm not sure what the best venue for help is, if the Ubuntu forums aren't helpful.
I don't think a realtime kernel will help, this seems like something else.
Perhaps I am extremely unlucky. Sounds sometimes breaks down both for built-in soundcard on the mobo, and an external USB DAC (which main function is to record guitar but I tested how it could work for output because I can).
By the way do you think it's worth it to try replacing the kernel with some kind of "realtime" versions as described here https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel to see if it makes the problem less frequent at least?
That does sound very strange, and I'm afraid it's not something where I am aware of an easy solution. Maybe it's some sort of hardware conflict, maybe something particular to your hardware. I'm not sure what the best venue for help is, if the Ubuntu forums aren't helpful.
I don't think a realtime kernel will help, this seems like something else.
This is an anecdote about my own situation. I use one of those USB plug-in headphone amplifiers. It works great, except the Linux volume controls initially worked very poorly. Basically, the specific USB headphone amp that I use isn't quite 100% supported (It is an audioengine D3 -- I think.) Anyway, I found a driver/kernel patch to fix the volume control issue, and every kernel that I update to needs the patch. They still don't support it in the mainline kernel, but being a kernel developer of one kind or another since the late 1970's, it is no biggie for me to patch the kernel. (I update to the latest Linux development kernel -- way ahead of normal releases -- about once a month, unless I am in play-with-kernel mode, then I do it over and over again.) Bottom line is that Linux does tend to have spotty support for less than 100% mainstream HW, but when it does have support, it is usally either pretty good, or passable.
Windows is really good when you just want something to work -- perhaps suboptimally, perhaps more slowly, or perhaps irritatingly esp when the system is doing one of those irritating upates, but it does work most of the time.
Linux is really good if you want something that works knifedge-good. I mean, it will generally give you everything that your CPU and system can give you in performance, and when the software works -- it is second-to-none. However, Linux does often require care and feeding unless you choose hardware that is well known by the developers.
I LIKE using Linux (I wish it was FreeBSD, but that is ancient history), and I am generally satisfied when I use it because I am not usually waiting or frustrated because of an eccentric or poor design concept (e.g. Windows being infested with Belady's anomaly for a decade before being improved.)
I tolerate using Windows because it is what a lot of people use, and they are happy with it. If I write a piece of software, I will be able to benefit more people if I write it to be able to run on Windows.
It would be nice if the world used a Unix clone, and there was a super good GUI from day one so that more people would have been able to adopt it early on. We don't live in that world...
Just as a reminder, let’s leave commentary about sound quality that is not derived from proper scientifically contolled tests out of the discussion please.
This one isn't about quality though; when sound completely disappears or becomes replaced with noise very vaguely resembling what it should have been. Am I right?
This was a general comment not necessarily directed at any particular person, though those who haven't perused our terms of service, and I mean the real definition of perused (https://www.merriam-webster.com/dictionary/peruse), should take notice.
What reample-method is used in your /etc/pulseaudio/daemon.conf file? If you use speex-float-NUMBER then don't use 10 or 9 if your computer is not to fast because it can cause dropouts. Another option is to try the tsched method that you can find if you search for "pulseaudio tsched".
/etc/pulse/daemon.conf
resample-method = soxr-hq
avoid-resampling = true
and my PC is really fast anyway so this should be no problem for it. also the problem happens when playing audio which is already at 48000hz sample rate, which is the default sample rate set in that config too.
it uses tsched already; I tried disabling tsched, and it only becomes worse, producing noise 100% of the time (not only sometimes like when the tsched is used which is the default in my version of pulseaudio)
Conclusion is that the resampler in Windows 10 is superb.
Interesting. I wish someone who knows how (I don't), could run the test signals on the FAQ page for the Infinitewave SRC site.
http://src.infinitewave.ca/faq.html
They have Apple Core Audio and afconvert represented there. Would be interesting to see Windows there as well.
Interesting. I wish someone who knows how (I don't), could run the test signals on the FAQ page for the Infinitewave SRC site.
http://src.infinitewave.ca/faq.html
They have Apple Core Audio and afconvert represented there. Would be interesting to see Windows there as well.
Sorry, I meant to say run and submit the test signals. Also I didn't realize the FAQ url was an unnavigable endpoint. The test files are also available on the FAQ page (lower left button) from here: http://src.infinitewave.ca/ if anyone has time to do this for the Windows resampler.
I submitted results there.
I submitted results there.
Thank you Case. I've been expecting it to show up there for years, and now it finally will.
At http://src.infinitewave.ca/ there is an entry for "fooBar2000", another for foo_dsp_resampler and one for dBpoweramp Music Converter 5.1. As a layperson, I'm not sure what the 1 KHz test tone results really show. There's a marked difference between the three. I wish I knew how to interpret these types of results. I expected all three to be similar. Perhaps one is out of date, or there's a problem? Could anyone kindly explain what's going on and why?
The old fooBar2000 entry is from PPHS resampler, foo_dsp_resampler is lvqcl's SoX-based component, and the dBpoweramp entry is from the new tweaked SSRC resampler. Same resampler can be found in foobar with name Resampler (dBpoweramp/SSRC).
The old fooBar2000 entry is from PPHS resampler, foo_dsp_resampler is lvqcl's SoX-based component, and the dBpoweramp entry is from the new tweaked SSRC resampler. Same resampler can be found in foobar with name Resampler (dBpoweramp/SSRC).
Thanks. Good to know. I assume then that the dBpoweramp resampler is the preferred one?
One downside it has is that it's very slow. And if you use foobar2000 there are other resamplers that have signal extrapolation to help prevent glitches on gapless track transitions. Though latest foobar2000 can circumvent that if you tick the "Don't reset DSP between tracks" checkbox. But that further slows down conversion as it gets limited to single thread. Also some people claim too sharp transition can cause audible ringing. Though I don't believe that, the frequencies are way too high already at 44.1 kHz sampling rate.
Perhaps I am extremely unlucky. Sounds sometimes breaks down both for built-in soundcard on the mobo, and an external USB DAC (which main function is to record guitar but I tested how it could work for output because I can).
By the way do you think it's worth it to try replacing the kernel with some kind of "realtime" versions as described here https://help.ubuntu.com/community/UbuntuStudio/RealTimeKernel to see if it makes the problem less frequent at least?
That does sound very strange, and I'm afraid it's not something where I am aware of an easy solution. Maybe it's some sort of hardware conflict, maybe something particular to your hardware. I'm not sure what the best venue for help is, if the Ubuntu forums aren't helpful.
I don't think a realtime kernel will help, this seems like something else.
This is an anecdote about my own situation. I use one of those USB plug-in headphone amplifiers. It works great, except the Linux volume controls initially worked very poorly. Basically, the specific USB headphone amp that I use isn't quite 100% supported (It is an audioengine D3 -- I think.) Anyway, I found a driver/kernel patch to fix the volume control issue, and every kernel that I update to needs the patch. They still don't support it in the mainline kernel, but being a kernel developer of one kind or another since the late 1970's, it is no biggie for me to patch the kernel. (I update to the latest Linux development kernel -- way ahead of normal releases -- about once a month, unless I am in play-with-kernel mode, then I do it over and over again.) Bottom line is that Linux does tend to have spotty support for less than 100% mainstream HW, but when it does have support, it is usally either pretty good, or passable.
Windows is really good when you just want something to work -- perhaps suboptimally, perhaps more slowly, or perhaps irritatingly esp when the system is doing one of those irritating upates, but it does work most of the time.
Linux is really good if you want something that works knifedge-good. I mean, it will generally give you everything that your CPU and system can give you in performance, and when the software works -- it is second-to-none. However, Linux does often require care and feeding unless you choose hardware that is well known by the developers.
I LIKE using Linux (I wish it was FreeBSD, but that is ancient history), and I am generally satisfied when I use it because I am not usually waiting or frustrated because of an eccentric or poor design concept (e.g. Windows being infested with Belady's anomaly for a decade before being improved.)
I tolerate using Windows because it is what a lot of people use, and they are happy with it. If I write a piece of software, I will be able to benefit more people if I write it to be able to run on Windows.
It would be nice if the world used a Unix clone, and there was a super good GUI from day one so that more people would have been able to adopt it early on. We don't live in that world...
Aside from that, I've found that video drivers tend to react VERY poorly with USB audio; both are high-bandwidth, low-latency applications, and the video driver will naturally want to hog everything and as a higher-class citizen, gets that. When a major video driver update screws up your audio, your choices are basically hack the kernel or hope for the best and try not to trigger it. I've had the same USB DAC since 2006 (Turtle Beach Roadie, now called SRM) and the ins and outs of it working well could fill a very boring novel. The worst was a year or so when just scrolling anything on Windows would cause audio stutter. Driver developers really aren't good at playing well with other drivers.
On windows there are tools like DPC Latency Checker or LatencyMon to diagnose such problems.
Funny, I never experienced the stuttering sound after so much uptime on my desktop under Linux. I have experienced stuttering sound, but it's usually from certain Windows apps run under Wine.
Aside from that, I've found that video drivers tend to react VERY poorly with USB audio; both are high-bandwidth, low-latency applications, and the video driver will naturally want to hog everything and as a higher-class citizen, gets that. When a major video driver update screws up your audio, your choices are basically hack the kernel or hope for the best and try not to trigger it. I've had the same USB DAC since 2006 (Turtle Beach Roadie, now called SRM) and the ins and outs of it working well could fill a very boring novel. The worst was a year or so when just scrolling anything on Windows would cause audio stutter. Driver developers really aren't good at playing well with other drivers.
AFAIK threading has been supported for long time and other drivers should not be able to fsck up others anymore. Scrolling could cause stuttering if process priority of scrolling app is higher than audio apps.
https://d2.alternativeto.net/dist/s/20646eb1-fc4b-df11-82d2-0022190f5762_2_full.gif?format=gif&width=1600&height=1600&mode=min&upscale=false
Even this kind of peaking should not affect audio with Win 7 and newer, maybe even Vista.
AFAIK threading has been supported for long time and other drivers should not be able to fsck up others anymore. Scrolling could cause stuttering if process priority of scrolling app is higher than audio apps.
https://d2.alternativeto.net/dist/s/20646eb1-fc4b-df11-82d2-0022190f5762_2_full.gif?format=gif&width=1600&height=1600&mode=min&upscale=false
Even this kind of peaking should not affect audio with Win 7 and newer, maybe even Vista.
That period was under Windows 8.1, which was otherwise an excellent OS, but the Intel video driver's IRQs simply overrode the audio's instead of playing nicely. They fixed it after a little over a year; it magically went away with one driver update. It has nothing to do with process priority; the GDI and DirectDraw/Direct2D calls run in the kernel and realtime drivers.
I submitted results there.
Hi Case, thanks again for doing this, but do you know if it's there yet? I've looked under Windows and Microsoft and don't see anything new there, and the last updated still says July 17, 2018. Maybe it's normal, but I thought I'd seen results appear there sooner in the past.
http://src.infinitewave.ca/
[...] foo_dsp_resampler is lvqcl's SoX-based component[...]
Its test results being so similar to those of Audacity 2.03's is entirely down to coincidence, or is this humble layman here just seeing too much?
The graph of AIMP 3.60 is also similar to Audacity and foo_dsp_resampler.
Both Audacity and AIMP use libsoxr, so it's hardly surprising.
Yeah, I'd innitially suspected that was down to library sharing.
Edit:
@lvqcl , since you're online ATM, there's this question I've been meaning to ask regarding the SoX Resampler.
Shall I PM you or post it over the FB2K forum?
@includemeout - yes.
I mean, forum is preferrable.
Cool. I guessed so, before your edition. :D
For future reference, here it is (https://hydrogenaud.io/index.php/topic,117191.msg967381/topicseen.html#new).
Hi Case, thanks again for doing this, but do you know if it's there yet? I've looked under Windows and Microsoft and don't see anything new there, and the last updated still says July 17, 2018. Maybe it's normal, but I thought I'd seen results appear there sooner in the past.
I expect them to email me when the results are posted. But I think the people updating the site wait for more results and do them in batches.