Ingo's questions

I recently bought a new hard disc for my old laptop and installed ubuntu on that new hard disc. When running ubuntu from the new hard disc, I experience some issues with realtime audio that I didn't experience on the same hardware on the previous install. Specifically, after about a minute, I have regular xruns every approximately 3.030 seconds. Given that I have another installation on a different hard drive that runs flawlessly, I am sure that this is not a limitation of my hard ware but rather an issue with software/configuration. However, I am a little lost for where else to look for differences.

I have connected a controller (Novation Launchpad Mini MK3) that I use to interact with Bitwig Studio 3.1.3. Sometimes (but not reliably), it is possible to get almost no xruns if I avoid hitting any keys on the controller. However, this is not reliable and if I stop hitting keys on the controller, the regular cracking of the xruns continues for another approximately 30 seconds (about 10 cracks).

Running with lower cpu frequency (e.g. on battery power) makes things much worse.

Neither of these behaviours happens on the old system.

Soundcards are listed as

$ lspci | grep Audio
00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09)
00:1b.0 Audio device: Intel Corporation Wildcat Point-LP High Definition Audio Controller (rev 03)

I verified that the following are the same on both systems: - /usr/share/alsa/ and contents - /usr/share/alsa-base/ and contents - /usr/share/jackd/ and contents - /usr/share/pulseaudio/ and contents There is no local alsa config in my home directory on either of the two systems.

I am using QJackCtl to start jack (and monitor xruns). My settings are - Sample Rate: 44100 - Frames/Period: 256 - Periods/Buffer: 2 I ticked "realtime" on both systems, however, the old system runs with default priority, which results in the following .jackdrc:

/usr/bin/jackd -dalsa -dhw:PCH -r44100 -p256 -n2

With these settings, I have many xruns on the new system, so I have tried increasing priority up to 80 (my current limit in /etc/security/limits.conf) resulting in the following .jackdrc:

/usr/bin/jackd -P80 -dalsa -dhw:PCH -r44100 -p256 -n2

I played around with these settings on the new system, going up to 2048 Frames/Period and 192k Sample rate but the problem persists and xruns still come very regularly every 3.030 seconds.

Notably, the old system used a generic kernel:

$ uname -a
Linux riemann 4.15.0-50-generic #54-Ubuntu SMP Mon May 6 18:46:08 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

while the new system uses a lowlatency kernel:

$ uname -a
Linux laplace 5.3.0-40-lowlatency #32~18.04.1-Ubuntu SMP PREEMPT Mon Feb 3 14:53:06 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

I note that these are different. When I downgrade the new system to the 4.15.0-50-generic kernel, it doesn't find most of the (inbuild) hardware, wifi-adapter, soundcard, ... Given that the 4.15 kernel is no longer supported with updates by the kernel team, I am not eager to downgrade or resolve the driver issues manually.

I'm quite puzzled and don't know where else to look. I feel that the very regular interval between successive xruns might contain some information, but I can't seem to see what it would tell me.

EDIT: I finally resolved the issue by switching to lubuntu. The lower overhead (and probably less background processes) seems to solve the issue.

I use Mutt to read email and most of my email displays just fine as plain text. For the few exceptions I got used to hitting 'v', selecting the html part of the message and then hitting enter to view that message in my browser. To accomplish that, I had a file ~/.mailcap in my home directory with the following entry

text/html; google-chrome '%s'; test=test -n "$DISPLAY"; needsterminal;

I referred to the file from my .muttrc like this

set mailcap_path="~/.mailcap"

Since upgrading to Ubuntu 18.04, this doesn't open a new browser window anymore, but rather shows the raw html code in mutt. After some searching, I learned that I might have to use 'm' instead of the enter key. Indeed that opens the file in a browser, but instead of rendering the html, it displays the message's raw html.

I should mention that I had a similar problem with PDFs, so I assume it's something about Mutt: After the upgrade, PDFs were suddenly shown in acrobat reader, although my mailcap was configured to use zathura. After adding the quotation marks around my mailcap file in my muttrc, mutt displayed raw PDF code when I hit enter and opened the PDF in zathura when I hit 'm'. Yet, the PDF gets rendered, while HTML doesn't.

EDIT I noticed that saving the message manually as message.html allows me to open the message and have it rendered, but saving it as message makes chrome display the source code. So the following mailcap entry does the job (if I hit 'm'):

text/html; mv '%s' '%s'.html && /usr/bin/sensible-browser '%s'.html && sleep 2 && rm -f '%s'.html; test=test -n "$DISPLAY"; needsterminal;

But this is clearly not how it is supposed to be.

I installed Ubuntu 18.04 on a new ASUS Zenbook recently and virtually everything works almost perfectly. With one exception: Suspend/Resume is broken. Ubuntu seems to be aware of that and by default, selects s2idle:

$ cat /sys/power/mem_sleep
[s2idle] deep

Of course, this means that the laptop's battery is down by about 30% after a day of sleep and it means that the laptop really isn't useful as the mobile device it's supposed to be. I can activate deep sleep by

$ echo deep > /sys/power/mem_sleep

And then the computer does suspend properly (for example via pm-suspend). I can see this because the power indicator LEDs on the side and in the power button start blinking slowly, in the same way as they do on my four-year-old Zenbook. If I wake the laptop up by pressing the power button briefly (or by opening the lid), the computer seems to start waking up (the power indicator LEDs go from blinking to steady light), but neither does the screen turn on, nor does the computer react to the keyboard in any way, nor can I ssh into it.

There are a couple of posts online that seem to find similar behavior with the nouveau driver for NVIDIA graphics cards. But neither does my computer have an NVIDIA card (it has a built-in Intel), nor does the nouveau driver accidentally get loaded.

Another set of online advice recommends using older/new kernels. I've tried kernel versions down to 4.14.41 and up to some 4.18 versions, both none of them changed this behavior.

I'm a little stumped here. I don't even know where to start diagnosing this. Any help would be greatly appreciated.

p.s. Hibernate doesn't work either, but I'm not overly eager to get it to work.