Telegram doesn't start when Pulseaudio is running

[bluebell]

With kernel 4.4.0 on my Xubuntu 16.10 everything is fine:

Code: Select all

[…]
connect(23, {sa_family=AF_LOCAL, sun_path="/run/user/1000/pulse/native"}, 110) = 0
write(22, "W", 1)                       = 1
clock_gettime(CLOCK_MONOTONIC, {52, 963145311}) = 0
write(22, "W", 1)                       = 1
futex(0x7ff40515d7b0, FUTEX_UNLOCK_PI_PRIVATE, 33) = 0
futex(0x7ff40515d7e4, FUTEX_WAIT_REQUEUE_PI_PRIVATE, 9, NULL, 0x7ff40515d7b0) = 0
write(22, "W", 1)                       = 1
clock_gettime(CLOCK_MONOTONIC, {52, 963516310}) = 0
write(22, "W", 1)                       = 1
futex(0x7ff40515d7b0, FUTEX_UNLOCK_PI_PRIVATE, 33) = 0
futex(0x7ff40515d7e4, FUTEX_WAIT_REQUEUE_PI_PRIVATE, 11, NULL, 0x7ff40515d7b0) = 0
write(22, "W", 1)                       = 1
clock_gettime(CLOCK_MONOTONIC, {52, 963686445}) = 0
write(22, "W", 1)                       = 1
futex(0x7ff40515d7b0, FUTEX_UNLOCK_PI_PRIVATE, 33) = 0
futex(0x7ff40515d7e4, FUTEX_WAIT_REQUEUE_PI_PRIVATE, 13, NULL, 0x7ff40515d7b0) = 0
write(22, "W", 1)                       = 1
close(25)                               = 0
close(24)                               = 0
munmap(0x7ff3f65fe000, 67112960)        = 0
write(22, "W", 1)                       = 1
close(23)                               = 0
munmap(0x7ff3fa5ff000, 67112960)        = 0
unlink("/dev/shm/pulse-shm-4254065881") = 0
futex(0x7ff40515d7b0, FUTEX_UNLOCK_PI_PRIVATE, 33) = 0
write(17, "[2023.10.15 12:16:44] Audio Capt"..., 126) = 126 
[…]

But with kernel 5.15.134 Telegram hangs before it can display its UI:

Code: Select all

[…]
connect(26, {sa_family=AF_LOCAL, sun_path="/run/user/1000/pulse/native"}, 110) = 0
sendto(25, "W", 1, MSG_NOSIGNAL, NULL, 0) = -1 ENOTSOCK (Socket operation on non-socket)
write(25, "W", 1)                       = 1
clock_gettime(CLOCK_MONOTONIC, {50, 589784800}) = 0
write(25, "W", 1)                       = 1
futex(0x7f4ba8d4ecf0, FUTEX_UNLOCK_PI_PRIVATE, 33) = -1 EPERM (Operation not permitted)
futex(0x7f4ba8d4ed24, FUTEX_WAIT_REQUEUE_PI_PRIVATE, 1, NULL, 0x7f4ba8d4ecf0) = ? ERESTARTNOINTR (To be restarted)
=> at this point Telegram hangs

Any idea? Is there a new kernel variable with late v5 kernels that has to be set for backwards compatibility? New permissions for my user that have to be set?

[sunrat]

I don't use *buntu but the telegram-desktop version from Debian repo, currently v.4.6.5, is working fine here in Debian Bullseye with Liquorix kernel 6.4.x
Are you using a recent version of Telegram?

[bluebell]

I don't use *buntu but the telegram-desktop version from Debian repo, currently v.4.6.5, is working fine here in Debian Bullseye with Liquorix kernel 6.4.x
Are you using a recent version of Telegram?

Yes. 4.9.9 from telegram.org. It has its own updater.

But the problem occurs with 4.2.4 and 4.5.3 as well.

[autostatic]

And this is on the same installation where it works with the older kernel but not with the newer one?

[bluebell]

And this is on the same installation where it works with the older kernel but not with the newer one?

Yep. When I boot the v4 kernel everything works as expected, when I boot the v5 kernel I get the problem with Telegram and Pulseaudio.

[autostatic]

That's weird! Any difference in file permissions of /run/user/1000/pulse/native between those two kernels?

[bluebell]

That's weird! Any difference in file permissions of /run/user/1000/pulse/native between those two kernels?

No difference.

Kernel v4:

Code: Select all

drwx------ 2 hm hm 80 Okt 15 18:06 /run/user/1000/pulse
srwxrwxrwx 1 hm hm 0 Okt 15 18:06 /run/user/1000/pulse/native

Kernel v5:

Code: Select all

drwx------ 2 hm hm 80 Okt 15 18:10 /run/user/1000/pulse
srwxrwxrwx 1 hm hm 0 Okt 15 18:10 /run/user/1000/pulse/native

[autostatic]

The plot thickens. You might think this is a permissions error when looking at the strace output. And also, PA is a user space app, a different kernel shouldn't make a difference. Unless the newer kernel has difficulties with your audio devices. aplay -l looks the same too with both kernels?

[bluebell]

The plot thickens. You might think this is a permissions error when looking at the strace output. And also, PA is a user space app, a different kernel shouldn't make a difference. Unless the newer kernel has difficulties with your audio devices. aplay -l looks the same too with both kernels?

Pulseaudio outputs to the already running jack2 and isn't aware which hardware is attached.

I guess I have to compile a recent Pulseaudio to find out more.

EDIT:
No difference with a more recent version pulseaudio-14.2. So I give up for now.

[Linuxmusician01]

[...] kernel 4.4.0 on my Xubuntu 16.10

That's a very, very old distro. Why would you want to update the kernel if you do not have problems?

[bluebell]

[...] kernel 4.4.0 on my Xubuntu 16.10

That's a very, very old distro. Why would you want to update the kernel if you do not have problems?

For @Drumfix' ua101 replacement driver for my MOTU UltraLite AVB (doesn't compile with a v4 kernel) and improvements for my Scarlett 18i20.

Works fine.

Of course there are some problems. I can compile Qtractor either with CLAP or gtkmm support. gcc5 compiles programs using gtkmm, gcc7 and 9 compile programs using CLAP. I can't have both. Earlier or later I'll have to install a new system and the game will begin again.

[tavasti]

With kernel 4.4.0 on my Xubuntu 16.10 everything is fine:

Running anything network-related on so old system feels pretty risky for me. No updates for last 6 years

[bluebell]

With kernel 4.4.0 on my Xubuntu 16.10 everything is fine:

Running anything network-related on so old system feels pretty risky for me. No updates for last 6 years

It must be totally secure because I haven't got security updates for years.

Even my private servers connected with a packet filter are not up to date because I update only to fix relevant security holes that can't be fixed by stopping or deinstalling services that are not needed. Result: My machines weren't vulnerable by the glibc bug because the glibc wasn't recent enough to have this bug.

I remember old times when I was a systems programmer for IBM mainframes. IBM field technicians told us "Don't fix what ain't broken."

Times have changed. If I still had to run servers for a living I'd join the "recent updates are more important than running systems" religion for my employer.

[autostatic]

Totally unrelated but a free Ubuntu One account allows you to use ESM on 5 machines. This will keep your 16.04 machine secure until 2026.

Edit: you're running a non-LTS version, 16.10. No ESM for those versions

[bluebell]

Totally unrelated but a free Ubuntu One account allows you to use ESM on 5 machines. This will keep your 16.04 machine secure until 2026.

Edit: you're running a non-LTS version, 16.10. No ESM for those versions

Sorry, it's 16.04 LTS. I think about it for my mailserver. Updating from 12.04 via 14.04 to 16.04 was a pain in the ass. Don't feel like updating to 18.x or 20.x in the next months.