Telegram causes music in rhythmbox (gstreamer applications) to play faster!? #1548

cookiengineer · 2016-01-23T15:12:45Z

When I startup telegram, the music in my applications play around 1.5 times the usual speed. I have not yet any kind of hint what causes the bug to appear, I just know that it always happens when starting Telegram.

Hardware used: Intel NUC (i5 and Intel Audio dedicated hardware, no additions).
OS used: UbuntuGNOME 15.10

Does anybody have an idea how to debug such a thing? Is it most likely pulseaudio-related?

cookiengineer · 2016-02-02T13:22:42Z

I can now reproduce the bug, but I have no clue how to figure out what causes it. strace is so big that it's a couple hundred megabytes big with all the pulseaudio stuff going on.

Steps to reproduce (any Ubuntu with GNOME or GTK3 installed (also XFCE)):

Start rhythmbox or any other gstreamer-based media player like totem
Start playing back a music track
Open telegram binary

This will crash the pulseaudio frequency (or timer!?), so track will be played back around 1,5x times faster.

Fixes:

When Bug occurs, go to top right corner in GNOME shell
Open Settings from there
Open Sound Settings

When Sound Settings window was initialized, the bug is fixed. Can be reproduced afterwards following the steps above (telegram must be closed and re-opened, also from the systray bar).

ghost · 2017-02-08T18:39:13Z

Hey there!

We're automatically closing this issue since there was no activity in this issue since 372 days ago. We therefore assume that the user has lost interest or resolved the problem on their own. Closed issues that remain inactive for a long period may get automatically locked.

Don't worry though; if this is in error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

_{(Please note that this is an automated comment.)}

cookiengineer · 2017-02-09T04:06:23Z

This bug has not been magically fixed. It is still active and still telegram is causing change of frequency on devices that have not 44kHz by default.

stek29 · 2017-04-03T01:03:43Z

Is this Telegram issue for sure?
Also, can you test other OpenAL based apps?

cookiengineer · 2017-04-03T05:14:42Z

I've been using the same identical setup for over 5 years now. It is telegram, for absolutely nothing-else-breaks sure. Every other application, even games, work perfectly without any issue.

Telegram keeps always resetting the frequency of the sound device, which it should not do. Eversince I reported this bug, this issue stays the same and is still causing troubles for devices that have no 44.1kHz frequency.

Yes it is confirmed, the current version of Telegram is still causing the same problems. Yes everything is as up-to-date as possible; as I'm using ArchLinux. Yes, it is still the same issue on Debian Jessie, Ubuntu 16.10, ArchLinux and even on XFCE setups.

So this is definitely a Telegram Bug, and nothing that is caused by the sound daemon. Any other application that plays back sound will be affected, even Chromium, Firefox, GNOME mplayer (and every other app you can imagine) because Telegram keeps resetting the goddamn frequency to 44.1kHz.

That is what Telegram is causing and no other App is causing. I cannot report or explain the bug in more detail, as this is exactly what happens. 100% of the Telegram opening time. 100%. Every single start of Telegram resets the device frequency, reproducible.

I am definitely sure the code that causes this problems is either media_audio_ffmpeg_loader#L201 or media_child_ffmpeg_loader#L72 as both have static comparisons of frequencies until they re-initialize the audio setup. And that is exactly what both methods shouldn't do. If they can't support the frequency, just do nothing.

gaelanlloyd · 2017-08-07T16:07:09Z

I have the same issue too and came here to open a ticket about it. Arch Linux here. If I'm playing music in CMUS, VLC, Rhythmbox, etc., and then I start Telegram, the audio stream pauses for a moment, Telegram loads, and then the audio resumes at a higher pitch. The only fix I've seen is to do pulseaudio -k to restart the PulseAudio daemon, but I'd rather not have to do that every time I launch Telegram. Can this ticket be re-opened?

mtaalas · 2018-07-21T20:01:08Z

This is a huge issue on Windows 7 platform as well.

I use MOTU 828MKII audio interface for music production and I try to run my system on one single sampling rate no matter what. (48khz, 96khz or what ever I need or the project was made in) and every single time I start telegram it'll reset the sampling rate to 44.1khz and all the other programs are still expecting another sampling rate and audio is slowed down because of the mismatch. It's even more infuriating since I have disabled sounds on telegram and thus the audio initialization routine is completely unnecessary.

Resetting the sample-rate back to what ever it was isn't that simple since it can't be done from my audio interfaces driver unless the audio device isn't being used at all (I have to shut down all applications using it first)

What ever the case may be, Telegram should respect the current sampling rate of the system and never ever try to change it on its own. What would be better, if I could set the sample rate that telegram requests from the system like in any decent audio software if I know what i'm doing (default to current sampling-rate by default add a tick "request sampling rate" on advanced menu).

john-preston · 2018-07-21T20:27:07Z

@mtaalas Telegram uses OpenAL library for notifications audio and music / voice messages / video files playback. Perhaps this could be reported there. Or maybe I use the library wrongly :(

zerodayyy · 2019-07-23T19:45:49Z

Hello, is there any progress on this issue? It's been more than 3 years and the problem still persists on devices that use any sample rate other than 44.1kHz (e.g. I use an external Focusrite audio interface running at 48kHz). This is annoying and the only workaround so far is not using Telegram Desktop at all.

Lerke · 2019-08-18T17:28:01Z

+1 to this issue. Like @zerodayyy, I also have a Focusrite interface. Every time Telegram Desktop is launched, all of my system audio gets sped up. The only way to work around this is by having Telegram auto-launch on boot and manually restarting pulseaudio with pulseaudio -k and pulseaudio -D.

Aryojaam · 2019-10-05T11:52:30Z

I have the same issue. I am using Ubuntu 19.04. I have a Behringer UMC204Hd audio interface connected. I can usually fix this problem by just opening Ubuntu settings and just navigating to sound options. Does this fix work for you guys as well? @zerodayyy @Lerke

zerodayyy · 2019-10-05T14:25:25Z

No, that doesn't work for me. Anyway, I'm still waiting for that to be fixed.

…

On Sat, Oct 5, 2019, 2:53 PM Aryojaam ***@***.***> wrote: I have the same issue. I am using Ubuntu 19.04. I have a Behringer UMC204Hd audio interface connected. I can usually fix this problem by just opening Ubuntu settings and just navigating to sound options. Does this fix work for you guys as well? @zerodayyy <https://github.com/zerodayyy> @Lerke <https://github.com/Lerke> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1548?email_source=notifications&email_token=AL24WPZR7SGHMAJDGVYHXT3QNB52BA5CNFSM4BZLYHG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEANQWGQ#issuecomment-538643226>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AL24WP7WDRSVKMN6TNGJ4VLQNB52BANCNFSM4BZLYHGQ> .

tnagler · 2019-10-23T13:32:55Z

Same issue here with Ubuntu 19.04 and NI Komplete Audio 2 interface. For me it's "fixed" by (temporarily) switching to a different device in the Sound Settings.

majcosta · 2019-10-30T06:34:44Z

I have the same issue! I own a Behringer u-phoria umc202hd, and if I'm watching a person talking in a youtube video and open telegram, I get a pop, a pause, and the sound resumes but the person inhaled some helium until I pulseaudio -k

Aryojaam · 2019-11-17T09:29:42Z

I can always reproduce the bug when I do the following:
Menu -> Calls -> Settings -> Test microphone

I am using Ubuntu 19.04. I have a Behringer UMC204Hd

AridaneAM · 2019-12-09T23:34:11Z

I can always reproduce the bug when I do the following:
Menu -> Calls -> Settings -> Test microphone

I am using Ubuntu 19.04. I have a Behringer UMC204Hd

I have the same problem with Behringer UMC202HD and Kubuntu 19.10.

ajaydee · 2020-04-11T22:59:43Z

This bug is absolutely infuriating. I've stopped using telegram on desktop because of it. I've ran so many OpenAL based applications that it's obvious it's been used incorrectly here.

Please fix this bug, I'm using the desktop app to contact friend & family during isolation. My mobile internet signal is so bad, I'm having to put my phone upstairs.

I'm going to take a peek at the code. Any info on what file the openal starting code is?

Edit: Ok, I see someone posted a link above to something that might be the problem. I can't deal with that. Blender can switch sample rates without messing up other software. Take a look at what it does to VLC, it turns it into a stuttering mess. Shame, I really like Telegram.

ilya-fedin · 2020-04-11T23:30:13Z

Ok, I see someone posted a link above to something that might be the problem.

i think he is wrong. That code converts the stream with ffmpeg, which doesn't communicate with sound system at all

More likely that the bug is caused by the direct channels flag or by microphone testing which is called at start

I've ran so many OpenAL based applications that it's obvious it's been used incorrectly here.

Would be more helpful if you provide full list of them

ajaydee · 2020-04-11T23:51:05Z

Blender, Dolphin, mumble, virtually every game.

Gish, Doom3, Colin McRae DiRT, ioquake3, Jedi Knight: Jedi Academy, Prey, Psychonauts, Quake 4, X3: Reunion, Alien Isolation, Minecraft.

Why am I listing software? Virtually everything uses OpenAL on Linux because it's awesome. It's quite clearly Telegram that's having the issue.

Edit: Thanks for the links. I'll take a look. :)

Edit2: Hmm. I've been using Blender all day, my brain is pooped.

ilya-fedin · 2020-04-11T23:53:02Z

Dolphin

Doesn't uses OpenAL if you're about KDE's Dolphin

ilya-fedin · 2020-04-11T23:54:18Z

Minecraft

they're too AFAIK

Pixelnarium · 2020-10-22T05:46:52Z

I know it would not be a fix at all, but maybe an option to disable recording would help people like me. I do not use Telegram for calls or voice mails.

Pixelnarium · 2020-10-22T06:12:41Z

One thing I saw after a quick look is that OpenAL asks for a specific sample rate from pulseaudio https://github.com/kcat/openal-soft/blob/master/alc/backends/pulseaudio.cpp#L662

Maybe this confuses ALSA or the hardware in this case. But I don't know pulseaudio that much.

vimpostor · 2020-10-22T14:58:23Z

Good find. I looked into it but unfortunately it was a dead end again. I tried changing the hardcoded frequency and sample format to my native audio interface format, but the distorted audio still occurs. The problem appears as soon as OpenAL calls into pa_stream_new. I also tried using pa_stream_new_extended instead (see https://freedesktop.org/software/pulseaudio/doxygen/stream_8h.html#acf41f201c5e6ac94b7fcbc8626b6c933), where instead of hardcoding a sample rate and format, you can give a list of acceptable formats and Pulseaudio will figure out what is the most suitable format. Sadly this was a dead end too. I think at the end of the day this is still an Alsa problem, openal-soft is not really doing anything wrong even when that hardcoded probe frequency seems a little suspicious. Edit: In case anyone wants to try this out again, attached is a patch on top of openal-soft that uses another hardcoded frequency but still reproduces the distorted audio. Build openal-soft as usual and start the new distorted_audio program in the build/examples folder. [0001-Reproducable-distorted-audio.patch.txt](https://github.com/telegramdesktop/tdesktop/files/5423680/0001-Reproducable-distorted-audio.patch.txt)

…

On Wed, Oct 21, 2020 at 11:12:56PM -0700, Pixelnarium wrote: One thing I saw after a quick look is that OpenAL asks for a specific sample rate from pulseaudio https://github.com/kcat/openal-soft/blob/master/alc/backends/pulseaudio.cpp#L620 Maybe this confuses ALSA or the hardware in this case. But I don't know pulseaudio that much. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1548 (comment)

ilya-fedin · 2020-10-22T17:59:26Z

I also tried using pa_stream_new_extended instead

Why not just to remove PA_STREAM_FIX_FORMAT | PA_STREAM_FIX_RATE | PA_STREAM_FIX_CHANNEL flags?

vimpostor · 2020-10-22T19:22:14Z

You are right that would have the same effect. I just tested it though and it does not work either.

…

On Thu, Oct 22, 2020 at 10:59:42AM -0700, ilya-fedin wrote: > I also tried using pa_stream_new_extended instead Why not just to remove `PA_STREAM_FIX_FORMAT | PA_STREAM_FIX_RATE | PA_STREAM_FIX_CHANNEL` flags? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #1548 (comment)

flamingspaz · 2020-10-27T18:41:47Z

Same issue with a Focusrite Scarlett Solo gen1, setting pulseaudio to 96khz doesn't fix the issue. fwiw the Zoom linux client does the same thing.

ilya-fedin · 2020-10-27T18:43:46Z

Wow, it is good to know that not only tdesktop is affected

Aokromes · 2020-10-27T18:59:44Z

sooo, 3rd party?

ilya-fedin · 2020-10-27T19:01:27Z

sooo, 3rd party?

We still don't know why exactly this happens :(

Pixelnarium · 2020-10-27T19:17:56Z

Some observations on my (!) system (sorry if this was already known, this issue is kinda long). The interface is a Steinberg UR22 MK2.

in my case the sound gets slower
this seems to happen only when the default input source is set to the interface. Using the build-in microphone port on the mainboard as default does not trigger the issue. Changing it to the interface after starting Telegram seems to work just fine. Verified with multiple tries and reboots.
the sampling rates Pulseaudio reports via pacmd list-sinks or pacmd list-sources do not change while triggering the issue
just changing the different device profiles in pavucontrol (analog input + digital input, digital input + analog output, ...) can trigger is issue
having different sampling rates set may or may not trigger the issue, depending on the current sampling rate. i.e. for me it does not trigger when everything is set to 44.1khz but does trigger when the output is set to 48khz and the input is set to 44.1khz.
at least my interface was pretty troublesome (stuttering, audio dropouts, ...) on Windows 10 after the 1803 update, I think a later Yamaha driver update fixed some (?) issues
you can trigger the issue with multiple applications (i.e. pavucontrol, OBS studio, pure OpenAL, ALSA helper tools)
you can also trigger the issue by just opening the GNOME audio settings while the "wrong sample combination" and the interface input source is currently active
it does not trigger when just opening and using the GNOME Sound Recorder
GNOME and all its daemons have nothing to do with it, it also happens on i3wm

What I did not test:

setting up a pure ALSA system. When I bought the interface a couple of years ago I had some troubles using it on a pure ALSA system. The ALSA subsystem crashed when I started Audacity.
setting up a pure JACK system (I never got JACK running nicely on any system)
setting up a PipeWire system (too new as an audio server, barely works)

Personally I think all this hardware needs some kind of quirks settings at the kernel level if it is not a kernel bug for USB Audio in general. Since nothing reports any issues or changes while playing I think the hardware gets confused when the output sampling rate is not in a good combination with the input sampling rate when the specific hardware call happens.

Since I could not find the Kernel Bugzilla entry in here, here is the link from the OpenAL issue above:

https://bugzilla.kernel.org/show_bug.cgi?id=207617

Pixelnarium · 2020-10-27T20:55:22Z

Okay, since this issue is interesting I tried something more. I set up a pure ALSA system and tried some things:

at least for me this issue does not happen on a pure ALSA system (i.e. Archlinux base install)
- aplay and arecord are working nicely in parallel no matter what sample rate is used
- the OpenAL sample code also does not trigger the issue when aplay plays the music
the issue seems to be triggered or caused by Pulseaudio
- installing & starting pulseaudio and playing a 48khz music file via mpv and running the OpenAL sample code does trigger the issue
- installing pulseaudio-alsa sets up the alsa wrapper so that ALSA calls get redirected to Pulseaudio
  - running aplay and arecord after installing said package the issue also happens

I found a similar issue on the Pulseaudio Bug Tracker: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/issues/944

Maybe we should ask there.

vimpostor · 2020-10-27T22:23:14Z

Yup I have the same pulseaudio-alsa package installed. I did not know that it redirects Alsa sound to pulseaudio, but if it does like you said it does, then this is indeed a pulseaudio problem, which is good news because that would be way easier to debug than a bug deep inside the kernel audio system.

ilya-fedin · 2020-11-07T18:00:47Z

Today I noticed that pipewire finally got sound support and could be enabled on arch by installing pipewire-alsa, pipewire-pulse, pipewire-pulse-dropin and lib32-pipewire-pulse-dropin package (the last one is needed if 32-bit applications like wine are used, two last ones are from AUR) and editing the last line of /etc/pipewire/pipewire.conf to exec /usr/bin/pipewire-media-session -e bluez5,pulse-bridge

In case if anyone want to test if this bug is present with pipewire and report it to them, since pulseaudio development seems to be very slow

ghost · 2021-01-21T16:54:05Z

I also have audio speed up on 2.5.5 beta, but only when I'm calling or receiving a call. Just launching telegram and receiving sound notifications is fine. before I accept a call I physically turn on +48V mic on usb sound card. the fix after the call is to kill pulseaudio to make it restart.

ilya-fedin · 2021-01-21T16:57:44Z

There's probably nothing we can do about that since there's a bug with handling different sample rates on pulseaudio side

OlliC · 2021-01-23T10:28:33Z

I am also using a Steinberg UR22 MK2 interface and had the same issue. I reinstalled my PC and forgot that i had set a fixed sample rate of 48kHz in my /etc/pulse/daemon.conf before, so the issue popped up again. With a fixed sample rate the issue does not happen. This is a general issue with external USB audio interfaces and pulseaudio.

These are the settings i use:

resample-method = speex-float-10
default-sample-rate = 48000
alternate-sample-rate = 48000

ghost · 2021-01-31T09:44:32Z

This is not the case for me -- people I talk to still sound like they are on helium baloons. With the following config

❯ grep -ve '^;' /etc/pulse/daemon.conf | grep -ve '^#' | grep '\S'
resample-method = speex-float-10
flat-volumes = no
default-sample-rate = 48000
alternate-sample-rate = 48000

and Audient iD4 as sound card, in pulseeffects I see:

Does this mean PA ignores my settings? Weird.

ilya-fedin · 2021-01-31T09:47:44Z

Does this mean PA ignores my settings? Weird.

Maybe some another application is forcing PA to 44100? I've seen that PA switches to another sample rate when some application requests it and there are no other application playing at the same time and it doesn't reset to default sample rate when the playback is finished

vimpostor · 2021-02-05T16:44:50Z

I just set up Pipewire to replace Pulseaudio on my system. I can report that the problem does no longer appear when using Pipewire on my system (Version 1:0.3.21 on Arch Linux)

ghost · 2021-02-06T13:33:20Z

Same. I have installed pipewire 0.3.19 and the problem is gone.

stale · 2021-08-05T13:35:03Z

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

github-actions · 2021-10-20T00:06:58Z

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

auchri added the linux label Jan 25, 2016

ghost closed this as completed Feb 8, 2017

ghost added the auto closed label Feb 8, 2017

stek29 mentioned this issue Nov 15, 2018

starting telegram speeds up music (spotify) #5349

Closed

stek29 removed the auto closed label Nov 15, 2018

stek29 reopened this Nov 15, 2018

Aokromes mentioned this issue Dec 10, 2019

Other programs start to play music/sounds faster, when TelegramDesktop is started #4492

Closed

Aokromes added the bug label Jan 27, 2020

ilya-fedin mentioned this issue Apr 11, 2020

Telegram makes audio raise in pitch on Linux. #7616

Closed

ilya-fedin mentioned this issue Nov 20, 2020

Capture regression on macOS (1.19 fine, 1.20.1 and after bad). kcat/openal-soft#495

Closed

ilya-fedin mentioned this issue Jan 22, 2021

Telegram reduces tone pitch of other playing music sources upon start #10196

Closed

ilya-fedin mentioned this issue Jan 23, 2021

Degraded audio quality systemwide if-and-only-if Telegram has an active call #9954

Closed

ilya-fedin mentioned this issue Mar 23, 2021

Crackling notifications sound #10591

Closed

ilya-fedin mentioned this issue Jun 28, 2021

Sound lowers Sample Rate in Linux #16515

Closed

stale bot added the stale label Aug 5, 2021

stale bot closed this as completed Sep 4, 2021

github-actions bot locked as resolved and limited conversation to collaborators Oct 20, 2021

Telegram causes music in rhythmbox (gstreamer applications) to play faster!? #1548

Telegram causes music in rhythmbox (gstreamer applications) to play faster!? #1548

Comments

cookiengineer commented Jan 23, 2016 • edited by ghost Loading

cookiengineer commented Feb 2, 2016

ghost commented Feb 8, 2017

cookiengineer commented Feb 9, 2017

stek29 commented Apr 3, 2017

cookiengineer commented Apr 3, 2017 • edited Loading

gaelanlloyd commented Aug 7, 2017

mtaalas commented Jul 21, 2018

john-preston commented Jul 21, 2018

zerodayyy commented Jul 23, 2019 • edited Loading

Lerke commented Aug 18, 2019

Aryojaam commented Oct 5, 2019

zerodayyy commented Oct 5, 2019 via email

tnagler commented Oct 23, 2019

majcosta commented Oct 30, 2019

Aryojaam commented Nov 17, 2019

AridaneAM commented Dec 9, 2019

ajaydee commented Apr 11, 2020 • edited Loading

ilya-fedin commented Apr 11, 2020

ajaydee commented Apr 11, 2020 • edited Loading

ilya-fedin commented Apr 11, 2020

ilya-fedin commented Apr 11, 2020

Pixelnarium commented Oct 22, 2020 • edited Loading

Pixelnarium commented Oct 22, 2020 • edited Loading

vimpostor commented Oct 22, 2020 via email • edited Loading

ilya-fedin commented Oct 22, 2020 • edited Loading

vimpostor commented Oct 22, 2020 via email

flamingspaz commented Oct 27, 2020

ilya-fedin commented Oct 27, 2020

Aokromes commented Oct 27, 2020

ilya-fedin commented Oct 27, 2020

Pixelnarium commented Oct 27, 2020 • edited Loading

Pixelnarium commented Oct 27, 2020

vimpostor commented Oct 27, 2020

ilya-fedin commented Nov 7, 2020

ghost commented Jan 21, 2021

ilya-fedin commented Jan 21, 2021

OlliC commented Jan 23, 2021

ghost commented Jan 31, 2021

ilya-fedin commented Jan 31, 2021

vimpostor commented Feb 5, 2021 • edited Loading

ghost commented Feb 6, 2021

stale bot commented Aug 5, 2021

github-actions bot commented Oct 20, 2021

cookiengineer commented Jan 23, 2016 •

edited by ghost

Loading

cookiengineer commented Apr 3, 2017 •

edited

Loading

zerodayyy commented Jul 23, 2019 •

edited

Loading

ajaydee commented Apr 11, 2020 •

edited

Loading

ajaydee commented Apr 11, 2020 •

edited

Loading

Pixelnarium commented Oct 22, 2020 •

edited

Loading

Pixelnarium commented Oct 22, 2020 •

edited

Loading

vimpostor commented Oct 22, 2020 via email •

edited

Loading

ilya-fedin commented Oct 22, 2020 •

edited

Loading

Pixelnarium commented Oct 27, 2020 •

edited

Loading

vimpostor commented Feb 5, 2021 •

edited

Loading