Serious audio output problems.

ben_wizards

If you add this at the top of render.cpp

#include <I2c_Codec.h>
extern I2c_Codec *gAudioCodec;

then you should be able to write to the audio codec with

gAudioCodec->writeRegister(register, value)

(see some examples in core/I2c_Codec.cpp)

Unfortunately anything you would do during setup would be overwritten by the actual codec initialization, so you should try to run it in an auxiliary task (which is scheduled from render()), or do it at the first call to render(), something like

static bool init = false;
if(init == false){
  gAudioCodec->writeRegister(register, value);
  init = true;
}

Also, a couple of notes on the snippets of code you posted above:
1) I am not sure what degree of precision you can expect from sinf_neon(rad) when rad is outside the range of 0 to 2*M_PI. Even if the precision of the function is not an issue, you should always make sure you wrap the phase in order to avoid troubles with the finite precision of float (e.g.: after a few seconds or minutes that your project is running, the frequency of the sinewave will change and eventually degrade to a DC signal).
2) in case you already are wrapping the phase between 0 and 2*M_PI, then (sinf_neon(gphasex*3))/3*x is NOT going to give you a sine wave, because gphasex*3 would be affected by the wrapping. The resulting wave will probably contain lots of high frequency and potentially cause aliasing.

Also, applying a filter in the digital domain is not likely to help much with aliasing, unless aliasing is concentrated in a band where you have no signal.

One last thing, the forum engine understands markdown, so when pasting your code you are encouraged to use backticks ( ` ) around it, so that it is displayed in a monospace character. For blocks of code, use three backticks ( ``` ) before and after, this also gives some sort of syntax highlighting and different background color.

As andrew pointed out, the time-domain representation of a waveform can be distorted by a simple high-pass filter, without that impacting the resulting sound. Also, at is common in many amplifying stages, depending on their design, the output of the headphone amp is inverted with respect to its input, again with no audible difference.

So I made a Matlab simulation to see what happens to a bandlimited complex waveform when it is delayed, slightly offset, inverted and high pass filtered.
I used a Butterworth second order high pass, cutoff 50Hz, the waveforms have fundamental frequency of 200Hz.

You can see the results here Square wave sawtooth (matlab code is embedded in the image description, should run fine also on GNU/octave which is free ).
They seem pretty close to the ones you posted above, from which I'd conclude: what you see is not distortion, it is just the effect of linear filtering. I actually did not realize it immediately myself, as you'll have realized from my first answer above, but as Andrew pointed out in his first post, there seems to be no issue with your board.

Have you heard any audible distortion (when using reasonable gain settings) by any chance?

Incidentally, as mentioned briefly above, I do not think that "software filters" would help you get rid of aliasing and using a signum() function (or anything with sharp corners) is likely to cause aliasing. Aliasing sounds great some times but the time-domain representation of a non-bandlimited waveform may be affected in even more unexpected ways when it goes through a lowpass filter like the one built into the audio DAC.