<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 19 Feb 2010, at 13:47, Fons Adriaensen wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex stone wrote:<br><br><blockquote type="cite">The use case i'm thinking of is a crescendo or decrescendo using gain<br></blockquote><blockquote type="cite">in a continuous stream of data. Will 1/16 reduce the......<br></blockquote><blockquote type="cite">"smoothness"?<br></blockquote><br>No, the DSP code has to perform smoothing anyway, no matter<br>what the source of the control data is. Does your GUI fader<br>provide smooth audio rate updates ? Of course not, you'd be<br>lucky if it updates 25 times per second.<br><font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><br></div><div>If the receiving application is going to smooth the data back up to audio rate anyway then what's the point? If the sender has already got audio-rate data then this is a big *lose* efficiency wise, with the sender spending cycles decimating a buffer that's going to be upsampled as soon as it arrives. Even if the sender hasn't got audio-rate data, it might as well do the smoothing itself rather than push the cost into *all* the apps that receive the data.</div><div><br></div><div>"control rate" optimisations make more sense when you're NOT going to smooth the data, eg when you don't want to update your filter parameters every sample. In this case (as I just said in another post) the receiver can skip down an audio buffer at control rate jumps with no help from anybody.</div><div><br></div></body></html>