Harry van Haaren wrote: > On Wed, Jan 1, 2014 at 1:21 PM, Joel Roth <joelz@xxxxxxxxx> wrote: > > > I was curious, if doubling the sample rate is a > > practical way to reduce latency for live effects > > processing. I would think it would reduce latency by half. > > > > It would: you mention "practical", i'm not sure I'd call it that. > > > > If one wanted to avoid the tradeoff of handling twice the > > usual amount of audio data, > > CPU load will go up, since there is 2x more of data to process, > which also means every plugin / host has 2x more work to do. > Adds up quickly if you're doing things like convolution reverbs > or other CPU intense processing.. > > I was curious if ALSA sample > > rate conversion, or some other clever hack could be used to > > get low latency advantage of the high sample rate, while > > actually dealing with 48k streams through JACK. > > > Theoretically possible I suppose, it seems like an awful lot of > effort to get a few less ms latency.. > > Latency below ~3ms isn't percievable at all IMO: most will agree. > Why not run jack at 64 frames, 2 buffers? That'll achieve approx > 3ms (on 44.1kHz and 48kHz).. which is fine for the purpose? > Perhaps I'm missing something, are you doing mulitple passes > trough the sound-card that you're adding its latency two or more times? For a live submix, the routing I want to use is exemplified by: system:capture_5 --> Nama:sax_in_1 --( ecasound )--> Nama:sax_out_1 Nama:sax_out_1 --( ecasound )--> system:playback_11 If I understand correctly, the latency not due to Ecasound in this graph is the soundcard roundtrip plus the number of hops which contribute (frames*buffers/sample-rate) latency per. I'm adding one more hop, so that would be 3ms at 64/2, 4ms at 64/3, and 5.3ms at 128/2. Regards, Joel > Cheers, -Harry -- Joel Roth _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
