Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Parametric Equalizer for PulseAudio (github.com/keur)
119 points by keurrr on Sept 25, 2020 | hide | past | favorite | 50 comments



Looks and works great - it's simple to use and very intuitive. Very useful for badly recorded lectures, to filter out the crowd.

I hope you can add a bit of polish to integrate better into OS. On XFCE the program has a nice-looking icon showing in Notification Area (system tray), but in Window Buttons (taskbar) it has a generic icon. It cannot be minimized or hidden, it can only be closed.


After using it some more, I have to say tweaking the spectrum while the music is playing is fun! Far better experience than dozen sliders found in graphic equilizers.


That makes me so happy to hear! Since this thread is getting less active, feel free to email me at kevin@segfault.fun if you need anything else.


Is the Jack aware at all? This is a pretty nice looking eq and more eq plugins are always a handy tool to have. Needing to use the pulseaudio bridge for an eq makes it difficult to use in production setup with a chain of Jack input/outputs though.


Being Jack aware would be a bonus but there are already a multitude of Jack aware EQ plugins. The feature-set of this prettyeq plugin seems aimed specifically at system-wide audio, in other words to adjust the audio on your system to match your daily use preferences, rather than production work. I might never use this sort of EQ (high-pass, lo-pass, 5 peaks) for production work. Maybe for tweaking a final mix... pulseaudio is definitely in need of some nicely integrated audio filters. Jack has many to choose from, but more are always welcome.

Edit: I am not an audio pro and if this EQ is in fact aimed at production, I would love to learn more about its use cases


This is pretty accurate. I wrote it to tweak songs to my speakers when I'm streaming music. I wanted something very fast, no configuration, pleasant graphics.

While probably not suited for production work, the design is based off of existing production tools that I am very familiar with (Channel EQ from Logic Pro X, Parametric Eq 2 from FL Studio).


If I need to do any kind of DSP i'd much rather insert a VST plugin into the chain using Carla or similar. Way more generic and less tied to Pulse that way and usually superior in engineering.



Any way to set pre-amp to avoid clipping or is there built-in headroom / automatic gain adjust so that that is taken care of by default?


So my background is I did music production in high school. I actually based the design for PrettyEQ off of the Logic Pro X equalizer and Fruity Parametric EQ 2, and those will happily let you clip. So I like the idea of leaving that to the user's discretion (move the filters slowly, especially in the lows and highs, and know your speakers well). These days, especially in EDM / Hip Hop, slight clipping in bass in somewhat stylistic. So I don't know. Maybe could be an option in the GUI that could be switched on? Would need to think about it more.


> These days, especially in EDM / Hip Hop, slight clipping in bass in somewhat stylistic.

No it's not, it's just widespread incompetence and has ruined lots of music I would have liked. Having better software tools that alert when clipping is happening would be a good thing (i.e. it needs to alert when crossing over from 0dB to a distorted wave form, not just hitting 0dB without distorting, which is fine).


You know you can distort without clipping and can clip without blowing out your meters?


> clip without blowing out your meters

If the audio clips, and the meter doesn't "blow out", then in my opinion that is a defective meter.

ALSA already has an eq plugin (http://quitte.de/dsp/caps.html#Eq10) and I added this to it:

                if ((s > +0.99 && x[z1] > +0.99 && x[z2] > +0.99) ||
                    (s < -0.99 && x[z1] < -0.99 && x[z2] < -0.99) ) {
                        //clipped audio isn't exactly 1.
                        printf ("dsp/Eq.h:process(): input clipped :(\n");
                }
....

                if (
                    (r >= 1.0 || r <= -1.0) &&
                    (r < 20 && r > -20)) { //uninited memory?
                        printf ("dsp/Eq.h:process(): output clipped :( %0.16f\n", r);
                }
(one day I should try to get upstream to accept that or something like it...)


If you feel strongly about clipping, I would also accept a patch that allows a user to select an option in the GUI to prevent it.


Yes, I have strong feelings about clipping... For many years I was using the track Moby - Inside trying to find a hifi system or headphones that could play it without sounding crap, then discovered it couldn't be because it's clipped.

And thanks but I'm happily using my patch on a pure alsa system without pulse audio, and don't really have the time to spend on adding the equivalent to yours sorry. But I'd want to if only to spread awareness about clipping - it's not just music, there are also many Youtube channels that I unsubed from because of it (I did tell them but they didn't care).

Actually preventing clipping instead just detecting it (which mine does) is a lot of work - it would need to find the loudest frequency, then find the closest band and reduce that (while loudly informing the user, and oviously with an option to control it).


If the equalization is done near the end of the audio output chain (ex: music player, defaults at 100% volume -> user sets master audio output volume to 50% -> EQ is applied) then a pre-amp is not strictly necessary if the EQ can take advantage of the extra headroom in the output channel. Otherwise, an adjustable pre-amp / gain setting would be nice, preferable with the option for it to automatically set itself to reduce by the maximum gain the EQ is applying to avoid clipping. But yeah, it should be optional; if the user wants stuff to clip, let it clip.


Does this use vector extensions where available?


Not by hand, but the FFT I wrote for the spectral analyzer is compiled with -ffast-math and gcc vectorizes it (verified with objdump). Same thing with the functions that change the filter parameters.


> is compiled with -ffast-math and gcc vectorizes it

Automatic vectorization is extremely limited, in all compilers.

Check this out, feel free to merge if it works in reality not just in the test: https://github.com/Const-me/prettyeq/tree/master


Thanks. I actually found your repo before seeing this post and sent you an email. Definitely going to port it back to C and merge it in. Thanks so much for this. Hand vectorizing this was on my TODO.


fftw3 is extremely fast and vectorized well. Why write your own FFT implementation?

Did you test against pulseeffects cpu usage?


I can't link with fftw3 since it's GPL. The other libraries that were permissive licensed had confusing APIs and the output binaries were almost as large as my entire project. CPU usage is high but because of one poorly designed part of the GUI (eqhover.cpp)


Surely there's one in here that would be acceptable. https://community.vcvrack.com/t/complete-list-of-c-c-fft-lib...


I'm not sure I understand, why can't you use GPL code?


I can’t statically link with it because I would need to release my own software under the GPL.


Why not license your software under the GPL? For end-user applications like these, there's no reason software shouldn't be GPL, and if fact it would be better for you since it prevents companies from exploiting your work that you intended to serve the greater good for purposes of their own profit.


> Why not license your software under the GPL?

If OP did that, I probably wouldn’t bother to improve their code: https://github.com/Const-me/prettyeq/tree/master

While my primary motivation was “for lulz”, possibility to reuse the code whenever I need a fast 1D FFT also contributed.


note that from our recent experience adding AVX to Ardour's existing SSE hand-written vector code, gcc is now able to generate SIMD code that essentially matches the performance of the hand-written versions.



you likely want -O3 -march=native if building for your own machine, this way you get more than the SSE2 baseline if available


Love this, great job, will join to contribute.. Would be very interested in getting >2.0 channel support. Great job again


Cool, yeah. Would love if you contributed that. So off the top of my head we would want to get all output sinks and display them in the GUI and, when the user switches, detect the number of channels they support and live configure to that. We would need to update the null sink, sample_spec struct, and latency. This would live in equalizer/pretty.c so that's a good place to poke around.

Email me at kevin@segfault.fun if you have any questions. The pulseaudio C API can be a bit... opaque :)


This is a neat project, but I'm still using PulseEffects, which appears to be more fully featured: https://github.com/wwmm/pulseeffects


oh, global compressor. Sounds god sent for badly mixed movies.


I was just looking for a replacement for the app I used on Mac: Boom.

I will give this a try tomorrow!


Yes please, that buggy piece of...


It’s turned in to nagware.


how do I build this? (there doesn't seem to be a Makefile)?

very promising. have been looking for a pulseeffects replacement for some time.


QMake, probably (it's a Qt program and there's a `.pro` file in the root)


a thanks, silly me. I wondered what that was.


Any CLI planned?


I'd like to know the same thing. I'm currently using PulseEffects [0] for my parametric eq needs, but as I use a dedicated PC to play music, it's a bit of a pain to have to connect via vnc to control it.

[0] https://github.com/wwmm/pulseeffects


Hah, pulseeffects was why I wrote this project. It has tons of latency, very sluggish UI, not nice to use.


I'm not personally into cli stuff, but most of the code in the equalizer/ directory could be used without much change. If anyone started that project and needed assistance I would for sure help out.


I have an HTPC hooked up to my speakers in my living room that I often SSH into in order to play music while I work, hence the need for a CLI EQ.


How does one use this?


In the project directory run:

mkdir ./make ./build

cd ./make

qmake CONFIG+=release ..

make -j<cthread_count>

mv ./prettyeq ../build


Thanks!

First try I got: equalizer/equalizer.pro:10: Parse Error ('pretty.h')

Then I removed the extra pretty.h line and got: ../../gui/prettyshim.h:4:10: fatal error: QObject: No such file or directory #include <QObject>

which is beyond my time to dig right now :/


I didn't forget about you! I did a release statically linked with qt5. Let me know if this works for you. Email me at kevin@segfault.fun if you run into any issues. Use prettyeq-static.

https://github.com/keur/prettyeq/releases/tag/v0.2-alpha


Oh, you need the qt5 shared libs to compile. I am planning to do a release in the next couple weeks that statically links the full thing so no one has to deal with this. Qt makes it very annoying to static link your project (you are stuck compiling Qt yourself), so been putting that off.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: