Re: [LAU] Sound card for recording guitar

From: Ralf Mardorf <ralf.mardorf@email-addr-hidden-dsl.net>
Date: Fri Dec 20 2013 - 18:47:48 EET

On Fri, 2013-12-20 at 15:04 +0100, Clemens Ladisch wrote:
> Ralf Mardorf wrote:
> > I never tested it myself, however, I remember that it often is mentioned
> > not to use -n >2. Is there a reason to avoid -n >2 or is t juts a myth?
>
> The buffer size is the product of the period size (-p) and the number of
> periods (-n). A larger buffer size increases latency, but reduces the
> risk of underruns. A smaller period size _slightly_ increases CPU usage
> because of the overhead needed for handling a period.
>
> Therefore, when optimizing for low latency, one typcially uses two
> periods and makes -p as small as possible.
>
> With USB devices, the period boundaries (where interrupts are supposed
> to happen) are not necessarily coincident with the USB frame boundaries
> (where interrupts actually happen). This results in delays (jitter) of
> up to 1 ms in the timing of period interrupts; with very small buffer
> sizes, this increases the risk of underruns greatly. So if, e.g., the
> machine is not able to handle "-p 64 -n 2" reliably, increasing the
> number of periods to 3 results in lower latency (3*64=192) than
> increasing the period size (2*128=256). (Using "-p 96 -n 2" would have
> the same latency, but works only if that particular Jack version allows
> period sizes that are not a power of two.)

Thank you too. Jeremy already posted a link to a thread where _you_
explained it :) (less detailed than now). Résumé: As Fons pointed out,
the sound quality isn't affected by the -n size. I assume even sync
between audio and MIDI, between several devices isn't affected by the -n
size, but just some prosumer USB devices could cause less good sync
between audio and MIDI, irrelevant for this thread.

Regards,
Ralf

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Fri Dec 20 20:15:02 2013

This archive was generated by hypermail 2.1.8 : Fri Dec 20 2013 - 20:15:02 EET