linuxaudio.org

--Apple-Mail-1-518904479

Content-Transfer-Encoding: quoted-printable

Content-Type: text/plain;

	charset=us-ascii
On 19 Feb 2010, at 13:47, Fons Adriaensen wrote:
> On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex stone wrote:

quoted text
>=20

>> The use case i'm thinking of is a crescendo or decrescendo using gain

>> in a continuous stream of data. Will 1/16 reduce the......

>> "smoothness"?

>=20

> No, the DSP code has to perform smoothing anyway, no matter

> what the source of the control data is. Does your GUI fader

> provide smooth audio rate updates ? Of course not, you'd be

> lucky if it updates 25 times per second.

>=20

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.
"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.
--Apple-Mail-1-518904479

Content-Transfer-Encoding: quoted-printable

Content-Type: text/html;

	charset=us-ascii
On 19 Feb 2010, at 13:47, Fons Adriaensen =

wrote:On Fri, Feb 19, 2010 at 04:20:19PM +0300, alex stone =

wrote:The use case i'm thinking of is =

a crescendo or decrescendo using gainin a continuous stream of data. Will 1/16 reduce =

the......"smoothness"?No, the DSP code has to =

perform smoothing anyway, no matterwhat the source of the control =

data is. Does your GUI faderprovide smooth audio rate updates ? Of =

course not, you'd belucky if it updates 25 times per =

second.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."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.=
--Apple-Mail-1-518904479--