Linux: big problems with audio (2)

Official support for: bitwig.com
RELATED
PRODUCTS

Post

Great this is like the most detailed bug report ever by the way. :) This actually made me realise that my rtirq-init script is not running unless I provoke it. I'm wondering if your soundcard is just not up to handling such a low latency? You could try with settings a lot slower and see if the crackles still persist.

Another thing from one of your previous posts, it is possible to switch all/most pulseaudio streams to use jack by using a frontend like pavucontrol ( I think the settings stick only during run-time tho ).

And can you see if your pulse jack modules are actually running too thanks .

Post

Thanks. I will see how it goes before adding any other details. I have noticed yesterday that when the audio subsystem reaches a certain state, starting Bitwig and simply pressing on the Audio enable/disable icon at the top left will start the crackling for say, a vlc application playing an mp4 file. During that time Mixbus32C (Ardour in other words) plays a project just fine.

What I do now, as a test, is to run the following as soon as the machine has booted:

Code: Select all

pactl unload-module module-jackdbus-detect
pactl unload-module module-alsa-card
pactl unload-module module-udev-detect
I keep an eye on Bitwig interaction with the audio subsystem since version 1.3.11 crashed big time when playing audio samples from the Samples Browser in Linux. Quickly version 1.3.12 was out to fix this. There is somethign that might be going on, and the enabling/disabling of the audio engine described above directly related to the number of crackle being heard looks like interaction.

OTOH, I now also disabled the MB audio interface, to see if it has any effect. The audio card is a 1010LT.

Cheers. Tschüß.

Post

mevla wrote:I have noticed yesterday that when the audio subsystem reaches a certain state, starting Bitwig and simply pressing on the Audio enable/disable icon at the top left will start the crackling for say, a vlc application playing an mp4 file.
Maybe your buffer is too short. Try to start jack with 4 or 6 buffers instead of two.
In my case 4 * 64 buffers is more stable than 2 * 128

Post

mevla wrote:
OTOH, I now also disabled the MB audio interface, to see if it has any effect. The audio card is a 1010LT.

Cheers. Tschüß.
Priority for linux audio has two maximum settings, in /etc/security/limits.d/audio.conf
it is 99 but in qjackctl, the maximum is 89. I'm not sure of any effect from
your jackd.rc file setting being 95, thus over the limit, but it might reject that value,
and employ a low default? Worth trying at 89.

I use m-Audio 24/96 in Mint 17, below is my audio.conf setting, for years.
I also used synaptic to remove all of pulseaudio items, leaving only libpulse
due to a dependency.

@audio - rtprio 99
@audio - memlock unlimited
@audio - nice -19

Cheers

Post

It is now back at -P80 for jackd. I will try at 89, if that makes a difference. The audio.conf is just about the same, with rtprio being 95 instead of 99. As I've seen earlier today, copying files to Bitwig's samples directory will instantly provoke the crackling, the millisecond they are copied. Instant. I could not believe it when it happened. Nothing else was running apart from Bitwig playing a drum machine MIDI loop and firefox occasionally playing some audio samples.

Cheers.

Post

Update.

About two weeks later, and with some experiments, it looks like the problem with the crackling noise was due to using too small buffers with jackd (this is a Linux system).

In other words, the previous way to launch jackd was using 64 frames between JACK process() calls:

/usr/bin/jackd --sync -T -P80 -ndefault -dalsa -dhw:M1010LT -r44100 -p64 -n4

The new incantation which seemingly has gotten rid of the crackling problem uses 256 frames:

/usr/bin/jackd --sync -T -P80 -ndefault -dalsa -dhw:M1010LT -r44100 -p256 -n4
Last edited by mevla on Fri Sep 23, 2016 1:49 am, edited 1 time in total.

Post

I recently did a fresh install with Linux Mint 18 and noticed crackle that I never experienced with my old configuration.

This thread is a huge help. I'm going to fix this as soon as I get home from work! Thank you fellow Linux users.

Post

There are a few other things that I did in Linux Mint 17. The inital problem was having delay in the headphones while recording acoustic guitar. Here are my notes, provided as-is:

Code: Select all

Audio card: M-Audio Delta 1010LT
CPU:        i5-3570 CPU @ 3.40GHz
RAM:        16G
jackd:      1.9.9.5
OS:         Linux Mint 17

1) install linux-lowlatency (the meta-package)

   Note: In this case the kernel went from 3.13.0-24-generic to
   3.13.0-77-lowlatency, which is not much of a change.  Some reported
   that the jump can be more significant.

2a) install rtirq-init

2b) In /etc/default/rtirq, put the name of the sound card

   #RTIRQ_NAME_LIST="rtc snd usb i8042"
   RTIRQ_NAME_LIST="snd_ice1712"

	 TODO: How to obtain the name of the sound card ?

2c) establish priority

   % /etc/init.d/rtirq start
   Setting IRQ priorities: start [snd_ice1712] irq=18 pid=547 prio=90: OK.

3a) In /etc/security/limits.d/audio.conf :
   @audio   -  rtprio     95
   @audio   -  memlock    unlimited

3b) dpkg-reconfigure -p high jackd

4) scaling_governor adjustment
   echo -n performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
   echo -n performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
   echo -n performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
   echo -n performance > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor

   TODO: See if modif in /etc/init.d/ondemand is OK after reboot

5) Invoke jackd with prio 80, number of frames 256

   /usr/bin/jackd --sync -T -P80 -ndefault -dalsa -dhw:M1010LT -r44100 -p256 -n4

   Note: the above line can be put in ~/.jackrc for automatic

6) User is part of the audio group:

   % cat /etc/group | grep audio
   audio:x:29:pulse,mevla

7) reboot
And here are some checks:

Code: Select all

A) /etc/init.d/rtirq status

  PID CLS RTPRIO  NI PRI %CPU STAT COMMAND
  449 FF      90   - 130  0.7 S    irq/18-snd_ice1
   47 FF      50   -  90  0.0 S    irq/9-acpi

B) top (use H option)

  PR is priority.  Should be in the range shown here.

  PR  NI    VIRT    RES    SHR S %CPU %MEM     TIME+ COMMAND
 -76   0 3249132 498212 127200 S 28,2  3,1   0:11.58 ardour-4.6.0
 -76   0 3249132 498212 127200 R 26,9  3,1   0:11.93 ardour-4.6.0
 -76   0 3249132 498212 127200 R 26,6  3,1   0:11.79 ardour-4.6.0
  20   0 3249132 498212 127200 S  6,0  3,1   0:08.53 ardour-4.6.0
 -81   0  219412  91232  83960 S  4,3  0,6   0:10.22 jackd
 -76   0 3249132 498212 127200 S  2,7  3,1   0:01.58 ardour-4.6.0

C) cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

performance
performance
performance
performance

D) cat /proc/interrupts 

     CPU0 CPU1 CPU2 CPU3       
  0:  28    0   0    0  IR-IO-APIC-edge   timer
  1:   3    0   0    0  IR-IO-APIC-edge   i8042
  4:   4    1   0    1  IR-IO-APIC-edge    
  8:   0    1   0    0  IR-IO-APIC-edge   rtc0
  9:   0    0   0    4  IR-IO-APIC-fasteoi acpi
 12:   2    1   1    0  IR-IO-APIC-edge   i8042

 18: 721931 205637 141868 54923  \
      IR-IO-APIC-fasteoi   snd_ice1712
You can also test the acutal round-trip latency:

Code: Select all

apt-get install jdelay
jack_iodelay
use qjackctl to connect jack_iodelay input and output

Use a RCA cable, only one, mono.  Connect one end to a playback port
and the other end to a capture port.  Launch jack_iodelay.  Connect
using qjackctl.  In this case, the RCA connection is from the
headphone white output jack to the # 6 red input jack of the 1010LT card.

Measurements for kernel 3.13.0-24-generic

stop qjackctl
/usr/bin/jackd -T -ndefault -dalsa -dhw:M1010LT -r44100 -p1024 -n2
configuring for 44100Hz, period = 1024 frames (23.2 ms), buffer = 2 periods
start qjackctl
make connections (see jdelayConnections.png)
jack_iodelay
 3133.532 frames     71.055 ms total roundtrip latency

stop qjackctl
/usr/bin/jackd -T -ndefault -dalsa -dhw:M1010LT -r44100 -p512 -n2
configuring for 44100Hz, period = 512 frames (11.6 ms), buffer = 2 periods
start qjackctl
make connections (see jdelayConnections.png)
jack_iodelay
  1597.528 frames     36.225 ms total roundtrip latency

stop qjackctl
/usr/bin/jackd -T -ndefault -dalsa -dhw:M1010LT -r44100 -p256 -n2
configuring for 44100Hz, period = 256 frames (5.8 ms), buffer = 2 periods
start qjackctl
make connections (see jdelayConnections.png)
jack_iodelay
  829.529 frames     18.810 ms total roundtrip latency

stop qjackctl
/usr/bin/jackd -T -ndefault -dalsa -dhw:M1010LT -r44100 -p128 -n2
configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods
start qjackctl
make connections (see jdelayConnections.png)
jack_iodelay
   445.529 frames     10.103 ms total roundtrip latency

stop qjackctl
/usr/bin/jackd -T -ndefault -dalsa -dhw:M1010LT -r44100 -p64 -n2
configuring for 44100Hz, period = 64 frames (1.5 ms), buffer = 2 periods
start qjackctl
make connections (see jdelayConnections.png)
jack_iodelay
   253.529 frames      5.749 ms total roundtrip latency

stop qjackctl
/usr/bin/jackd -T -ndefault -dalsa -dhw:M1010LT -r44100 -p32 -n2
configuring for 44100Hz, period = 32 frames (0.7 ms), buffer = 2 periods
start qjackctl
make connections (see jdelayConnections.png)
jack_iodelay
   157.529 frames      3.572 ms total roundtrip latency
The idea is to strike a balance. Trying to go too fast will not produce necessarily good results.
jdelayConnections.jpg
You do not have the required permissions to view the files attached to this post.

Post Reply

Return to “Bitwig”