Major updates, mostly for final project

content/01_final_project.md

++++
+title = "Final Project"
+date = "2018-09-12"
+menu = "main"
+weight = 2
++++
+
+This is my giant final project tracking page. It covers everything from abandoned ideas through implemented ones through my plans beyond this course.
+
+
+## Idea 1: The Analog Analogue Synthesizer
+
+Every electronic circuit has an analogous mechanical circuit whose motion is governed by an equivalent differential equation. Analog synthesizers are electronic circuits, so analog synthesizers have mechanical analogues -- analog analogue synthesizers.
+
+The heart and soul of any classic subtractive synth is its filter section. Most use a ladder of RC circuits to make a low-pass filter (LPF). It takes a raw waveform with a lot of harsh high frequency content (like a sawtooth or triangle wave), and turns it into something more musical.
+
+![](/img/01_rc_ladder.jpg#c)
+
+Two rungs (pictured) give a two pole filter, and four, well, four. I'd like to make a mechanical analog of one such rung. If things go well, I can make multiple and chain them together, just like in the electronic circuit.
+
+
+### Will it work?
+
+In a normal analog synthesizer, voltage is used to represent air pressure (or more directly, the displacement of a speaker cone). In my analog analogue synthesizer, voltage will be replaced with force. The common electrical components then each have their own analog:
+
+ - resistance <---> damping
+ - capacitance <---> springiness
+ - inductance <---> mass
+
+So each rung of the ladder circuit will be, in my mechanical version, a damped oscillator.
+
+To be more precise, a normal RC circuit is described by the following ODE:
+$$rc \dot{y}(t) + y(t) = x(t)$$
+Here \\(r\\) is the resistance in ohms, \\(c\\) the capacitance in farads, \\(x(t)\\) is the input voltage, and \\(y(t)\\) the output voltage (i.e. what we'll need to solve for).
+
+A driven massless damped oscillator is described by this equation:
+$$r \dot{y}(t) + k y(t) = x(t)$$
+Here \\(r\\) is the damping coefficient (in Newtons per meters per second), \\(k\\) the spring constant (in Newtons per meter), \\(x(t)\\) the input force, and \\(y(t)\\) the displacement of the oscillator.
+
+For appropriate values of the constants these two systems will clearly have the same behavior. So there's hope!
+
+In order to keep forces and velocities within reasonable ranges, I'll aim to operate 100 times slower than normal audio. So a concert A, instead of being 440 Hz, will be just 4.4.
+
+
+### How would it be made?
+
+Since we'll represent the waveform-to-filter using force, the input has to be a force control servo. I know this can be done either via current measurement, or with a load cell looped into the controller. How hard could it be?
+
+The damping could be provided with a viscous fluid. But, I don't know of viscous fluid dampers that can adjust their viscosity on the fly, which we'll need to do if we want to sweep the cutoff frequency of our filter. Which obviously we do. I only know of one other way to get a resistance force directly proportional to velocity: eddy braking. So we'll need an electromagnet (vary the current to vary the resistance) and an aluminum rail. What could go wrong?
+
+The capacitor, luckily, just becomes a spring. Phew.
+
+Now a normal RC filter contains no inductor. It would be difficult to make my mechanical filter's moving parts massless<sup>[citation needed]</sup>, but luckily this isn't strictly necessary. All RC circuits contain some self-inductance, as all mechanical circuits contain some mass. I'll just try to keep my filter's mass to a minimum relative to the damping and spring factors.
+
+Finally, instead of measuring the output voltage across the capacitor, we'll be measuring the output force across the spring. So we need a load cell.
+
+All in all, here's a simple sketch of the main components for one stage of the filter. If all goes well I'll build multiple of these.
+
+![](/img/01_mechanical_design.jpg#c)
+
+
+
+### Frequency Response Analysis
+
+Since our mechanical oscillator won't be massless, we might as well model it with some mass. At least then we know what to expect. This gives us a second order ODE:
+$$m \ddot{y}(t) + r \dot{y}(t) + k y(t) = x(t)$$
+(The symbols are defined as above, except for the addition of the mass \\(m\\).)
+
+Let the input function be \\(x(t) = A \sin(\omega t)\\). Then our ODE is solved by:
+$$y(t) = \frac{-A r \omega \cos(\omega t) + A (k - m \omega^2) \sin(\omega t)}{r^2 \omega^2 + (k - m \omega^2)^2}$$
+It has an amplitude of
+$$\frac{A}{\sqrt{r^2 \omega^2 + (k - m \omega^2)^2}}$$
+
+For completeness, the first derivative is
+$$\dot{y}(t) = \frac{A \omega (k - m \omega^2) \cos(\omega t) + A r \omega^2 \sin(\omega t)}{r^2 \omega^2 + (k - m \omega^2)^2}$$
+and its amplitude
+$$\frac{A \omega}{\sqrt{r^2 \omega^2 + (k - m \omega^2)^2}}$$
+
+The output of our filter is the force exerted by the spring, or \\(k y(t)\\). I also care about the maximum displacement, the maximum velocity, and the maximum force exerted by the damping system.
+
+
+## Idea 2: Custom MIDI guitar pickup
+
+Conventional guitar pickups produce an analog signal, that is amplified and fed directly into a loudspeaker. Electronic keyboards, on the other hand, can communicate in a digital format called MIDI that encodes (among other things) when notes are played and released. A fun but not so commonly used bridge between these two worlds is the MIDI pickup. These pickups record analog signals just like conventional pickups, but then sample and process the signal so that corresponding MIDI messages can be generated. This enables, for example, a bass guitar to control a synthesizer.
+
+There are two dominant commercial MIDI guitar pickups: the [Fishman TriplePlay](https://www.fishman.com/products/series/tripleplay/) and the [Roland GK-3](https://www.roland.com/global/products/gk-3/). Both cost several hundred dollars. I bet it's possible to make one for far less. I'll try to make one for my five string bass.
+
+
+### General Design Requirements
+
+Frequency extraction isn't a trivial problem, since even a single note played on a guitar has overtones at many different frequencies. So there's always an element of inference: given an observed frequency spectrum, the problem is to determine which note or notes are most likely to generate it. This problem is especially difficult for some commonly played patterns, like playing two notes an octave apart, in which the frequency spectra of the two notes are very similar. Luckily the problem can be simplified a great deal by processing each string independently. Each string can only sound one note at a time, so we don't have to consider note combinations. All popular commercial MIDI pickups function in this manner.
+
+So the essential components of the system are:
+
+ - a divided pickup that can listen to each string individually
+ - a collection of ADC channels that sample the analog signal from each string
+ - signal processing software that determines which note is being played on each string (if any)
+ - an output system that emits the appropriate MIDI messages
+
+
+### The Divided Pickup
+
+A pickup is at heart a variable reluctance sensor. It consists of a coil of wire in a magnetic field. When a ferromagnetic object like a steel string vibrates nearby, the field is disturbed and an alternating current is induced in the coil.
+
+Most pickups fall into one of two classes: single coil or humbucking. A single coil pickup works just as already described. A common problem in the modern environment is that in addition to picking up the signal generated by the vibrating guitar strings, you also get a signal from the 60Hz alternating current in nearby power wires. Humbuckers reduce this problem in a clever way: while the signal induced by the strings depends on the orientation of the magnetic field as well as the winding direction of the coil, the signal induced by AC mains only depends on the winding direction. So a humbucker chains two single coil pickups together, where the second has its magnetic field and winding direction reversed. As a result the signal from the strings is picked up twice (the signals from each coil constructively interfere), while the signal from AC power is cancelled out (the signals from each coil destructively interfere). Having a cleaner signal to analyze is a good thing, so I'll make a humbucker. After all, an intermittent 60Hz signal could look a lot like a series of (somewhat sharp) B notes.
+
+There are two main arrangements of coils and magnets in guitar pickups: either the coil is wrapped around a permanent magnet directly, or it is wrapped around a metal slug with high permeability and a magnet is placed underneath. I don't want to have to drill any new holes in my bass, so my pickup will need to be thin. So the former arrangement is probably more appropriate.
+
+The classic DIY coil winding technique involves a hand drill, but people have tried all sorts of other solutions [as well](http://www.tdpri.com/threads/diy-winding-with-a-drill-press.159104/). The CBA does have a specialized coil winding machine, however, so I can indulge in a bit of winding luxury. As an aside though, hand-wound and machine-wound pickups do have a discernable difference in sound. Machines are much steadier than hands, so the individual windings are packed closer together and stay more parallel. This allows more windings to occupy the same space, leading to a louder output, but also increases stray capacitance, which can reduce frequency response in the upper portions of the human hearing range. Hand-wound pickups, with their comparatively messier coils, are ever so slightly quieter but sometimes ever so slightly brighter.
+
+I took the relevant measurements on my bass with a pair of calipers and dove into Fusion. At first I thought I'd 3d print some bobbins and wrap the coils on them, as seen below. Magents could be fit inside, and all ten wound bobbins could be encapsulated in epoxy.
+
+![](/img/01_pickup_v1.jpg#c)
+
+Then Sam encouraged me to try freestanding coils. So instead of using bobbins that stay permanently wrapped with copper wire, I'd wind the coils on a temporary shaft, using temporary guides. The wrapped coils would be glued to themselves, removed from winding shaft, and transfered to a cylindrical magnet (with the same diameter as the winding shaft). I searched online and found that the most commonly used type of magnet is Alnico. But the ones I found [for sale](https://www.stewmac.com/Pickups_and_Electronics/Pickup_Kits_and_Parts/Pickup_Kits_and_Parts_for_Strat/Alnico_5_Polepiece_Magnets.html) were longer than I wanted. So I bought some 3/16" diameter, 1/4" long cylindrical neodymium magnets from [K&J Magnetics](https://www.kjmagnetics.com/). From [McMaster](https://www.mcmaster.com/rotary-shafts) I ordered a four inch long, 3/16" diameter rod to use for winding.
+
+I printed two shaft collars, that can be fixed in place thanks to some press-fit M3 hole inserts and corresponding screws. With this setup I'm ready to wind some coils. However at this stage I decided to refocus my efforts (discussed more below).
+
+![](/img/01_coil_winding_setup.jpg#c)
+
+
+### Microcontroller Selection
+
+The big question to answer here is whether the system should be monolithic or distributed. In the monolithic design, I try to find one powerful microcontroller than can process all the signals at once. In the distributed design, I process each string on a dedicated microcontroller. The former requires more careful selection of components, but requires less soldering and programming, and is likely more power efficient in the end. It also circumvents the need for communication between microcontrollers. If I'm going to run all the signal chains on one microcontroller, I'll probably want it to support floating point operations in hardware, as I'll probably want to run a lot of DFTs or other common signal processing algorithms.
+
+I also need to decide if I want to use the ADC on the microcontroller, or if I should use an offboard ADC. I have no experience with this, but my guess is that an audio-specific off-chip ADC would sound nicer (i.e. more linear response and lower noise), but that the onboard ones are still fine for the purpose of extracting a pitch --- as long as the sample rate and bit depth are acceptable. For my first take I think it's wise to cut out all components that aren't completely necessary, so I'll try to find a microcontroller with a capable ADC built in.
+
+So overall the relevant microcontroller specs are clock speed, hardware floating point capability, and ADC performance. I set out to perform a somewhat systematic review of the options, but found it to be a Sisyphean task. This is both because there's so many microcontrollers out there, and because it can require a long time with a datasheet to determine just how well the ADC will perform. The latter involves understanding how the ADC is clocked, how the sample rate affects the resolution, how different ADC channels interact, etc.
+
+So eventually I went with the first microcontroller I found that seemed to have decent stats in all the aforementioned departments: the Atmel SAMD51. It has an ARM Cortex M4F processor with a floating point unit, and can sample up to 1 million samples per second at 12-bit resolution, or trade off sampling frequency for higher resolution (up to 16 bits supported in hardware). The problem is that I have never worked with ARM chips before, and they are a lot more complex than their AVR counterparts. To try to overcome this I spent a lot of quality time with the datasheet, and experimented with two different pre-existing SAMD51 boards: an [Adafruit Feather M4](https://www.adafruit.com/product/3857?gclid=Cj0KCQiAr93gBRDSARIsADvHiOrHAq68TLa7fTvkSxp-SecTAZ-jKGF9rtpwsRLK9wJn-houwsa7XHgaAgSjEALw_wcB) and a precursor to Jake's [atkbreadboardboard](https://gitlab.cba.mit.edu/jakeread/atkbreadboardboard), the [mkbreadboardboard](https://gitlab.cba.mit.edu/jakeread/mkbreadboardboard).
+
+![](/img/01_samd51_boards.jpg#c)
+
+Ultimately I decided that progress was too slow on the SAMD51. I'm learning plenty by programming AVRs and don't feel compelled to rush to an ARM. So I decided to switch to an Atmel XMEGA. It doesn't have a floating point unit, and it doesn't have hardware support for 16-bit sampling, but it can still sample millions of times a second. Plus I had just gotten acquianted with its ADC for [machine week](../11_machine_week).
+
+
+### Algorithms
+
+My go-to algorithm for most audio processing tasks is the [DFT](https://en.wikipedia.org/wiki/Discrete_Fourier_transform). I've used these in the past for beat extraction and it worked pretty well. For this application, however, they aren't quite appropriate. Human perception of pitch is logarithmic, since each octave actually equates to a doubling of pitch. (As a result the difference between the fundamental frequencies of the lowest two notes on my bass is only 1.8Hz, while the difference between the highest two notes is around 20Hz.) But the DFT gives frequency buckets that are linearly distributed in frequency space. Luckily there's a logarithmically spaced counterpart, the [constant-Q transform](https://en.wikipedia.org/wiki/Constant-Q_transform).
+
+So my plan is to perform a constant-Q transform, then perform a least squares optimization to determine which note is most likely to generate the observed overtone distribution (assuming each note generates a harmonic series with roughly exponential decay). Ideally I'd be able to incorporate past states into the model, so I'd really want to compute the probability that a given note is playing conditioned on the observed frequency distribution and prior states.
+
+This sort of algorithm sounds like fun, but it's also not the sort of thing I'm in this class to learn. I already have enough experience with software. For this reason, and to avoid having possibly having to duplicate circuits five times (one for each string) as I'm learning the basics, I decided to pivot once again.
+
+
+## Idea 3: DIY USB Audio Recording Interface
+
+Instead of turning the audio into MIDI, I will aim to transmit it to my computer via USB. This still has a strong software emphasis, but learning about USB is much more tightly coupled to hardware than learning about constant-Q transforms. 
+
+I'll stick with the XMEGA because I'm becoming familiar with its registers and don't want to change. My board design/fabrication and software are described on my [networking](../13_networking) and [wildcard](../14_wildcard) week pages. So here I'll talk about the system integration.
+
+I designed an enclosure in Fusion. Its main chassis is printed, and it has a transparent acrylic top held on by magnets (left over from my pickup plans). The magnets are seated in recesses and held in place with epoxy. It has a 1/4" audio jack input, a knob to control the pre-amp gain, and a MIDI output. Currently I'm not using the MIDI output, but I want to leave the option open for the future. These three features are mounted to the enclosure, so that they can't put any mechanical strain on the circuit board. The MIDI connector and circuit board are held in place using plastic thread-forming screws. The fusion file is [here](/designs/01_enclosure.f3z).
+
+![](/img/01_enclosure.jpg#c)
+

content/01_final_project_idea.md

-+++
-title = "Final Project Idea"
-date = "2018-09-12"
-menu = "main"
-weight = 2
-+++
-
-## The Analog Analogue Synthesizer
-
-Every electronic circuit has an analogous mechanical circuit whose motion is governed by an equivalent differential equation. Analog synthesizers are electronic circuits, so analog synthesizers have mechanical analogues -- analog analogue synthesizers.
-
-The heart and soul of any classic subtractive synth is its filter section. Most use a ladder of RC circuits to make a low-pass filter (LPF). It takes a raw waveform with a lot of harsh high frequency content (like a sawtooth or triangle wave), and turns it into something more musical.
-
-![](/img/01_rc_ladder.jpg#c)
-
-Two rungs (pictured) give a two pole filter, and four, well, four. I'd like to make a mechanical analog of one such rung. If things go well, I can make multiple and chain them together, just like in the electronic circuit.
-
-
-## Will it work?
-
-In a normal analog synthesizer, voltage is used to represent air pressure (or more directly, the displacement of a speaker cone). In my analog analogue synthesizer, voltage will be replaced with force. The common electrical components then each have their own analog:
-
- - resistance <---> damping
- - capacitance <---> springiness
- - inductance <---> mass
-
-So each rung of the ladder circuit will be, in my mechanical version, a damped oscillator.
-
-To be more precise, a normal RC circuit is described by the following ODE:
-$$rc \dot{y}(t) + y(t) = x(t)$$
-Here \\(r\\) is the resistance in ohms, \\(c\\) the capacitance in farads, \\(x(t)\\) is the input voltage, and \\(y(t)\\) the output voltage (i.e. what we'll need to solve for).
-
-A driven massless damped oscillator is described by this equation:
-$$r \dot{y}(t) + k y(t) = x(t)$$
-Here \\(r\\) is the damping coefficient (in Newtons per meters per second), \\(k\\) the spring constant (in Newtons per meter), \\(x(t)\\) the input force, and \\(y(t)\\) the displacement of the oscillator.
-
-For appropriate values of the constants these two systems will clearly have the same behavior. So there's hope!
-
-In order to keep forces and velocities within reasonable ranges, I'll aim to operate 100 times slower than normal audio. So a concert A, instead of being 440 Hz, will be just 4.4.
-
-
-## How would it be made?
-
-Since we'll represent the waveform-to-filter using force, the input has to be a force control servo. I know this can be done either via current measurement, or with a load cell looped into the controller. How hard could it be?
-
-The damping could be provided with a viscous fluid. But, I don't know of viscous fluid dampers that can adjust their viscosity on the fly, which we'll need to do if we want to sweep the cutoff frequency of our filter. Which obviously we do. I only know of one other way to get a resistance force directly proportional to velocity: eddy braking. So we'll need an electromagnet (vary the current to vary the resistance) and an aluminum rail. What could go wrong?
-
-The capacitor, luckily, just becomes a spring. Phew.
-
-Now a normal RC filter contains no inductor. It would be difficult to make my mechanical filter's moving parts massless<sup>[citation needed]</sup>, but luckily this isn't strictly necessary. All RC circuits contain some self-inductance, as all mechanical circuits contain some mass. I'll just try to keep my filter's mass to a minimum relative to the damping and spring factors.
-
-Finally, instead of measuring the output voltage across the capacitor, we'll be measuring the output force across the spring. So we need a load cell.
-
-All in all, here's a simple sketch of the main components for one stage of the filter. If all goes well I'll build multiple of these.
-
-![](/img/01_mechanical_design.jpg#c)
-
-
-
-## Frequency Response Analysis
-
-Since our mechanical oscillator won't be massless, we might as well model it with some mass. At least then we know what to expect. This gives us a second order ODE:
-$$m \ddot{y}(t) + r \dot{y}(t) + k y(t) = x(t)$$
-(The symbols are defined as above, except for the addition of the mass \\(m\\).)
-
-Let the input function be \\(x(t) = A \sin(\omega t)\\). Then our ODE is solved by:
-$$y(t) = \frac{-A r \omega \cos(\omega t) + A (k - m \omega^2) \sin(\omega t)}{r^2 \omega^2 + (k - m \omega^2)^2}$$
-It has an amplitude of
-$$\frac{A}{\sqrt{r^2 \omega^2 + (k - m \omega^2)^2}}$$
-
-For completeness, the first derivative is
-$$\dot{y}(t) = \frac{A \omega (k - m \omega^2) \cos(\omega t) + A r \omega^2 \sin(\omega t)}{r^2 \omega^2 + (k - m \omega^2)^2}$$
-and its amplitude
-$$\frac{A \omega}{\sqrt{r^2 \omega^2 + (k - m \omega^2)^2}}$$
-
-The output of our filter is the force exerted by the spring, or \\(k y(t)\\). I also care about the maximum displacement, the maximum velocity, and the maximum force exerted by the damping system.
-
-
-

content/06_cnc_machining.md

@@ -81,6 +81,5 @@ Remember when I mentioned that cutting climb vs conventional had a noticeable im
 I'm really happy with the end result. Here's my room, before and after. I can't imagine going back.
 
 ![](/img/06_before.jpg#c)
-
-TODO: after
+![](/img/06_after.jpg#c)
 

content/13_networking.md

@@ -12,11 +12,11 @@ This week we're making machines talk to each other. I've used I2C before, so I'm
 
 ## Board Design
 
-For part of my final project I want to make my own USB audio recording device. So I'll try to develop all the necessary electronics this week. I have the analog circuitry I need from [inputs week](../10_input_devices). But I don't have a board ready to go with a USB-capable microcontroller (bit-banging will not suffice, since I need the CPU to be available for audio processing). I've heard that [LUFA](http://www.fourwalledcubicle.com/LUFA.php) is much nicer than ATMEL's own USB [libraries](https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591207) so I'll try to use that. I'd like to use an XMEGA board, since they are fast, have a good amount of memory for audio applications, and I've used them [recently](../12_machine_week). LUFA's [XMEGA support](http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__x_m_e_g_a_support.html) is technically experimental, but people have been using it since [2013](https://www.avrfreaks.net/forum/lufa-xmega-hello-world). So I think it should be ok.
+For part of my final project I want to make my own USB audio recording device. So I'll try to develop all the necessary electronics this week. I have the analog circuitry I need from [inputs week](../10_input_devices). But I don't have a board ready to go with a USB-capable microcontroller (bit-banging will not suffice, since I need the CPU to be available for audio processing). I've heard that [LUFA](http://www.fourwalledcubicle.com/LUFA.php) is much nicer than ATMEL's own USB [libraries](https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en591207) so I'll try to use that. I'd like to use an XMEGA board, since they are fast, have a good amount of memory for audio applications, and I've used them [recently](../11_machine_week). LUFA's [XMEGA support](http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__x_m_e_g_a_support.html) is technically experimental, but people have been using it since [2013](https://www.avrfreaks.net/forum/lufa-xmega-hello-world). So I think it should be ok.
 
 ![](/img/13_schematic.png)
 
-On the left I have my microcontroller. I'm using an external 16MHz crystal to give it an accurate clock signal. High speed USB 2.0 requires a 48MHz clock, which I can get by multiplying the crystal's output by 3 using the XMEGA's phase locked loop (PLL). On top I have my power section, including a regulator to bump USB's 5V power down to 3.3V, some filtering capacitors, and a power indicator LED. The two circuit groups with op-amps together amplify and bias the audio input, as I learned in [inputs week](../10_input_devices). Finally I have some headers that provide convenient debugging access to certain signals, and a 0-ohm resistor I needed to connect all my ground signals.
+On the left I have my microcontroller. I'm using an external 16MHz crystal to give it an accurate clock signal. High speed USB 2.0 requires a 48MHz clock, which I can get by multiplying the crystal's output by 3 using the XMEGA's phase locked loop (PLL). On top I have my power section, including a regulator to bump USB's 5V power down to 3.3V, some filtering capacitors, and a power indicator LED. The two circuit groups with op-amps together amplify and bias the audio input, as I learned in [inputs week](../09_input_devices). Finally I have some headers that provide convenient debugging access to certain signals, and a 0-ohm resistor I needed to connect all my ground signals.
 
 ![](/img/13_board.png)
 

content/14_wildcard.md

@@ -5,7 +5,7 @@ menu = "main"
 weight = 16
 +++
 
-Files: [audio_interface_2.sch](/designs/13_audio_interface_2.sch) [audio_interface_2.brd](/designs/13_audio_interface_2.brd) [lufa](https://gitlab.cba.mit.edu/erik/lufa) (see Demos/Devices/ClassDriver/MIDI and Demos/Devices/ClassDriver/AudioInput)
+Files: [audio_interface_2.sch](/designs/13_audio_interface_2.sch) [audio_interface_2.brd](/designs/13_audio_interface_2.brd) [lufa](https://github.com/erikstrand/lufa) (see Demos/Devices/ClassDriver/MIDI and Demos/Devices/ClassDriver/AudioInput)
 
 This week there's a lot on the menu: soft robotics, bioprinting, coil plotting, wire EDM, and many more. I'd like to learn them all, but for now I'll continue my exploration of [LUFA](http://www.fourwalledcubicle.com/LUFA.php). So far I have a virtual serial port example working, but let's see what else I can do. Throughout I'll be using the board that I designed and fabricated [last week](../13_networking).
 
@@ -48,5 +48,13 @@ To begin I cleared out the LUFA LED, Button, and ADC code since they're either n
 	#else
 {{< /highlight >}}
 
-Now the compiler complains about invalid registers. Progress! To fix this I need to figure out what the registers they use do on smaller AVR boards, then implement the same thing for XMEGA.
+Now the compiler complains about invalid registers. Progress! To fix this I need to figure out what LUFA is doing with these AVR8 registers, then implement the same thing for XMEGA. This ended up being pretty easy since I was already familiar with the XMEGA's ADC.
+
+At this point the code compiles, and the board is recognized as an audio device, but can't transmit any audio. More precisely, the board tries to transmit audio, in that it does generate samples and pass them to a LUFA method that should transmit them... but nothing gets through to my computer. Still, I'm excited that it can present itself as a CDC audio input at all.
+
+![](/img/14_audio_device.png)
+
+It turns out there was one final set of modifications that had to be made, and I still don't understand why. I accidentally stumbled across [this thread](https://www.avrfreaks.net/forum/lufa-xmega-endpoint-size) on AVRFreaks, in which someone mentions getting audio to function by changing certain USB endpoint and buffer sizes. Sure enough, after modifying the relevant numbers I could pass audio data to my computer. I posted a message on the [LUFA support list](https://groups.google.com/d/msg/lufa-support/3xiXBc5gCnc/uJQ4Zqq8BgAJ) asking why these changes do what they do, but no one has responded yet. Endpoint and buffer sizes of 64 and 128 bytes work, but 256 does not.
+
+And it's still not working properly. When I record audio on my computer, the [result](/audio/14_interface_test.mp3) ends up shorter and higher pitched than intended. So something is probably going wrong with the sample rate. (It's also obviously bit-crushed, but that's expected since the XMEGA is only sampling with 12-bit resolution.) My current theory is that the data transfer is not happening over isochronous USB, and this is confusing the host driver. The results sure sound like a throughput issue (i.e. the audio board sends less samples than the computer expects, so the computer squashes them together and pads the ends with zeros), but even without isochronous USB I think I should have enough bandwidth for one channel of audio. Perhaps it also has to do with jitter (non-isochronous USB doesn't make the same guarantees about packet delivery times).