Application hangs when output volume is low

[fitzthum]

When I adjust the volume of one of the analogue outputs on the main panel, the application will hang if the volume is low (around -60 or below it seems). I have to kill the process. When I load the application again, it often crashes again as soon as I try to adjust the volume. If I am really sneaky and raise the volume very quickly I have been able to escape.

I am using Scarlett 8i6 Gen 3 on Ubuntu 22.04

[geoffreybennett]

Is this still happening with the latest release? I can't think what might be causing it besides some bug in gtkdial.c, and I haven't ever seen that issue.

Can you build from source then run:

$ gdb ./alsa-scarlett-gui
(gdb) r
Enable debuginfod for this session? (y or [n]) n
[make it crash]
[if it has hung, press ^C]
(gdb) bt
[send me the output displayed]

[fitzthum]

It still happens with v0.3.3. I ran it through gdb a few times and got fairly consistent behavior. I'm not sure how revealing this will be.

(gdb) r
Starting program: /home/tobin/Documents/alsa-scarlett-gui/src/alsa-scarlett-gui 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff5bff640 (LWP 3737910)]
[New Thread 0x7ffff53fe640 (LWP 3737911)]
[New Thread 0x7ffff4bfd640 (LWP 3737912)]
[New Thread 0x7fffe7fff640 (LWP 3737913)]
[Thread 0x7ffff4bfd640 (LWP 3737912) exited]
[New Thread 0x7ffff4bfd640 (LWP 3737914)]
[New Thread 0x7fffdf7d9640 (LWP 3737915)]
[Thread 0x7ffff4bfd640 (LWP 3737914) exited]
[Thread 0x7fffdf7d9640 (LWP 3737915) exited]
^C
Thread 1 "alsa-scarlett-g" received signal SIGINT, Interrupt.
0x00007ffff6f18dbf in __GI___poll (fds=0x5555555a75d0, nfds=4, timeout=26) at ../sysdeps/unix/sysv/linux/poll.c:29
29	../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
(gdb) bt
#0  0x00007ffff6f18dbf in __GI___poll (fds=0x5555555a75d0, nfds=4, timeout=26) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x00007ffff7f051f6 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x00007ffff7ead3e3 in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x00007ffff73dffb5 in g_application_run () at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#4  0x000055555555d77e in main (argc=1, argv=0x7fffffffdea8) at main.c:70

[geoffreybennett]

You're right, that's not revealing at all. That's essentially the same backtrace that I see when the app is running normally:

(gdb) bt
#0  0x00007ffff6eb234d in poll () at /lib64/libc.so.6
#1  0x00007ffff7f15629 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0
#2  0x00007ffff7eb4b83 in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007ffff72c801d in g_application_run () at /lib64/libgio-2.0.so.0
#4  0x0000000000407319 in main (argc=1, argv=0x7fffffffd8d8) at main.c:70

A bunch of things shooting in the dark that will hopefully help narrow this down:

• What version of Gtk4 do you have installed?

• Do the Flatpak and the packaged .deb versions have the same behaviour?

• "When I load the application again, it often crashes again as soon as I try to adjust the volume." ­— can you catch this with gdb & get a backtrace?

• What is strace ./alsa-scarlett-gui showing when it hangs?
  Normal function looks like this repeated every 50ms:

ioctl(13, SNDRV_CTL_IOCTL_ELEM_READ, 0x7ffcee282770) = 0
recvmsg(7, {msg_namelen=0}, 0)          = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}, {fd=7, events=POLLIN}, {fd=12, events=POLLIN}, {fd=13, events=POLLIN}], 4, 50) = 0 (Timeout)

(that's it polling the meters)

• At the bottom of window-levels.c you can turn off the meter polling by putting a return statement above the call to g_timeout_add():

  return levels_top;  ← add this
  card->meter_gsource_timer = g_timeout_add(50, update_levels_controls, card);
  return levels_top;
}

The strace should be a lot quieter then. Does that make any difference to it hanging? What does the strace output look like when it hangs then?

• In gtkdial.c, place a return statement at the start of the dial_snapshot() function:

static void dial_snapshot(GtkWidget *widget, GtkSnapshot *snapshot)
{
    return;

That will make the dials invisible, but they will still adjust if you mouse click/drag/scroll on them. Does it still hang?

[fitzthum]

What version of Gtk4 do you have installed?

$ apt-cache policy libgtk-4-dev
libgtk-4-dev:
  Installed: 4.6.6+ds-0ubuntu1
  Candidate: 4.6.9+ds-0ubuntu0.22.04.1

Do the Flatpak and the packaged .deb versions have the same behaviour?

Yes for .deb. Not sure about flatpak.

"When I load the application again, it often crashes again as soon as I try to adjust the volume." ­— can you catch this with gdb & get a backtrace?

It's the same.

What is strace ./alsa-scarlett-gui showing when it hangs?

I disabled the meter polling as you suggest. As soon as I enter the error state, strace dumps a ton of the following

poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=17, events=POLLIN}, {fd=19, events=POLLIN}], 4, -1) = 1 ([{fd=9, revents=POLLIN}])

I bypassed the dial_snapshot function as you suggest. The dials aren't shown but the behavior is the same.

[geoffreybennett]

I installed Ubuntu 22.04 and plugged in my 8i6 Gen 3 and have had no luck reproducing this.
Can you first upate all packages with something like sudo apt-get update; sudo apt-get dist-upgrade.
If you run alsamixer, there's no similar problem when you adjust the levels in there is there?
That poll() in a loop looks like something is listening for data from fd 9 & then not doing anything with it, so let's try and narrow down what that fd is.
In alsa.c alsa_add_card_callback(), put return; at the top, and same in alsa_notify_init(). Those changes will disable listening for notifications from ALSA & looking out for new interfaces. The strace should show only two fds in the poll() call.
With the volume level starting low so you can reproduce the problem quickly, can you do strace -o /tmp/asg-trace -f --decode-fds=all ./alsa-scarlett-gui, to capture everything. Then bzip2 /tmp/asg-trace (it should compress well) and send that through.

[fitzthum]

Well the issue went away after dist-upgrade. I guess we can close this. Some issue still lurks, but I can't reproduce it or even be sure that it is directly related to this project. Thanks for taking a look.

Btw I do see one minor graphics glitch with the dials. When the level is -100 or below, the label gets a little wider and causes the dial to resize. I wouldn't really prioritize fixing that, though.

[geoffreybennett]

Oh, that's great news!

With the dial resizing, I don't see that, I guess because I've got a different default font. Can you try what's in the dev branch? I think that issue might already be fixed, although maybe the window will end up resizing even though the dial doesn't. Might need a fix like Sebastian did in 50b7531 instead.

[fitzthum]

dev branch has same issue with resizing.