You don't need an FPGA for accurate timing resolution -- any microcontroller can do this. Even an Arduino can give you ~ microsecond resolution. You just need to stay away from multi-threaded operating systems; Linux is not a real-time OS.
> On Aug 13, 2016, at 09:15, Theo Verelst <theo...@theover.org> wrote: > > Hi all, > > This is one of those things I've been toying in thought about lately (again): > everything on PCs and probably phones and pads as well that does > input/output, be it in the family of proper thread management or actual > devices like Midi and Audio interfaces (and certainly over networks as well), > has weak timing accuracy associated with it. > > When software that does digital signal processing includes musical synthesis, > unless it is an off-line music reader (like Midi files), gets Midi-like note > and control messages, the DSP needs to follow real time messages, and the > current timing accuracy can be limited. For a class of applications where at > least you would want sample accurate control messages, buffering for > efficient pipeline and cache use dictates some form of delay control, which > IMHO should be such that from Midi event to note coming out of the DAC, there > is always a accurately fixed delay. > > Timing midi messages isn't yet necessarily very accurate, for instance here > is some Linux info: > > http://wiki.linuxaudio.org/faq/start?redirect=1#qwhat_is_the_difference_between_jack-midi_and_alsa-midi > > That has also to do with most devices using buffering a a low machine level, > and thread switching isn't going to be brilliantly fast and instantaneous all > by itself, either. So I though it might be a good idea to time stamp Midi > messages with an Fpga (I use a Xilinx Zynq), and built in some form of timing > scheduler in the FPGA to help the kernel. I'm not talking about a hardware > Linux "select()" call as kernel accellerator or single sample delay Fpga DSP, > or upgrading to dozens of Fpga pins at a hundred times Midi clock rate doing > clock edge-accurate timing, but an intersting beginning point for the next > generation of accurate DSP software and interfaces. > > If you have ideas or facts to mention about such projects, please respond. > > T.V. > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp > _______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
