Implement simple audio compressor for all input and output.#672
Implement simple audio compressor for all input and output.#672hselasky wants to merge 1 commit intojamulussoftware:integrate_float2from hselasky:integrate_float2
Conversation
Signed-off-by: Hans Petter Selasky <hps@selasky.org>
|
Introducing a compresser to solve a Windows audio interface bug is no option for me. The actual bug has to be fixed. The preferred way of inserting audio effects to Jamulus is to insert the effect(s) in the audio path before the Jamulus client. E.g. in Jack Audio this is very simple but there exist tools for Windows and MacOS, too. |
|
@corrados : I think it is not a problem in Jamulus. Regardless, can you test this patch? |
|
@corrados : Please beware that some audio devices need additional space in the samples to do EQ // audio processing, and don't support using the full 24-bit range for example. |
On the server side this is not an option. I think the compressor is cheap enough that we simply put it into the Jamulus audio path. This replaces the simple range-clipping, which is not working. |
|
@corrados : In the old code everything was cast to 16-bit, so you never reached the limit of 24-bit. How can you say that this is a problem in the new code and not with your audio device? I'm sorry, but I don't have any Windows machines here to test. I tried a VM on a MacBookPro, but that is terribly slow. Can you explain exactly what is clipping? Is the audio going through the OPUS codec via a server or is this for local loopback? --HPS |
|
Sorry, there is an urgent request (#619) which I want to work on with highest priority. So I don't have time to assist you here. Maybe bflamig can help. |
|
@hselasky: I have to agree with @corrados that using the proposed compressor isn't addressing the real issue, whatever that is. I also note that as far as I can tell, no other audio library that I can find needs such tweaks for 24 bit audio data. Do you have documentation or links that describe this issue for certain devices that have this problem? They would be interesting to read. By the way, we don't know that the current range clipping is not working. It's entirely possible it's not being called all the times it needs to be. I don't have access to an audio device that uses 24 bit samples, so I can't debug this directly. A small test program needs to be written that uses a buffer of 24 bit data having the range extremes, and passing them through the conversion routines to see if there are any inherent problems. My personal belief is that the Jamulus code isn't really keeping the floating point values between -1.0 & 1.0. I think it's going over that at times, and that will cause overflow problems when converting to integer samples. That would sound nasty and perhaps that's what corrados is seeing. Or, it's a simple mistake in the code, that we're just not realizing yet. I'm currently working on an audio project of my own, and during the course of developing that code, I will be testing such conversions. Am in the process of doing that now, but I don't have a good estimate of when that will be accomplished. Only so many hours in a day! Perhaps I'll have some results over the weekend. But the only real test is to use a 24 bit device and see it in action with Jamulus, in a debugger. |
|
I'll close this pull request since the compressor does not fix the source of the problem and since HPS now has started his own jam software project (see #539 (comment)). |
4 participants
Signed-off-by: Hans Petter Selasky hps@selasky.org