Personal (and heavily biased) opinion follows.

No, we don't need an equalizer. In 2016, it's an outdated concept in consumer audio world.

Equalizers are something too difficult for normal people (not audio engineers) to operate. And we shouldn't model our UI on Windows when there are better models. In fact, many high-end AV receivers don't have equalizers, and have a better UI for the tasks normally solved with equalizers in Windows.

The problem usually half-solved by an equalizer is bad room acoustics (room modes resonating on certain notes, and reflections) or bad speakers (that either resonate on some frequencies, or inadequately reproduce others, or, worse, distort mid-range when bass is present at all). An equalizer can somewhat flatten the amplitude response, but can do nothing with the phase response (which is critical if you want to have pin-point stereo imaging, not corrupted by room reflections). And the number of bands that a human can manage is too low for any adequate compensation of the room acoustic problems.

What I propose is to integrate "digital room correction" instead ("Audyssey" is one of the trademarks related to this subject). It relies on a set of measurements made with a known-flat omnidirectional microphone (receivers usually ship with such microphone). A corrective FIR filter is then built, which is convolved with the audio signal. This way, both amplitude issues and even some early reflections can be corrected. A microphone suitable for room correction can be obtained for as low as 30 EUR, and the math for calculating the filter is already available as open source: http://drc-fir.sourceforge.net/

A patch adding a "convolution" primitive to PulseAudio core and refactoring both the equalizer (if we decide to fix it) and module-virtual-surround-sink to use it would be welcome. The future room-correction module can then also use it.

(In reply to Alexander E. Patrakov from comment #1)
> No, we don't need an equalizer. In 2016, it's an outdated concept in
> consumer audio world.

Wrong.

You're talking about high-end AV-receivers and buying microphones and stuff...

Yet, personally I would simply be needing an equalizer for a simple Logitech 2.1 active PC speaker system, which connects directly to the analog speaker output of my mainboard's onboard soundcard.

That speaker system has too much bass even with the bass knob turned all the way down.

However, using the 10-band equalizer that is built into the Realtek HD Audio Manager on Windows, I can get the bass just right, by simply lowering the bass a bit on the 31 and 62 Hz slider of the equalizer. Simple as that.

Here's a screenshot of the equalizer in the Realtek HD Audio Manager on Windows:

http://www.sevenforums.com/attachments/sound-audio/305826d1392117211t-using-graphic-equaliser-realtek-audio-realtek-eq.jpg

There are lots of active PC speakers out there that can be made sound better through some simple adjustments in that equalizer.

So please don't say there would not be a need for an equalizer. That's simply wrong.

> Equalizers are something too difficult for normal people (not audio
> engineers) to operate. And we shouldn't model our UI on Windows when there
> are better models. In fact, many high-end AV receivers don't have
> equalizers, and have a better UI for the tasks normally solved with
> equalizers in Windows.

Wrong. See above. Please don't assume that most users are using high-end AV receivers or AV receivers at all.

Not having a proper system-wide equalizer available everywhere on Linux is a _major_ downside to Linux compared to Windows.

Seriously, not having a proper system-wide equalizer available on Linux would be one reason for me not to switch from Windows to Linux as a desktop operating system.

Regards

As for high-end AV receivers, you misunderstood me. If one is using such a receiver, then there is absolutely no need to use equalizer or room correction in PulseAudio. What I am saying is that we should provide, to users of simple active speakers, the functionality equivalent to that of a high-end receiver, not to that of a Windows driver.

But again, that's just my opinion, and if anyone sends patches that fix the equalizer, I promise to review them.

I currently have no plans to incorporate qpaeq as is into pavucontrol.  If it's functionality is reduced a bit (no stretching=increasing resolution of control bands), it can be done though but the plugin is not a first class citizen to PA and one of the reasons for that is the criticisms Alexander brings up, another being a dependency, module-dbus-protocol was stuck in limbo for a long time too.  Though I have to add that while he has pointed out several valid things, that list is over inflated - some I've addressed in conversation, some issues were never there (6a), (7, 10) for time varying filters, and I don't see why 9 is important (I use mine with video all the time... but there is a problem of subjectivity and I have some latency cancellation in mpv)

Anyway its long been on my todo list to fix many of these issues, and especially make the filtering much lower latency and parametrize it in terms of the device samplerates.  The good news is that I'm finally in a position to learn more [audio] time series signal processing (I specialize in image processing which is why I had made most of the mistakes Alexander points out) and the time might be there for it in the next year or so.  Things were quite bad for me before this year but it still remains on my mind daily, if that's any penance.

I'm not as experienced of an audio engineer as Alexander but I believe we still need to address the people who are too poor or lazy to get a microphone and do this setup, and also for devices like earphones and laptop/tablet speakers as well - since they don't have a fixed location of operation.  Equalizers do the next best job to DRC in a stationary setup, otherwise they may be the only common method.  But there is no computation of the filter coefficients - you fiddle with it till your happy, and that is inexact and error prone, unfortunately.  That's also why you need a real time UI for the bands or finding good settings takes far longer.

(In reply to Alexander E. Patrakov from comment #4)
> What I am saying is that we should provide, to
> users of simple active speakers, the functionality equivalent to that of a
> high-end receiver, not to that of a Windows driver.

Okay, I see, that sounds good. But would it also allow me to do such simple things as to lowering the bass a bit as described in the previous post for example?

> But again, that's just my opinion, and if anyone sends patches that fix the
> equalizer, I promise to review them.

Would there be any chance that fixing the equalizer or implementing high-end AV receiver audio correction into PulseAudio could be made a higher priority on the list of things to do for the PulseAudio maintainers?

Regards(In reply to Jason Newton from comment #5)
> I believe we
> still need to address the people who are too poor or lazy to get a
> microphone and do this setup, and also for devices like earphones and
> laptop/tablet speakers as well - since they don't have a fixed location of
> operation.  Equalizers do the next best job to DRC in a stationary setup,
> otherwise they may be the only common method.  But there is no computation
> of the filter coefficients - you fiddle with it till your happy, and that is
> inexact and error prone, unfortunately.  That's also why you need a real
> time UI for the bands or finding good settings takes far longer.

Fully agreeing.

(In reply to nw9165-3201 from comment #6)

> But would it also allow me to do such simple
> things as to lowering the bass a bit as described in the previous post for
> example?

The DRC-FIR project does allow setting the target response (use case: don't try to boost bad bass where this would only lead to distortions), but I'd guess that you would not need it because the microphone-based measurement will, by itself, reduce the bass by exactly the same amount as you want.

(In reply to Alexander E. Patrakov from comment #7)
> but I'd
> guess that you would not need it because the microphone-based measurement
> will, by itself, reduce the bass by exactly the same amount as you want.

Maybe it would, maybe it wouldn't..., so an equalizer would probably still be needed.

As already pointed out by Jason, an equalizer would be needed anyway for things like headphones for example, since a.) they mostly would not have a fixed location of operation and b.) you would probably not be able to properly measure those with a microphone anyway.

a.) would also be true for mobile speakers like those in notebooks and tablets or small portable speakers as already pointed out by Jason.

So, I guess having advanced audio correction with microphone measurement surely would be nice, but an equalizer still would be essential.

Regards

(In reply to Alexander E. Patrakov from comment #2)
> A patch adding a "convolution" primitive to PulseAudio core and refactoring
> both the equalizer (if we decide to fix it) and module-virtual-surround-sink
> to use it would be welcome. The future room-correction module can then also
> use it.

Note that you don't actually need this in core. You could have a shared util library in modules/ for this kind of thing as well. We do this for ALSA and the webrtc bits of echo-cancel (for different reasons) already.

By the way, if you want to see that the demand for an equalizer is definitely there, then just have a look at the comments over there:

http://www.webupd8.org/2013/03/install-pulseaudio-with-built-in-system.html
http://www.webupd8.org/2013/10/system-wide-pulseaudio-equalizer.html
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/932834

Regards

Noticed a typo in the documentation of the Equalizer:

https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Equalizer/

It says:

> Getting the GUI (pqaeq):

Should be "qpaeq" not "pqaeq".

Regards

Any update on this one?

Can anyone recommend any alternatives?

I am trying to use alsaequal at the moment, together with PulseAudio, on Xubuntu 16.04, but it doesn't seem to work :(.

I have followed the instructions from over there:

http://www.thedigitalmachine.net/alsaequal.html
https://wiki.archlinux.org/index.php/Advanced_Linux_Sound_Architecture#System-wide_equalizer

But adjusting alsaequal through alsamixer has no affect on the sound at all :(.

Could anyone help in setting up alsaequal together with PulseAudio? As an alternative for qpaeq? Would be much appreciated.

Can alsaequal actually even work together with PulseAudio?

Also, I saw  Alexander E. Patrakov was saying:

> https://lists.freedesktop.org/archives/pulseaudio-discuss/2014-March/020174.html
> A better replacement already exists in the 
> form of module-ladspa-sink + mbeq + veromix.

But veromix is not in the Ubuntu 16.04 repositories and there does not seem to be any PPA available for it for 16.04. Besides, veromix seems to be unmaintained anyway.

Anyone here who can help on an alternative to qpaeq?

Also, couldn't you just use this module-ladspa-sink + mbeq and add a GUI for it to pavucontrol?

Regards

Rereading a few points here, your primary issue with qpaeq/module-equalizer-sink was that it's not integrated into pavucontrol - right?  You would seek other equalizers without trying qpaeq/module-equalizer-sink for that functionality?  I bring the point up because you seem to want something that works now.  Is it a PyQt issue/avoidance?

There are some correctness issues as we've mentioned in the past before but otherwise, I'd say the equalizer is fine for day to day use assuming the numbers work out reasonably with sampling rates and latencies - YMMV of course.  From my glancing over this and your previous bug, it's not clear to me if you tried it to determine if they were problems for you.

Otherwise though, no - no improvements yet.  Still a project I actively think about, though and am slowly gaining knowledge I need to do a better implementation.

(In reply to Jason Newton from comment #13)
> Rereading a few points here, your primary issue with
> qpaeq/module-equalizer-sink was that it's not integrated into pavucontrol -
> right?
Yes, correct.

>  You would seek other equalizers without trying
> qpaeq/module-equalizer-sink for that functionality?  I bring the point up
> because you seem to want something that works now.
Well, I was using a rather low-end PC recently and noticed that qpaeq was causing stuttering audio and audio hickups in some circumstances. This might have been caused by the low-end hardware, but on the other hand, the Realtek equalizer which is built into the Realtek Control Panel on Microsoft Windows does not produce such issues when using the same hardware.

So this was somewhat frustrating.

Also, it's annoying that every time you reboot your PC, you have to launch qpaeq to bring your equalizer settings back.

> Is it a PyQt
> issue/avoidance?
No, not really.
 
> From my glancing over this and your previous bug, it's not clear to
> me if you tried it to determine if they were problems for you.
Yes, I understand your confusion.

Anyway, since Alexander E. Patrakov was saying:

> https://lists.freedesktop.org/archives/pulseaudio-discuss/2014-March/020174.html
> A better replacement already exists in the 
> form of module-ladspa-sink + mbeq + veromix.
I tried out another PulseAudio equalizer today, the one from 
psyke83, it also uses LADSPA and mbeq, see:

http://ubuntuforums.org/showthread.php?t=1308838

It seems to work fine (using it on a high-end Core i7-6700K at the moment though). And it actually even saves it's settings between reboots.

But on the other hand, there's also another thread which seems to suggest that qpaeq would have a better quality than mbeq, see:

http://ubuntuforums.org/showthread.php?t=1378087

Is that correct?

And since Alexander E. Patrakov said that LADSPA + mbeq would be a better than qpaeq, why don't you just make psyke83's equalizer the official PulseAudio equalizer and integrate that one into pavucontrol?

Regards

(In reply to nw9165-3201 from comment #14)
> (In reply to Jason Newton from comment #13)
> > Rereading a few points here, your primary issue with
> > qpaeq/module-equalizer-sink was that it's not integrated into pavucontrol -
> > right?
> Yes, correct.
> 
> >  You would seek other equalizers without trying
> > qpaeq/module-equalizer-sink for that functionality?  I bring the point up
> > because you seem to want something that works now.
> Well, I was using a rather low-end PC recently and noticed that qpaeq was
> causing stuttering audio and audio hickups in some circumstances. This might
> have been caused by the low-end hardware, but on the other hand, the Realtek
> equalizer which is built into the Realtek Control Panel on Microsoft Windows
> does not produce such issues when using the same hardware.
> 
> So this was somewhat frustrating.

There are some situations (I traced it mostly down to flash) that would cause stuttering in my own setups - as a work around, I let flash videos go to the direct output sink rather than the equalizer sink.  I realise that is not ideal in the long term.   QPaeq shouldn't be causing much cpu usage directly unless you're actively resizing it - equalizer cpu usage would show up under pulseaudio in any system monitor.  I developed and tested for years against an Intel i7 920 - you may or may not consider this low end hardware by today's standards.  It's certainly not an Intel Atom, though.  IIRC, I only used 7-13% CPU at 48khz - realize these numbers are aggregate to the pulseaudio process.

> 
> Also, it's annoying that every time you reboot your PC, you have to launch
> qpaeq to bring your equalizer settings back.

That is not necessary.  I think you just didn't have the modules listed in your config?  It will save and restore the last state it is/was in.  Provided your configs load the module, that is.  You should see some files containing the sink state under ~/.pulse, along with any presets.

> 
> > Is it a PyQt
> > issue/avoidance?
> No, not really.
>  
> > From my glancing over this and your previous bug, it's not clear to
> > me if you tried it to determine if they were problems for you.
> Yes, I understand your confusion.
> 
> Anyway, since Alexander E. Patrakov was saying:
> 
> > https://lists.freedesktop.org/archives/pulseaudio-discuss/2014-March/020174.html
> > A better replacement already exists in the 
> > form of module-ladspa-sink + mbeq + veromix.
> I tried out another PulseAudio equalizer today, the one from 
> psyke83, it also uses LADSPA and mbeq, see:
> 
> http://ubuntuforums.org/showthread.php?t=1308838
> 
> It seems to work fine (using it on a high-end Core i7-6700K at the moment
> though). And it actually even saves it's settings between reboots.
> 
> But on the other hand, there's also another thread which seems to suggest
> that qpaeq would have a better quality than mbeq, see:
> 
> http://ubuntuforums.org/showthread.php?t=1378087
> 
> Is that correct?
> 
> And since Alexander E. Patrakov said that LADSPA + mbeq would be a better
> than qpaeq, why don't you just make psyke83's equalizer the official
> PulseAudio equalizer and integrate that one into pavucontrol?

Better is in the eye of the beholder - Alexander has debunked a few things pertaining to aliasing being only a bad thing but mbeq doesn't fix everything and is only more correct in the strict sense of it's core dsp algorithm vs what is here now, in my opinion.

If somebody wants to do the work to make mbeq controllable from pavucontrol, I certainly won't stop them though.

Equalizers absolutely have a valid use case, and room correction / loudness curve compensation / dynamic range compression do not provide the same result or serve the same goal as an equalizer does.

Room correction exists to provide a baseline "flat" frequency response (mostly) irrespective of room and transducers; loudness curve compensation exists to provide good perceptual bass response at low listening volumes; dynamic range compression exists to provide good listening levels on high-dynamic range tracks at low listening volumes.  Equalizers exist to tailor the sound to the listener's ear aside from these other three technologies.

(An aside: it should not be our goal to philosophize about what the "proper way" for users to use their gear should be.  If the user wants an equalizer, give it to him.  The fact that some of us think equalizers are "not the right thing" — for *us* — does not mean equalizers are not the right thing for users, and does not serve as an excuse not to provide it.)

I would really like PulseAudio to incorporate an equalizer applet (like pavucontrol) in-tree, as well as fix the plumbing to get it to work correctly.  This is aside from the room correction software running on my receiver, which certainly gets me to "flat" down to 19 Hz, but won't get me to the bass I would like to have on certain tracks or during certain times of day, the bandpass I want to listen to certain podcasts, and the treble I'd like to cut on certain tracks.

Of course, it would also be phenomenal if PulseAudio could incorporate room correction, loudness curve compensation, and dynamic range compression, in particular if these technologies would work on encoded multichannel streams.  It'd save thousands upon thousands of dollars for high-end users.  I would not have had to buy an expensive receiver if that was the case.

If you're desperate for an equalizer, you could do it at the Alsa layer.  It's more or less needed for iMacs along with other things.

https://bugs.freedesktop.org/show_bug.cgi?id=98377

(In reply to Dylan Taft from comment #17)
> If you're desperate for an equalizer, you could do it at the Alsa layer. 
> It's more or less needed for iMacs along with other things.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=98377

That sounds interesting. But how would you do that? The link that you've posted doesn't seem to explain it? In the link that you've posted it looks like one would need to install something to do it on the ALSA layer?

I guess the equalizer section on the ALSA page in the Arch Linux Wiki explains it:

https://wiki.archlinux.org/index.php?title=Advanced_Linux_Sound_Architecture&redirect=no#System-wide_equalizer

?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/515.