On Sat, Feb 13, 2016 at 10:23 PM, jonetsu@teksavvy.com <jonetsu@teksavvy.com> wrote:
> From 'lspci' I got it that the 1010LT is ICE1712, then
> /proc/interrupts is:
>
>  18: 132417 52953 35846 25609 IR-IO-APIC-fasteoi snd_ice1712

See the "Running RtIRQ" section of the real-time tuning page, and you'll
see how to set the priority IRQ for the soundcard (summarized below):
http://openavproductions.com/real-time-latency-tuning/

Summary:
1) Get PID of task that services the soundcard interrupt:
    ps -eo pid,rtprio,comm --sort -rtprio | head -n 30

2) Change the priority of that task:
    chrt -f -p 84   <PID of IRQ handler>

> I have now tried 256 and it is quite good.
"Good" depends on use case ;) The "real" measure of latency is
much more representative than the number of frames in a buffer.

Samplerate, number of buffers, and buffer-size are the 3 factors
for latency. There is also some latency in the ADC and DAC
converters (no flame-discussions indented :)

Its easy to measure the total round-trip delay: jack_iodelay
For full info, read here: http://apps.linuxaudio.org/wiki/jack_latency_tests

For testing, just run jack_iodelay, and then connect a loopback
cable to the soundcard (aka, output -> input). Connect jack_iodelay
to the soundcard's hardware input/output ports you just patched, and
jack_iodelay will tell you a very precise amount of latency.

Example screenshot:
http://openavproductions.com/realtime_latency.png

I run jackd with -p 48 -n1 -r48000, causing a theory of 1ms input,
and 1ms output. Note: -n1 makes no sense, see that jackd/alsa
corrects this to -n2, because one input and one output buffer is
needed.

So in theory, we have 2 * 48 / 48000. round trip latency: 2ms.
jack_iodelay actually measures 6.629.

Why? ADC / DAC conversion delay. The soundcard in use here is
an "Art USB Dual Pre", retails for < 100 euro. These converters
will probably not be particularly low-latency ones.


> Thanks.  I'll take a look at he links you provided.  For now 256 seems
> OK.

For curiosities sake, would you mind measuing the round-trip delay?
(Assuming you have a loopback cable available and time :)
I think you might be surprised... because I always am that its actually
worse than we think, because I usually look at the software "theory"
latency, instead of actually measuring :D

Cheers, -Harry

--

http://www.openavproductions.com