Ubuntu – Why the process priority of Pulseaudio is -11

As none of the other answers worked on my system (Ubuntu 18.04 LTS on a 2012 MacBook Air), I found my solution on the german ubuntuusers wiki. English summary of the german instructions:

The choppy output might be caused by the A2DP implementation, and how it buffers sound before encoding it. For me, changing this buffer's size solved the choppy sound problem. You need to perform three steps:

1. Find necessary info about the bluetooth device (while it is connected!)

   pactl list | grep -Pzo '.*bluez_card(.*\n)*'
   

The output should be something like

    Name: bluez_card.28_11_A5_84_B6_F9
    Driver: module-bluez5-device.c
    ...
    Ports:
    speaker-output: Speaker (priority: 0, latency offset: 0 usec, available)
        Part of profile(s): a2dp_sink, headset_head_unit
    speaker-input: Bluetooth Input (priority: 0, latency offset: 0 usec, not available)
        Part of profile(s): headset_head_unit

We see that the buffers have currently 0 latency. In the next step, you will need the NAME and PORT of your output. In this example, these are bluez_card.28_11_A5_84_B6_F9 and speaker-output, respectively.

2. Set the buffer size (latency) of your card to a suitable value with this command pattern:

   pactl set-port-latency-offset <NAME> <PORT> <BUFFER_SIZE_MICROSECONDS> 
   

The latency unit of the following command is microseconds, so I'm using a 50 millisecond buffer for my command here:

    pactl set-port-latency-offset bluez_card.28_11_A5_84_B6_F9 speaker-output 50000 

3. Restart your bluetooth service to apply your change

   sudo service bluetooth restart
   

As there is usually no documentation about this, you may have to experiment with higher or lower buffer values. Many people people posted their working latencies in the comments to this answer. Check them out for guidance on the latency value.

According to this formula, the processes with higher nice values have higher priorities, but some resources says that the process with low nice value has more priority.

Close, but no cookie. That the numeric value of priority is high doesn't mean the priority is high. top reads the priority from /proc/<pid>/stat. See man 5 proc for the explanation of that file:

(18) priority  %ld
    (Explanation  for Linux 2.6) For processes running a real-time scheduling
    policy (policy below; see sched_setscheduler(2)),  this  is  the  negated
    scheduling  priority,  minus  one;  that  is, a number in the range -2 to
    -100, corresponding to real-time  priorities  1  to  99.   For  processes
    running  under  a  non-real-time  scheduling policy, this is the raw nice
    value (setpriority(2)) as represented in the kernel.  The  kernel  stores
    nice  values  as numbers in the range 0 (high) to 39 (low), corresponding
    to the user-visible nice range of -20 to 19.

    Before Linux 2.6,  this  was  a  scaled  value  based  on  the  scheduler
    weighting given to this process.

So: PR goes from 0 (high) to 39 (low).