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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Fri Feb 19 16:15:04 2010
This archive was generated by hypermail 2.1.8 : Fri Feb 19 2010 - 16:15:05 EET