Me as +1...😎
With usb audio friendly devices, usb class compliant ... all ought to be but many, especially those designed for windows and delivered with custom asio drivers, don't...😡
Sadly I haven't had ANY success with > 2 channel USB audio on the Pi B or Pi 2. Real bummer since I had hoped to use them for cheap miniDSP alternative. I think that Intel fanless computers are the best bet for say, digital crossovers when you want to do more novel stuff than a MiniDSP.
Charlie, what you are doing sounds AWESOME!! I have thought about this many times. Even a multiband compressor would work to some extent. In any case the Xmax plugin will have to be last in the chain before a fixed gain output.
Forgetting about the change in TS parameters with excursion for now... what info does the plugin need to ensure that Xmax (or Xlim if you're feeling dangerous) is not exceeded?
- box model (volume, ports)
- driver TS parameters
- actual SPL calibrated sweep measurement at 1"
- desired low frequency response curve
Think that's it?
Last edited:
Well, have been trying without success for two years, but it seems that 2016 will be the year... I have no idea about it didn't work before, and works now for me. How long ago did you try...btwthese guys seem to make changes they don't tell anything about to anybody, and audio seems to be the least of their priorities, even to announce they have finally done some homeworks...
Are you planning sum the bass excursion - perhaps anything under 2*(box Fs)?
Worst case scenario: lots of bass notes happening at the same time, all of them cresting. The excursion would be additive... excuse my terrible pseudo math:
Total excursion = sum( (excursion @ freq @ calibration SPL) * sin(phase @ freq @ sample) * (amplitude @ freq over period / amplitude @ calibration SPL) )
I think you were right the first time when you said that you would need to look at 0.5*(lowest freq period in samples).
Let me know if I am misunderstanding your binning strategy, which I easily could be! I know basically nothing about DSP.
Worst case scenario: lots of bass notes happening at the same time, all of them cresting. The excursion would be additive... excuse my terrible pseudo math:
Total excursion = sum( (excursion @ freq @ calibration SPL) * sin(phase @ freq @ sample) * (amplitude @ freq over period / amplitude @ calibration SPL) )
I think you were right the first time when you said that you would need to look at 0.5*(lowest freq period in samples).
Let me know if I am misunderstanding your binning strategy, which I easily could be! I know basically nothing about DSP.
Well, have been trying without success for two years, but it seems that 2016 will be the year... I have no idea about it didn't work before, and works now for me. How long ago did you try...btwthese guys seem to make changes they don't tell anything about to anybody, and audio seems to be the least of their priorities, even to announce they have finally done some homeworks...
Perhaps the USB implementation has been updated (in software?). I was planning to try again soon ... that's encouraging that you have it working now. What exactly do you have working? I was hoping for full duplex 2 in / 4-8 out.
I'm not planning on try to do a plugin that limits xmax itself. The problem is that the LADSPA code only has the audio signal to use when making decisions about when that signal is "too hot" and should be reduced/limited, etc. How does that signal relate to Xmax?
You can find modeling programs that will give you a plot of Xmax versus FREQUENCY for e.g. a closed box subwoofer, but the data streaming through our LADSPA plugin is actually in the TIME domain, as samples of the audio waveform. So problem #1 is that you don't know for any given sample how that samples level relates to the level at, say, 30Hz, unless you do a Fourier Transform on the data to get frequency response information. The problem with that approach is that time and frequency are mutually exclusive when doing this, and while you can determine the frequency spectrum of a time series if you use A LOT of time points to do so. This would mean VERY LARGE latencies, not just because you need a lot of time data as input for the FT but also because computing a FT does require some computing muscle in and of itself. Also, while you know the frequency (power) spectrum of this time series used as input, you don't know WHEN those frequencies are high or low WITHIN that long time series! If you use less time series data as input, you now have worse frequency response info from your FT, especially at low frequencies. Not only that, we are talking about a continuous stream of data. You need to window and overlap or whatever to keep working on the data as it arrives. This is not trivial and it's above my pay grade even if it would make sense and provide great benefit to do so. Even at that point you only have the power in the signal versus frequency - STILL no Xmax data. You need a box model AND need to know the power amplifier gain!
In my approach (for the plugin I am writing) I make an assumption about what frequencies will be causing the OUTPUT of the Linkwitz Transform to exceed the maximum signal level of 1.0. Why 1.0? Well that's the floating point signal level that is assigned internally to 0dB (maximum output level) and represents the maximum level the DAC can spit out. I believe that my LADSPA host actually clips the outputs at +/-1.0 before sending the data to any output device. Anyway, back to my assumption... So with the LT I am assuming that there is a lot of boost being used AND that the input signal to the LT filter is NOT already above a signal level of 0dB/1.0. Let's say you have 30dB of boost at the lowest frequencies. In terms of voltage this is 31 times voltage gain, or another way to say this is with an input of 1/31 Volts = 0.032 Volts at low frequency the output will just reach clipping. So it's quite likely that most of the time its these lowest frequencies that are causing the signal level to exceed the maximum level. I'm assuming that in all cases the excess signal levels are due to the boost from the LT, and that most of this will happen with the lowest frequencies such that a small to modest boost reduction only when and where it's needed will bring the signal back into the acceptable range. I believe that this is a pretty safe assumption to make, but I will definitely need to do some listening tests, distortion measurements, etc. to make sure all is well.
The way the plugin works to limit the signal dovetails nicely with perceived SPL versus frequency data, like the Fletcher Munson curves (and whatever the more modern one is called). These show that the SPL of low bass must be higher to be perceived as being as loud as middle frequencies and that the difference between perceived loudness levels for low bass is less (in decibels) than for middle frequencies. My plugin should allow the user to increase the relative amount of low frequency output (or extend the low end frequency response) when the input signal level is LOW, and then only allows modest increases after that. For example, if "full LF boost" can be provide at -40dB level but the level is increased to -34dB (6dB more) the low frequency output might only be allowed to increase to -37dB (3dB). As the level continues to rise the LF output will hit a ceiling. This is very similar to the FM curves. It's letting the user get more out of their closed box subwoofer and make it more aligned with how one's hearing perceives low frequency sound.
Because I assume that the input signal is not exceeding the max level, one must be careful when putting filters AHEAD of this one to not boost up the level with EQ or other peaking type filters. For example, if the user applies EQ that boosts up the level to 1.1 at 100Hz and this is above where the LT kicks in the code will dutifully reduce the LT gain to ZERO in an effort to eliminate the excess signal, however, it doesn't know that reducing the LT gain will have no effect because it isn't providing any gain at 100Hz. The plugin has no idea about power versus frequency, only the level of a given sample. For this reason I am considering adding a hard limiter on the input to the LT as a little safety net that can trap this kind of issue before it happens.
Sorry, I misunderstood what you are doing. I thought you were trying to limit excursion (avoid clipping the speaker), but you are trying to limit low frequency boost so as not to exceed 0dBfs (avoid clipping the digital signal).
I'm aware of this.. that's why I suggested the (Xmax plugin you aren't making) would require the box and driver models, and measured amplifier gain. Not knowing much about DSP, I didn't understand how difficult and/or computationally intensive this would be, but I did get that it would involve Fourier transforms and windowing. Why is it that "you don't know WHEN those frequencies are high or low WITHIN that long time series"? I assumed this information would be available as a result of the FT. Feel free to just tell me to read a book on DSP if that's what needs to happen for me to understand!
Yes I've noticed this about LADSPA plugins... pretty serious design flaw IMO.
So basically its a LT combined with a look-ahead limiter which instead of altering the overall gain just reduces the amount of boost from the LT. Got it!
I see, set the max boost, then a ratio for mixing in that boost based on a threshold - compressor style.
I don't think that dynamically (moment to moment) applying a loudness control is a good idea. Equal loudness curve should be applied based on the difference between playback volume and reference volume. Within a particular piece of music / film, quiet sounds SHOULD sound quieter, with all that entails, including the changes in perceived frequency response due to equal loudness curves. (Aside: FM curves are outdated as you perhaps know - check out the ISO 226:2003 curves).
So, I don't think that thinking in terms of equal loudness contours will aid in the design of your plugin. That would be best implemented in a calibrated volume control plugin (only possible for film; no proper standards for music levels). For a non-calibrated application (music, or no SPL meter available) you could simply have a "loudness compensation" knob. Perhaps a separate plugin? I'd use it!
Sounds like LADSPA will clip the output of whatever comes before it, but you could always add an "input gain" control.
These two "limits" are related for the most part, or at least are interrelated. One I can do via a plugin and the other I cannot.
See: https://en.wikipedia.org/wiki/Short-time_Fourier_transform#Resolution_issues
Not a flaw at all. "1.0" doesn't have any units. It just the (arbitrary) number that is assigned in the internal (floating point) representation of the signal as the maximum output level, or 0dB "digital level". This could be 10 or 1000 or 0.001 and it wouldn't make any difference because the floating point number has incredible amounts of headroom for audio signals. Someone way back had to come up with a standard internal reference level for "full scale" and they chose "1.0".
Yes, that it exactly.
Sort of...
Well the limiter is essentially doing "moment to moment" adjustment of the level, isn't it? In the case of my plugin, it's only adjusting the level of the low frequency part of the signal when the level is "too high". The intent wasn't to create a loudness feature, although it does share some features with that kind of control and operates dynamically.
Again, it's not intended as a loudness control. I was just making a connection so that people could better understand how the plugin will function when used in practice.
Just about all of the filters available in my ACDf LADSPA plugin already have adjustable gain. That doesn't do anything except turn the level of all frequencies up or down (manually) and doesn't change with respect to level or any other parameter unless you tell it (manually) to change. Maybe you were thinking of a limiter that reduces overall gain?
Anyway "LADSPA" is just processing the internal floating point numbers to do things like filtering. The LADSPA "host" program (I use ecasound) is what interfaces with the DACs via the linux audio subsystem (e.g. ALSA) and that is what clips the signal, and if not then the DACs will. It doesn't really matter - the DACs can only output whatever their "maximum" level happens to be. The internal representation of a number corresponding to the audio signal level can be hundreds of dB higher because of the headroom of the floating point data type used to represent each sample.
Last edited:
Also, expanding a little more on this quote from above by dynomike:
The above is not what is happening in the code. The user supplies the parameters for the LT (Fz,Qz,Fp,Qp). In the absence of any limiting action all that is happening is the code is applying this filter (the LT) to the audio data.
Now let's assume that the level of the low bass energy increases - this can be because the volume is turned up or a bass note appears in the audio stream. The (high) amount of boost of the LT filter makes the peak of this bass note waveform at the LT output exceed the "1.0" internal threshold corresponding to "maximum level of the output device". This would normally be (hard) clipped. Instead my plugin then searches over N other LT filters that are being calculated in parallel on the audio stream for the filter that just makes the peak of the waveform equal to or less than the internal limit of 1.0. This is done by processing the data in blocks. The largest amount of "limiting" (I like to call it boost reduction) is then stored for that block - it's just an identifier for one of the N LT filters. We move on to the next frame of audio data and process that, then we return to the first one and, after some decision making on how to interpolate across the frame, the output stream is generated.
The user can specify how close together in decibels these N LT filters are. For instance if the boost is 24dB the user can select 3dB as the boost increment and then there will be 24/3= 8 LT filters calculated in parallel. IIR filters are so computationally lightweight that the plugin can calculate MANY filters in parallel within the same plugin and only use a few percent of the CPU capability of (for example) a Raspberry Pi 2. The user is free to choose the boost increment as desired. Choose 1dB of you would like. In this way the difference between LT filters is small and mixing their outputs should not result in any audible effect in and of itself.
The above is not what is happening in the code. The user supplies the parameters for the LT (Fz,Qz,Fp,Qp). In the absence of any limiting action all that is happening is the code is applying this filter (the LT) to the audio data.
Now let's assume that the level of the low bass energy increases - this can be because the volume is turned up or a bass note appears in the audio stream. The (high) amount of boost of the LT filter makes the peak of this bass note waveform at the LT output exceed the "1.0" internal threshold corresponding to "maximum level of the output device". This would normally be (hard) clipped. Instead my plugin then searches over N other LT filters that are being calculated in parallel on the audio stream for the filter that just makes the peak of the waveform equal to or less than the internal limit of 1.0. This is done by processing the data in blocks. The largest amount of "limiting" (I like to call it boost reduction) is then stored for that block - it's just an identifier for one of the N LT filters. We move on to the next frame of audio data and process that, then we return to the first one and, after some decision making on how to interpolate across the frame, the output stream is generated.
The user can specify how close together in decibels these N LT filters are. For instance if the boost is 24dB the user can select 3dB as the boost increment and then there will be 24/3= 8 LT filters calculated in parallel. IIR filters are so computationally lightweight that the plugin can calculate MANY filters in parallel within the same plugin and only use a few percent of the CPU capability of (for example) a Raspberry Pi 2. The user is free to choose the boost increment as desired. Choose 1dB of you would like. In this way the difference between LT filters is small and mixing their outputs should not result in any audible effect in and of itself.
Yup.. I realized just after I posted the thing about threshold/ratio that it was incorrect here. There is still a threshold involved (0dbFS, "1", whatever) but the only "compression" that is happening is fitting which LT filter will not exceed the threshold, ie. infinite ratio.
I would still like to see a threshold control though, for if your speakers are hitting Xmax below digital full scale (quite reasonable assumption I think).
I understand what a limiter does, and wasn't suggesting that your plugin was doing that. I was speaking of your plugin operating as a multiband compressor which would change the frequency response based on input volume (something a limiter shouldn't do). Of course, this is an unavoidable side effect of not having unlimited headroom, and likely less audible than limiting the entire signal. Hence the interest 🙂
As for the clipping issues, wow I had that totally wrong. I just performed some tests in Ardour and with Calf Jack Host and they both work totally fine - lots of headroom.
I still think a threshold control would be useful on your plugin, why not add it? It does perform a similar function of a linear-phase multiband compressor after all (one that has gain on the low frequency band in the form of the LT, and a fixed infinity ratio).
Are you lowpassing the signal that goes into the detection circuit? I would think that would be much more useful. The real problem with the LT is one of excursion, not clipping a DAC or amplifier. Any potential clipping can be easily resolved by leaving digital headroom. So this whole 0dB thing doesn't make sense to me for this application. Why run the DAC so hot that digital clipping becomes an additional issue? Leave headroom for the LT, and only limit the LT boost when it will create issues for the speaker. I'm assuming again that this plugin comes last in the chain (after a digital volume control).
So while keeping the main concepts of your plugin intact, I suggest that a threshold for maximum level *in the frequency range affected by the LT* should determine the selection of the LT filter, not the full-bandwidth signal hitting 0dB. Still very simple compared to the insane box-model and SPL calibration solution I proposed earlier.
Thanks for the wikipedia link btw. That helps explain why my idealistic proposed method would be exceedingly difficult / impossible...
@dynomike:
I'm not sure what would be gained by adding a user-defined threshold, slope above threshold, knee, and other limiter-like features (if that would even be possible). This isn't really intended to work like one band of a multi-band limiter - those limit the gain for all frequencies within the band equally. The plugin doesn't work that way.
Anyway, you still seem confused that I can make decisions based on "the frequency range affected by the LT". There is no information about power versus frequency available unless I implement additional processing to create it via multiple high-order bandpass filters or doing an FFT, etc. Not only would that create HUGE latency problems, it's just not the direction I was planning to go with this.
I'm not sure what would be gained by adding a user-defined threshold, slope above threshold, knee, and other limiter-like features (if that would even be possible). This isn't really intended to work like one band of a multi-band limiter - those limit the gain for all frequencies within the band equally. The plugin doesn't work that way.
Anyway, you still seem confused that I can make decisions based on "the frequency range affected by the LT". There is no information about power versus frequency available unless I implement additional processing to create it via multiple high-order bandpass filters or doing an FFT, etc. Not only would that create HUGE latency problems, it's just not the direction I was planning to go with this.
Ok. If I want something different, I had better learn to do it myself! I might fool around with the multiband to see what I can come up with, or in fact to determine where my thinking is off..
I was only suggesting adding a 12dB/octave low-pass filter on the signal you are using for detection. With a corner frequency matching the original speaker corner frequency.
Good luck with the plugin, and thanks for sharing your work and thought process.
I was only suggesting adding a 12dB/octave low-pass filter on the signal you are using for detection. With a corner frequency matching the original speaker corner frequency.
Good luck with the plugin, and thanks for sharing your work and thought process.
With ecasound+LADSPA, the user builds the connectivity of the crossover system and the routing can be implemented in any arbitrary way. To implement what you describe above, one can simply put the lowpass crossover filter(s) that are separating out the frequencies for the sub channel upstream of the LT plugin in the crossover routing. That way the LT plugin will only "see" the lower frequencies - any signal above the threshold is only due to the "band" passed on to the LT plugin.
Since that may or may not be desirable for all applications, I am not planning on including it into the LT plugin code.
The initial code debugging is done and I have started to experiment with the plugin. There are a couple of things I still need to fix, but it's more or less working as advertised.
As I was thinking about this, reading a little about lookahead limiting, and reflecting on the posts by dynomike I realized that I can take the guts of this code and use it create a multiband lookahead limiter. This kind of thing isn't really needed for domestic hi-fi playback, but if I am already 75% there I might as well create a public domain plugin using that technology. Hey, why not. So, that's probably next on the list. For now, back to the code at hand...
As I was thinking about this, reading a little about lookahead limiting, and reflecting on the posts by dynomike I realized that I can take the guts of this code and use it create a multiband lookahead limiter. This kind of thing isn't really needed for domestic hi-fi playback, but if I am already 75% there I might as well create a public domain plugin using that technology. Hey, why not. So, that's probably next on the list. For now, back to the code at hand...
I don't think that would implement what I describe. The LT plugin would be processing the low-passed signal. I was suggesting a low-passed "sidechain" (what feeds into the detector circuit, but is independent from the signal that is being processed) while processing the full bandwidth signal. Having a separate sidechain input would also work. It's a common design on compressors - filters to tailor the signal that goes to the detector, such that the elements you want compressed are triggering the compression. I know, its not a compressor. But it is a dynamics processor! 🙂
Well, after some more careful listening I have discovered some problems. The plugin in working, that is for sure. If I eliminate the lookahead (well its' somewhere between 0 and 1 buffer length but no longer) I hear a "tick" when the limiter kicks in. This is exactly what I was hoping to NOT hear with the output mixing approach that I used. I think it's only on the attack, where the limiting is ramping up very quickly. So I added some code that would increase the amount of lookahead and would more slowly ramp up the amount of boost limiting. This adds more buffers but this SHOULD be no big deal. When I listen to the version with the increased lookahead I hear a "tick" at the beginning of each frame! So there is probably something amiss in the code and I can't seem to find it. I will try to track this down, or I might try another way to attack the problem alltogether.
Interested
I'm interested in your work. I have an Infinite Baffle being DSP'ed by a Raspberry Pi 2 running Jessie.
Installed Jack and some plugins.
wget -O - http://rpi.autostatic.com/autostatic.gpg.key| sudo apt-key add - sudo wget -O /etc/apt/sources.list.d/autostatic-audio-raspbian.list http://rpi.autostatic.com/autostatic-audio-raspbian.list sudo apt-get update.
I'm using the 3 band parametric to give me crossovers and eq, works a charm. Its freed up my Behringer DEQ2496 Ultracurve.
I have a Peerless 12" XXLS in my van in a sealed box. Was thinking another Pi with a Linkwitz Transform Plugin 🙂 only issue beeing, to have the PI constantly powered so I don't have to keep setting up Jack.
Mike
I'm interested in your work. I have an Infinite Baffle being DSP'ed by a Raspberry Pi 2 running Jessie.
Installed Jack and some plugins.
wget -O - http://rpi.autostatic.com/autostatic.gpg.key| sudo apt-key add - sudo wget -O /etc/apt/sources.list.d/autostatic-audio-raspbian.list http://rpi.autostatic.com/autostatic-audio-raspbian.list sudo apt-get update.
I'm using the 3 band parametric to give me crossovers and eq, works a charm. Its freed up my Behringer DEQ2496 Ultracurve.
I have a Peerless 12" XXLS in my van in a sealed box. Was thinking another Pi with a Linkwitz Transform Plugin 🙂 only issue beeing, to have the PI constantly powered so I don't have to keep setting up Jack.
Mike
Last edited:
I'm sure you can set up a startup script. What are you using to get the audio I/O? I never had success with USB sound cards on the Pi for full-duplex.
- Status
- Not open for further replies.