Could you show some more info about your solution for those who don't have Octave installed (yet)?
It is not the solution, but a simulation of the potential outcome. The simulation assumes that the carriers are generated via (software) DDS and AM-modulated (regular double side-band modulation) with the 16 digital signals (after band-limiting them with a pulse shaping filter). Data streams are supposed to be async, with a (maximum) bit rate of 84.375 bits/s each. Carriers are 384.375, 553.125, 721.875, 890.625, 1059.375, 1228.125, 1396.875, 1565.625, 1734.375, 1903.125, 2071.875, 2240.625, 2409.375, 2578.125, 2746.875, 2915.625 Hz. Hopefully "KISS enough"
The most computationaly expensive thing at the sender side is likely the pulse shaping filter.
Receiver side assumes sampling the audio signal at 10.8kSa/s sampling rate, a 384.375Hz quadrature LO (realized as software DDS as well), mixer (one complex multiplication per sample), and overlapping 128-point FFT (112 points overlap -> 8 FFT evaluations per symbol).
EDIT: Prior decimation could reduce the FFT size, but OTOH requires an additional decimation filter. I'm not sure if that were computationally cheaper, after all. And decimation were still limited to 2x, since the transition band of the decimation filter needs to be > 0, and the 2700Hz channel bandwidth is fully occupied by the 16 sub-bands.
Even w/o Octave installed you can still look at the code, of course
I wonder you still use initial upconverter with FFT16 instead of let's say 16 (middle'ish) bins of FFT64 or even FFT32 w/o upconverter?
I did not assume FFT on the sender side. OFDM requires the insertion of a guard interval between the symbols (mostly a
cyclic prefix ->
CP-OFDM), so I guess symbol timing recovery cannot be renounced at the receiver, and the receiver cannot work async? Or can it? The guard interval also reduces symbol rate (which can be compensated OTOH by modulating multiple bits onto one carrier). But likely no longer "KISS enough" for the OP then...
Also did take a brief look at gnuradio docs. Seems that a huge nuber of building blocks are readily avalable, which are suitable to compose various kinds of modems. So Raspberry PI + USB sound card + gnuradio might be an option, too?