Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DC offset #10

Closed
R-a-l-f opened this issue Aug 26, 2014 · 5 comments
Closed

DC offset #10

R-a-l-f opened this issue Aug 26, 2014 · 5 comments

Comments

@R-a-l-f
Copy link

R-a-l-f commented Aug 26, 2014

Hi,

Phasex does produce DC offsets.

http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-August/098645.html

Regards,
Ralf

@caoliver
Copy link

Curiously, there is a DC offset rejection filter which seems to be commented out for some reason.
You might try it using the following patch:

diff --git a/src/phasex.h b/src/phasex.h
index 5c649d8..b45db75 100644
--- a/src/phasex.h
+++ b/src/phasex.h
@@ -244,7 +244,7 @@ typedef float sample_t;
 #define ENABLE_SAMPLE_LOADING

 /* Per part DC rejection filter */
-//define ENABLE_DC_REJECTION_FILTER
+#define ENABLE_DC_REJECTION_FILTER

 /* Audio output defaults, mostly for first startup w/ no config file.
    These options now can be set in config file and/or command line. */

I find there is still some terrible aliasing even with the band limited oscillators.
I'm left scratching my head about the seriousness of this thing.

@R-a-l-f
Copy link
Author

R-a-l-f commented Aug 28, 2014

Thank you very much Caoliver,

I had no time to update my bug report. We should test Fons Adriaensen's patches. At least I will do ASAP.

http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-August/098648.html
http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-August/098653.html
http://lists.linuxaudio.org/pipermail/linux-audio-user/2014-August/098655.html

IMO his knowledge about audio engineering is very good. I was an audio engineer myself, but I'm not a Linux coder. Since he noticed the same as you noticed, but he has got doubts regarding the implemented code, I guess it's wise to test his patches. It can't harm to add a pass filter when testing.

Regards,
Ralf

@caoliver
Copy link

I'll give that a try. The interesting thing here is that the sampled analog waveforms are normalized by their extrema when they are read. That would be fine if the signal had a zero mean, but it doesn't, so Phasex is baking in a DC offset as stands. I hacked the routine to displace the signal by its mean, and scale so the the largest of max, abs(min) is 1. If Fons' patch isn't sufficient, I'll try the combination. I think some specific DC blocking should be done anyhow as even a symmetric waveform could have a DC bias if properly (pathologically) FM or Phase modulated.

@caoliver
Copy link

I'm testing Fons' DC offset patch, and it seems to work fine; it needed a bit of work as the diff Fons provided seems to be from an earlier version. I've also applied the following patch for better normalizing the sampled waves when read: http://sprunge.us/UMTM

@williamweston
Copy link
Owner

Thank you caoliver, Fons, and Ralf for looking into the DC offset problem. The original DC offset filter was contributed by Anton Kormakov. I disabled it while working on the sample loading and bandlimiting, and never turned it back on because it didn't seem to be in the right place. I was noticing the same issue with the envelope, which makes me think also that the envelope curves deserve another look. This is what drew Anton to look into the DC offset problem in the first place.

Meanwhile, the resampling memory clobbering bug has been fixed (constant type conversion thrashing ratio value, thus causing src_simple() to overrun the wavetable). The vox samples were most affected, at least on my build. With clean sample conversion, I was able to standardize the bandlimiting scheme. Samples are now normalized using caoliver's method both when going into and out of the bandlimiting filter. The amplitudes of the waveforms output on the oscillators are much more consistent between wave shapes now. The only remaining issue with normalization is choosing the scheme for normalizing the bl_square and bl_stair so that they can be used as accurate modulators. I haven't decided whether to go with hand-tuned scalar constants or average hold amplitude calculation for coming up with the scalar values. The latter would allow simple addition of new stair and arpeggiator type square based waveforms.

With the exception of the noticeable difference in modulation depth between the bl_square/bl_stair and their non-bandlimited counterparts, the volume and modulation depth of all of the wave shapes seem to be much more consistent with these changes. Boosting volume on vox based patches to achieve the same audible level as other patches is no longer necessary.

Also changed in v0.14.98-dev is the internal tuning resolution, increased from 120 units/half-step to 1440 units/half-step. This was the source of some of the Aliasing noise Fons mentioned in another thread. Though just a few, all of these changes combined are a huge improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants