Since speakers we use for sabers have frequency range from 250 Hz to 20 kHz mostly, and won’t play frequencies below 200 Hz. Should filtering provide better sound and be safer for the speaker?
Would that reduce the chance of blown speakers?
The short answer is yes, but the cutoff frequency may differ from speaker to speaker. Also, if you have an audio out of some sort, the filtering will be unhelpful.
The ideal solution would be if proffieos could do the filtering at run time. That way you could have per-saber control over the cutoff frequency, and you could have unfiltered sound for spider output. I’m not sure how much cpu that would eat up though.
If I implement it, I will make it optional of course. I just have to figure out how to calculate filter coefficients first. 
4 Likes
Dmitry, have you listened to the same font, one high passed and one straight, on the same setup back to back? I’m interested in someone other than myself defending this practice. I have seen some “font reviews” where the sound is just blown out of the water distorted with waaaay too much bass…and they’re saying “ooo listen to that punch!” or something similar, meanwhile I’m cringing and crying for the poor speaker and the muddy fuzz it’s being forced to put out.
The low end being rolled off makes the sound so much cleaner. Even though the speaker can’t reproduce the lows directly, they influence all the other frequencies both directly and harmonically, basically 'getting in the way" with large, slow cone movements in the middle of another frequencies waveform.
Nobody would send subwoofer audio to a midrange or tweeter in any other audio application…why would it be ok to do in a saber?
1 Like
We probably should be looking into algorithms like MaxBASS or similar too, which can produce bass sounds without the fundamental frequency so that they can be played on a smaller speaker.
1 Like
Or maybe hardware filtering on the speaker amplifier output?
Simplest form, sure.
In simplest form, sure. Somewhere around a 200-400μF capacitor on one of the legs would be a basic HP filter.
True, but it would be a first-order filter, which means that the transfer-function slope would not be very steep. Basically, to filter out all the 100Hz frequencies, we would also filter out half the 200Hz frequences and half the 400Hz frequencies, which might not be what we want. Personally I think digitial filtering would be better.
I did some reading on how to build butterworth filters, so I might give that a try.
1 Like
If the possibility will be onboard digital filters, will there be a config entry for this to edit the parameters? Like:
eq-FILTER_120
Where you can fine tune the filter and adjust it per saber? I’m sure most people would want to keep some low frequencies intact if they have a large enough speaker to handle it, and would be nice to able to actually put in roll of frequency values here so it can be fine tuned per saber.
My current idea is to specify the filter cutoff frequency and filter order in the config file.
Higher orders means steeper rolloff, but at a higher cpu cost.
The filtering will be based on biquad filters of some sort, and those filters actually have the ability to implement pretty much any kind of filter. With some additional work, full equalization would be possible. (but the filter order and cpu usage would go up.)
If real-time filtering is possible, I’d like to revisit the idea of dipping the sound when you use push.wav. Filtering the low-mid ranges would make the effect sit so much better when it happens.
Ducking and filtering has nothing in common though. Seems like something that should be (and have been) discussed in a separate thread.
This is interesting…
Most of the time, digital filtering is done by using matlab to calculate the filter coefficients, and then you use a well optimized biquad implementation to make it run fast.
What’s interesting is that for a highpass filter, 4 out of 6 coefficients turns out to be 1 or 2. That means that with a little bit of coding shenanigans I might be able to skip a whole bunch of multiplications.
Now I’m curious to see if fast this code will end up…
2 Likes
I know it isn’t ducking, but a bell curve filter on the other sounds would make the push/force effects sit better while they is active. From an audio mastering perspective, throwing samples out the speaker when there’s already loads going on just creates mud. Plus, it’d be like in CoD or whatever when you get suppressing fire and it sort of cuts all the audio back. Pretty sure Fallen Order has a similar effect when you use a Force ability.
A real-time filter could easily do this.
I set up an option in my prop to play select sounds monophonically. Works great.
In the initial implementation, the filter will be static, then we’ll see what else we can do with it.
First try uses 15% cpu for an 8th-order filter. I think I can do better though.
Turns out that I miscalculated.
My initial implementation uses about 28% cpu.
However, my second implementation uses 11% cpu…
No, miscalculated again.
It’s 3%. Too bad I don’t have a speaker right now, I can’t actually check if it works/sounds right.
1 Like
I checked it in, but I don’t know if it works properly or not.
New defines:
#define FILTER_CUTOFF_FREQUENCY 200
#define FILTER_ORDER 8
Filter order defaults to 8, but I will change that once we figure out what sounds the best.
2 Likes