[LAD] CV data protocol in apps.

Simon Jenkins sjenkins at blueyonder.co.uk
Fri Feb 19 13:59:34 UTC 2010


On 18 Feb 2010, at 17:32, alex stone wrote:

> So it's feasible to create another type of port,  (CV/Fs), without
> crippling something else in jack, or damaging the current API?
> 
> If so, surely that would enhance further Jack's capabilities, and open
> it up to more options for devs and users alike.

A reduced rate CV port doesn't really make much possible that's not already possible with a full buffer of values at the audio sampling rate.

Its an optimisation -- *perhaps* -- but thats not the same thing as a new capability.

If a receiving application, for example, wants to update its filter parameters at 1/16th the full sampling rate it is perfectly capable of skipping 16-at-a-time along an audio-rate buffer of values all by itself. Or 8-at-a-time. Or 32 or whatever divisor makes most sense for *that* application, or was configured by the user of that application, or whatever.

Meanwhile this same buffer can be routed at the same time to applications that would prefer the full rate data.





More information about the Linux-audio-dev mailing list