[Jack-Devel] audioadapter: quality setting important when not changing sampling frequency?
23 Sep
2018
23 Sep
'18
12:02 p.m.
Hi all,
since I only need one microphone when recording I am happy with my
Focusrite Scarlett 2i4. I use the 2i4 for recording and direct
monitoring with the line outputs feeding a headphones amp. I use the
builtin headphones amp as well, both when recording and for mixing.
So far, so good.
Then I wanted 2 additional outputs to feed my active speakers (Neumann
KH120A plus KH805 sub). Because of my room's damping of the high
frequencies (at least compared to my headphones AKG K812) I need an EQ
before them. So I use a Scarlett 2i2 for this purpose, with CALF
Jackhost and a Calf EQ feeding this outputs.
Now I have 2 audio interfaces that can't be synchronized with a
wordclock cable. So I have to drive the 2i2 for the speakers in an async
way. Since I use this output only for mixing/mastering I can live with
some additional latency.
I tried several ways to use the 2nd interface:
- alsa_out
- zita_j2a
- audioadapter (jack_load -i "-dhw:2 -q0 -n2 -p128 -r48000" 2i2 audioadapter)
The audioadapter is the most robust solution and doesn't crash when I
resize jackd's bufsize on the fly, so I'd like to stay with it.
As I played around with the quality setting (-q0 ... -q4) I noticed an
enormous CPU load with -q4 (sinc) but couldn't hear any differences in
audio quality. -q0 sounds as good as -q4.
Now my question:
When the audioadapter has to resample to the same frequency (from 48000
to 48000), do higher -q settings improve the audio quality? As I
understand there is no interpolation needed at all so -q0 would be
enough to have a perfect audio quality.
Any comments/ideas to this?
Regards
Holger
24 Sep
24 Sep
6:51 a.m.
Holger Marzen <holger(a)marzen.de> writes:
Hi all,
since I only need one microphone when recording I am happy with my
Focusrite Scarlett 2i4. I use the 2i4 for recording and direct
monitoring with the line outputs feeding a headphones amp. I use the
builtin headphones amp as well, both when recording and for mixing.
So far, so good.
Then I wanted 2 additional outputs to feed my active speakers (Neumann
KH120A plus KH805 sub). Because of my room's damping of the high
frequencies (at least compared to my headphones AKG K812) I need an EQ
before them. So I use a Scarlett 2i2 for this purpose, with CALF
Jackhost and a Calf EQ feeding this outputs.
This may sound defaitist but I'd lean towards just using an analog EQ
here.
Now I have 2 audio interfaces that can't be
synchronized with a
wordclock cable. So I have to drive the 2i2 for the speakers in an async
way. Since I use this output only for mixing/mastering I can live with
some additional latency.
I tried several ways to use the 2nd interface:
- alsa_out
- zita_j2a
- audioadapter (jack_load -i "-dhw:2 -q0 -n2 -p128 -r48000" 2i2 audioadapter)
The audioadapter is the most robust solution and doesn't crash when I
resize jackd's bufsize on the fly, so I'd like to stay with it.
Wait, I am missing something here. "since I use this output only for
mixing/mastering". How does your first audio adapter even come into
play here?
As I played around with the quality setting (-q0 ...
-q4) I noticed an
enormous CPU load with -q4 (sinc) but couldn't hear any differences in
audio quality. -q0 sounds as good as -q4.
Now my question:
When the audioadapter has to resample to the same frequency (from 48000
to 48000), do higher -q settings improve the audio quality? As I
understand there is no interpolation needed at all so -q0 would be
enough to have a perfect audio quality.
Any comments/ideas to this?
Interpolation will be needed when the clocks drift. Basically you need
to delay by fractional sample amounts and the kind of interpolation used
for that makes a difference with regard to the precision particularly at
comparatively high frequencies. Simple forms of interpolation will
cause fluctuations in the high frequency response. With linear
interpolation, the frequency response will fluctuate between accurate
and a cosine bell shape. That would be rather extreme in the high
range, so you want better than that. The quality of interpolation will
be mostly audible in the high range, though, as long as you _do_
interpolate rather than skipping or duplicating samples (which would
result in clicks across the spectrum).
--
David Kastrup
7:08 a.m.
On Mon, 24 Sep 2018, David Kastrup wrote:
The output of the first adapter is used for
- direct monitoring
- headphone monitoring and mixing/mastering, but without EQ
Or you can simply wait til the "right" moment und use the original
values. But that would not use more CPU depending on the quality
setting. So there seems to bee an interpolation happening.
It looks as if I have to do a looptest (play through the 2nd interface
and record with the 1st) to get an impression how's the signal distorted
at the different quality settings.
Holger Marzen <holger(a)marzen.de> writes:
That was my first approach but I couldn't find an affordable stereo EQ.
Most affordable devices are 2x15 or 2x31 and not 15 or 31 band stereo.
I don't want to set the channels seperately.
Then I wanted 2 additional outputs to feed my
active speakers (Neumann
KH120A plus KH805 sub). Because of my room's damping of the high
frequencies (at least compared to my headphones AKG K812) I need an EQ
before them. So I use a Scarlett 2i2 for this purpose, with CALF
Jackhost and a Calf EQ feeding this outputs.
This may sound defaitist but I'd lean towards just using an analog EQ
here. Now I have 2
audio interfaces that can't be synchronized with a
wordclock cable. So I have to drive the 2i2 for the speakers in an async
way. Since I use this output only for mixing/mastering I can live with
some additional latency.
I tried several ways to use the 2nd interface:
- alsa_out
- zita_j2a
- audioadapter (jack_load -i "-dhw:2 -q0 -n2 -p128 -r48000" 2i2 audioadapter)
The audioadapter is the most robust solution and doesn't crash when I
resize jackd's bufsize on the fly, so I'd like to stay with it.
Wait, I am missing something here. "since I use this output only for
mixing/mastering". How does your first audio adapter even come into
play here? As I played
around with the quality setting (-q0 ... -q4) I noticed an
enormous CPU load with -q4 (sinc) but couldn't hear any differences in
audio quality. -q0 sounds as good as -q4.
Now my question:
When the audioadapter has to resample to the same frequency (from 48000
to 48000), do higher -q settings improve the audio quality? As I
understand there is no interpolation needed at all so -q0 would be
enough to have a perfect audio quality.
Any comments/ideas to this?
Interpolation will be needed when the clocks drift. 
8:18 a.m.
On Mon, September 24, 2018 7:08 am, Holger Marzen wrote:
On Mon, 24 Sep 2018, David Kastrup wrote:
No, digital audio requires continuous and equally spaced sample clock
signals. There is not waiting, that results in clicks, dropouts,
distortion. The only solution is either synchronize the clocks (the best
solution), or use interpolation filters to bridge between the slightly
different clock rates.
--
Chris Caudle
Interpolation will be needed when the clocks
drift.
Or you can simply wait til the "right" moment und use the original
values.
28 Sep
28 Sep
1:51 p.m.
On Mon, 24 Sep 2018, Holger Marzen wrote:
On Mon, 24 Sep 2018, David Kastrup wrote:
Or you can simply wait til the "right" moment und use the original
values. But that would not use more CPU depending on the quality
setting. So there seems to bee an interpolation happening.
It looks as if I have to do a looptest (play through the 2nd interface
and record with the 1st) to get an impression how's the signal distorted
at the different quality settings.
I used the interface that's connected via audioadapter for playback and
the "main" interface that's directly controlled by jackd for recording.
As a signal source I used Audacity with generated sine waves of 5000 and
10000 Hz. I played this signal and recorded it (audio cable between
interfaces). The result showed that the signal gets indeed resampled and
that the quality setting matters.
q0 (SRC_LINEAR) and q1 (SRC_ZERO_ORDER_HOLD) showed a non-flat envelope
of the recorded signal - bad.
q2 (SRC_SINC_FASTEST) showed the desired flat envelope and seems to be
the best compromise between CPU load and quality.
-> That's the setting I'll use from now on.
I cannot to further examination because the spectrum analyzer in
Audacity can't show the harmonics accurately. I expect a single peak in
a sine wave's spectrum but I got a softer curve.
SRC seems to bee an abbreviation for Secret Rabbit Code
http://www.mega-nerd.com/SRC/
Holger Marzen <holger(a)marzen.de> writes:
The output of the first adapter is used for
- direct monitoring
- headphone monitoring and mixing/mastering, but without EQ
As I
played around with the quality setting (-q0 ... -q4) I noticed an
enormous CPU load with -q4 (sinc) but couldn't hear any differences in
audio quality. -q0 sounds as good as -q4.
Now my question:
When the audioadapter has to resample to the same frequency (from 48000
to 48000), do higher -q settings improve the audio quality? As I
understand there is no interpolation needed at all so -q0 would be
enough to have a perfect audio quality.
Any comments/ideas to this?
Interpolation will be needed when the clocks drift.
2:50 p.m.
On Fri, 28 Sep 2018, Holger Marzen wrote:
q2 (SRC_SINC_FASTEST) showed the desired flat envelope
and seems to be
the best compromise between CPU load and quality.
-> That's the setting I'll use from now on.
Unfortunately this leads to errors once in a while (although my Core i7
has no big CPU load), the ringbuffer increases up to 64k. So it's no
stable solution for me.
29 Sep
29 Sep
3:19 a.m.
On Fri, 28 Sep 2018, Holger Marzen wrote:
On Fri, 28 Sep 2018, Holger Marzen wrote:
It seems that playing with jackd's priority can cure the problem. I'll
play around with the parms but this seems to be a good start. Maybe
squeezelite, an audioplayer, was the cause because it was running at a
higher priority than jackd.
jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority
self-connect-mode is "Don't restrict self connect requests"
audio_reservation_init
Acquire audio card Audio1
creating alsa driver ... hw:1|hw:1|128|3|48000|0|0|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 128 frames (2.7 ms), buffer = 3 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: use 3 periods for capture
ALSA: final selected sample format for playback: 32bit integer little-endian
ALSA: use 3 periods for playback
port created: Midi-Through:midi/playback_1
port created: Midi-Through:midi/capture_1
port created: Scarlett-2i4-USB:midi/playback_1
port created: Scarlett-2i4-USB:midi/capture_1
Fixed ringbuffer size = 1024 frames
Audio Interface Description :
Sampling Frequency : 48000, Sample Format : S32_LE, buffering : 256, nperiod : 3
Software inputs : 2, Software outputs : 2
Hardware inputs : 2, Hardware outputs : 2
Card info (address : 0x7fd536e242f0)
ID = USB_1
Driver = USB-Audio
Name = Scarlett 2i2 USB
LongName = Focusrite Scarlett 2i2 USB at usb-0000:00:14.0-1.4.3, high speed
MixerName = USB Mixer
Components = USB1235:8006
--------------
HW Params info (address : 0x7fd52c0bf6e0)
--------------
HW Params info (address : 0x7fd52c0bf950)
--------------
q2 (SRC_SINC_FASTEST) showed the desired flat
envelope and seems to be
the best compromise between CPU load and quality.
-> That's the setting I'll use from now on.
Unfortunately this leads to errors once in a while (although my Core i7
has no big CPU load), the ringbuffer increases up to 64k. So it's no
stable solution for me.
3:29 a.m.
Holger Marzen <holger(a)marzen.de> writes:
On Fri, 28 Sep 2018, Holger Marzen wrote:
Wouldn't jackd be running at realtime priority usually?
On Fri, 28 Sep 2018, Holger Marzen wrote:
It seems that playing with jackd's priority can cure the problem. I'll
play around with the parms but this seems to be a good start. Maybe
squeezelite, an audioplayer, was the cause because it was running at a
higher priority than jackd. q2 (SRC_SINC_FASTEST) showed the desired flat
envelope and seems to be
the best compromise between CPU load and quality.
-> That's the setting I'll use from now on.
Unfortunately this leads to errors once in a while (although my Core i7
has no big CPU load), the ringbuffer increases up to 64k. So it's no
stable solution for me. jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yup. Is squeezelite also running with realtime priority? That would
seem weird. I mean, running an audioplayer while in a recording session
seems weird anyway.
--
David Kastrup
3:34 a.m.
On Sat, 29 Sep 2018, David Kastrup wrote:
Holger Marzen <holger(a)marzen.de> writes:
I was surprised, too, that squeezelite runs in realtime:
RTPRIO TID PID CMD
1 262 262 [i915/signal:0]
1 263 263 [i915/signal:1]
1 264 264 [i915/signal:2]
1 265 265 [i915/signal:4]
5 10207 10194 pulseaudio --exit-idle-time=-1
5 10218 10194 pulseaudio --exit-idle-time=-1
9 10200 10194 pulseaudio --exit-idle-time=-1
9 10202 10194 pulseaudio --exit-idle-time=-1
9 10208 10194 pulseaudio --exit-idle-time=-1
9 10215 10194 pulseaudio --exit-idle-time=-1
9 10219 10194 pulseaudio --exit-idle-time=-1
45 13118 13115 squeezelite -z -n squeezelite-bubu -s mortimer
45 13119 13115 squeezelite -z -n squeezelite-bubu -s mortimer
50 1123 1123 [irq/133-enp5s0]
50 129 129 [irq/122-xhci_hc]
50 130 130 [irq/123-xhci_hc]
50 131 131 [irq/124-xhci_hc]
50 132 132 [irq/125-xhci_hc]
50 133 133 [irq/126-xhci_hc]
50 134 134 [irq/127-xhci_hc]
50 135 135 [irq/128-xhci_hc]
50 136 136 [irq/129-xhci_hc]
50 137 137 [irq/130-xhci_hc]
50 138 138 [irq/12-i8042]
50 139 139 [irq/1-i8042]
50 140 140 [irq/8-rtc0]
50 215 215 [irq/131-rtsx_pc]
50 220 220 [irq/132-ahci[00]
50 260 260 [irq/134-i915]
50 627 627 [irq/135-mei_me]
50 70 70 [irq/9-acpi]
50 746 746 [irq/136-snd_hda]
85 10189 10172 /usr/bin/jackd -P90 -p512 -t2000 -dalsa -r48000 -p128 -n3 -Xseq -dhw:1
85 10190 10172 /usr/bin/jackd -P90 -p512 -t2000 -dalsa -r48000 -p128 -n3 -Xseq -dhw:1
85 10216 10196 calfjackhost --load /home/hm/scripts/calf.d/main
85 10217 10195 /usr/bin/python /usr/bin/jack_mixer -c /home/hm/.jack_mixer
90 10179 10172 /usr/bin/jackd -P90 -p512 -t2000 -dalsa -r48000 -p128 -n3 -Xseq -dhw:1
99 11 11 [migration/0]
99 12 12 [watchdog/0]
99 15 15 [watchdog/1]
99 16 16 [migration/1]
99 21 21 [watchdog/2]
99 22 22 [migration/2]
99 2341 2339 /usr/lib/rtkit/rtkit-daemon
99 27 27 [watchdog/3]
99 28 28 [migration/3]
99 33 33 [watchdog/4]
99 34 34 [migration/4]
99 39 39 [watchdog/5]
99 40 40 [migration/5]
99 45 45 [watchdog/6]
99 46 46 [migration/6]
99 51 51 [watchdog/7]
99 52 52 [migration/7]
On Fri, 28 Sep 2018, Holger Marzen wrote:
Wouldn't jackd be running at realtime priority usually?
On Fri, 28 Sep 2018, Holger Marzen wrote:
It seems that playing with jackd's priority can cure the problem. I'll
play around with the parms but this seems to be a good start. Maybe
squeezelite, an audioplayer, was the cause because it was running at a
higher priority than jackd. q2 (SRC_SINC_FASTEST) showed the desired flat
envelope and seems to be
the best compromise between CPU load and quality.
-> That's the setting I'll use from now on.
Unfortunately this leads to errors once in a while (although my Core i7
has no big CPU load), the ringbuffer increases up to 64k. So it's no
stable solution for me. jackdmp 1.9.11
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2014 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Yup. Is squeezelite also running with realtime priority? That would
seem weird. I mean, running an audioplayer while in a recording session
seems weird anyway.
28 Sep
28 Sep
3:02 p.m.
On Fri, September 28, 2018 1:51 pm, Holger Marzen wrote:
I cannot to further examination because the spectrum
analyzer in
Audacity can't show the harmonics accurately. I expect a single peak in
a sine wave's spectrum but I got a softer curve.
You cannot perform FFT on an arbitrary length of data, it must be power of
2. Because of that most applications will use a window which is
essentially a multiplication in the time domain with an envelope to force
data to 0 at the beginning and end of the time series to enforce no
discontinuities. If you pick your number of samples to be a power of 2
with an integer number of cycles for your test signal you can get away
with no window function, but for an arbitrary signal you must use a window
function (rather the trade off is a large amount of distortion shown
because of signal truncation if you use no window, or a slight spreading
of the signal energy if you use a proper window).
Longer data sets (larger number of FFT points) should result in less
energy spreading in the frequency domain.
--
Chris Caudle
29 Sep
29 Sep
4:06 a.m.
Holger Marzen <holger(a)marzen.de> writes:
On Mon, 24 Sep 2018, David Kastrup wrote:
While it does not apply to either the Scarlett 2i2 or Scarlett 2i4,
quite a few audio cards that cannot be synchronized with a wordclock
cable can be brought to the same clock via an S/PDIF connection.
Just putting this in here in case someone with different hardware has a
similar problem.
--
David Kastrup
Holger Marzen <holger(a)marzen.de> writes:
That was my first approach but I couldn't find an affordable stereo EQ.
Most affordable devices are 2x15 or 2x31 and not 15 or 31 band stereo.
I don't want to set the channels seperately.
> > Now I have 2 audio interfaces that can't be synchronized with a
> > wordclock cable. Then I wanted 2 additional outputs to feed my
active speakers (Neumann
KH120A plus KH805 sub). Because of my room's damping of the high
frequencies (at least compared to my headphones AKG K812) I need an EQ
before them. So I use a Scarlett 2i2 for this purpose, with CALF
Jackhost and a Calf EQ feeding this outputs.
This may sound defaitist but I'd lean towards just using an analog EQ
here.
2281
days inactive
2287
days old
jackaudio@lists.linuxaudio.org
10 comments
3 participants
participants (3)
-
Chris Caudle -
David Kastrup -
Holger Marzen