Hi,
Just subscribed to the forum, first of all, to thank you guys for all the work you put in the development of this hardware and audio library. I'm very excited that there's something like this to experiment with audio processing without breaking the bank.
I'm also a software developer and developed some audio unit plugins (filters, delays, loop plugins and the like) for the mac. But mainly I wanted to give some feedback in the form of feature requests and comments from the point of view of a user (me) that could be described as an audiophile. I was looking for some DSP board to build a frequency divider and equalizer for a set of active bi-amped open baffle speakers when I discovered the teensy3.1+audio adapter. I just bought couple to start experimenting with them. I'm also interested in using them for guitar effects, but that's for later.
As far as I know, I understand there's only support for 16 bits because the effective SNR/THD of the current audio adapter is under 90dB. This makes sense for the "driver" of the audio adapter, but I think that making the sample size of the whole library just 16 bits for this reason is somewhat questionable. I also saw in this thread that some guys are trying to use higher quality ADC/DAC chips which may eventually be available to us as an alternative. It would be nice to have the capability to use more bits in this case.
But the main issue I see with 16 bits samples is more serious than having support for higher quality boards. Looking at the library code, most effects are using 32 bit arithmetic to minimize quantization/rounding errors. Also with a 32 bit processor is in many cases more efficient to do 32 bits arithmetic than using 16 bits arithmetic. Now, with a sample size of 16 bits, these effects need to convert samples from 16 to 32 bits, compute the new sample value, and then convert back from 32 to 16 bits. This is obviously less efficient than directly computing a 32 bits output from a 32 bits input.
The problem I think is that, in the process of 32 to 16 bits conversion, simple truncation (shift) produces quantization errors. To avoid these quantization errors, each effect that uses 32 bits arithmetic should perform dithering when going back to 16 bits. Processing dithering for each effect would be quite inefficient, but if no dithering is done, the quantization errors of each effect would at least add up. In many cases, these quantization errors could be multiplied by downstream effects.
Using 32 bits samples would fix this situation. 32 bit samples provide a more than enough dynamic range and precision to deal with most audio processing. Dithering would be needed only before the processed blocks are sent to the DAC and could be done in the audio board "driver", in the correct amount needed by the supported bit depth.
For example, a user could decide to attenuate the 16/24 bits input signal first in order to provide some headroom for the downstream effects chain while still having enough precision to avoid significant DSP quantization/rounding errors. A gain and soft limiter effect at the end of the chain would restore the level of the signal before the DAC.
As an obvious side effect of using 32 bit samples, the memory blocks that contain the samples would be double the size than they are now, but the number of blocks used in a chain of effects is usually small. Effects that need to save a large amount of samples (e.g. long delays) may convert samples to a lower bit count to increase delay times, but this is a design decision of the developer of a particular effect and not enforced by the library.
I think that using 32 bit samples would be a big improvement in audio quality for the library, with some potential performance gains, more clear (i.e. easy to maintain) code, and only a limited hit in memory usage.
I would also love to have support for other sample rates (just 88.2 would be great).
I think that the current ADC/DAC already supports more than 44.1KHz. I also understand that at 88.2KHz, signal processing would be perhaps limited with a 70MHz processor, but it is already possible to process simple equalization and frequency dividers without much trouble at under 100KHz sample rates. In the particular case I'm thinking of, I need to process only one channel to generate output to 2 channels, so the processing of a single channel at 88KHz sample rate is more or less equivalent to 2 channels at 44KHz.
So, it would be great if other sample rates were already supported by the library, even with the current audio adapter. This may be attractive to people that would like to experiment with the possibilities of the platform at higher rates. In the case of audiophiles, higher sample rates would make possible the implementation of high quality filters at audio frequencies close to 20KHz. Yes, I know that upsampling can be done inside effects, but it sounds like a compromise, not very efficient (if done well), and adds unnecessary complexity.
Also, from the perspective of the evolution of the platform (ok, I'm stretching things a little bit here, but it's worth mentioning I think), it is almost sure that a next teensy version would be able to process higher sample rates. I'm not saying to implement higher sample rates right now, but at least have a design, a framework, to support other sample rates, so developers of effects, device drivers, users, are all aware that the sample rate could be different than 44KHz and write more flexible code to support more capable hardware.
I read the whole thread and saw these same topics were discussed some time ago. Just wanted to share my thoughts and give my 2 cents, which is nothing compared with what you guys already did.
Thanks again.