I looked at the schematic in the manual off the page you linked to. The input is via an opto-isolator with a 4.7K current-limiting resistor (R16). The other side of the opto-isolator there is an RC filter (1K / 10uF). I would suggest the following:
1) It is better to use PWM rather than the DAC because there is already enough of an RC filter in the circuit.
2) If you lowered the value of R16 from 4.7K to around 680 ohms then the input voltage range would lower from 0-12V to approximately 0-3.3V which would avoid the need for an amplifier.
I tried something similar a few years ago - I also used a 14.318MHz crystal crystal. But I was using a Duemilanove, which was much easier as it already had a crystal oscillator for the 328P. All I needed to do was desolder the crystal and replace it with a socket, then I could change over the crystals easily.
I will see if I can find that Duemilanove, I think it is buried in my RepRap somewhere, and the 14.318MHz crystal, and see if I can get your code to work
The proposed fix for micros() will not work because the code relies on certain instructions being executed consecutively:
//#defines removed t = TCNT0; if ((TIFR0 & _BV(TOV0)) && (t < 255)) m++;
If an interrupt was allowed to occur between these lines, there could be a delay between reading TCNT0 and TIFR0 and m could be incremented erroneously causing an error of 1000us. Therefore it is necessary to disable all interrupts here, not just the timer.
As for timed interrupt sensitivity the jitter here will be small compared to the jitter caused by the millis timer interrupt itself and interrupts can be up to 3 ticks late anyway, you would be better dejittering the interrupt than altering micros.
The two different USB sockets is not an error - the native port is a micro-AB socket and the programming port is a micro-B socket (this is clearly marked on the diagram). This is needed when using the native port as a USB host - A USB host adaptor should have a USB micro-A plug and will not fit a micro-B socket.
However, the cheap Chinese USB host adaptors that you see on Amazon and Ebay have often been (incorrectly) made with a micro-B plug. If you did duplicate the programming port socket on the native port it might still work as a host if you can get one of those adaptors with the wrong plug.
In theory, it is possible to get the Serial and Serial2 pins working in SPI mode, but nobody has written a library to do this yet.
There are no female SPI connections which work with the current hardware SPI library on the Due. The only way is to use the male SPI pins - use connectors like these: https://www.sparkfun.com/products/9385 - don't use croc clips or similar because it's too easy to accidentally touch against the 5v pin and damage the SAM3X.
I think this bug might be more serious than it first appears. Looking at the pinout diagram, Arduino pin 10 is connected to two different pins on the SAM3X, port pin C29 and A28. pinMode(10,OUTPUT) sets C29 as output and sets it high. But SPI.begin(10) would cause the SPI hardware to use A28, and drive it low when needed.
So I'd conject that pin 10 is not actually floating, but when the CS is selected it is being driven both high and low at the same time
Adding pinMode(_pin,INPUT); to the beginning of the SPIClass::begin(uint8_t _pin) method ought to solve the problem.
I've made a new release of the library. Get it here: DueVGA-0.512.zip This release fixes a few bugs and clashes between DueVGA and the Serial and Audio libraries.
It also includes three longer demos - the GPS demo and the Animation demos have been posted above already, the other one is a demo of a waterfall plot. This takes an audio signal as inout, samples it and performs a FFT, and shows the result on a scrolling display. See the video and screenshot below for an example of what it does.
The SAM3X crystal is 12MHz. It doesn't have fuses, instead the clock speed is set by the PLL registers. To get 84MHz you set some register somewhere to multiply the crystal frequency by 7. I don't know any more about it than that though.