Excellent. Yes those are essentially the big points, although I would add that sharing memory can also be a good plan, at least in a processing loop. Processing block size is also of concern, as the smaller it can be, the lower the latency (between 64 and 512 samples per block is the range most try to hit). On Mon, Apr 29, 2013 at 11:34 PM, Brendon Costa <brendon.j.costa@gmail.com>wrote:
On Tuesday, 30 April 2013, Rich E wrote:
I would also be very pleased to see a generic audio processing library in boost and would certainly make use of it if one existed. Is the proposed library meant to be useable in real-time applications?
I would expect so and will endeavor to achieve this as I do understand it is often important in the audio space.
I have not myself had to write any hard-realtime applications before so may need some input from others with more experience on this, but as I understand it is a matter of having bounded processing time so taking into account things like not using locks, allowing pre-allocation of memory etc.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost