macOS Catalina: core-audio is killed

[JoPhiGURU]

Steps to reproduce

1. When I do a call, the app reloads core audio.
2. When I hang up a call, the app reloads core audio.
3. When I start the app, its reloading core audio.

Expected behaviour

It never should reload core audio.

Actual behaviour

It reloads core audio. This affects other audio devices and could lead to hardware damage, while these devices are in use for other tasks. At least it brings other devices to stop working for at least 3 seconds. Horrible, while streaming, when audio is gone and no one is able to hear anything.

Configuration

Operating system: MacOS: Catalina 10.15.5

Version of Telegram Desktop: 2.1.20 beta

Installation source (Linux Only) - the official website / GitHub releases / flatpak / snap / distribution package:

Used theme: dark

[john-preston]

@JoPhiGURU I don't know how to fix that (or even how to see what's that about), but nothing happens with any other apps playing music when I launch tdesktop.

[JoPhiGURU]

Well, I just can describe the behavior. My streaming software is telling me, that the inputs were changed. Also LogicX. Hmmm... Is tdesktop using an internal, virtual, temporary driver, which is hidden from the devices list?

[JoPhiGURU]

Please try it again, and please start a call. Are you using only internal devices, or also external equipment, like audo-interfaces. Maybe it has something to do with this... Hmmm...

[vimpostor]

Using tdesktop with external USB audio interfaces has problems on Linux and Windows too: https://github.com/telegramdesktop/tdesktop/issues/1548

Maybe this is related.

[JoPhiGURU]

Thank you very much for your input on this. All devices are affected. Even onboard devices, virtual devices. For any reason tdesktop is changing the core audio on Mac, who knows, maybe I'm able to sandbox it, to prevent it from doing this.

But yes, it seems to change the khz-settings for all devices, not just for the selected one, and this causes huge troubles! In worst case: Hardware damage.

[JoPhiGURU]

In the meanwhile I updated macOS to 10.15.6 and it is the same situation.

[JoPhiGURU]

More about the config: I use a Blackmagic Design Thunderbolt3-PCIe-capturing-device. Even this is affected. As said, tdesktop modifies all audio-devices, when it tries to pick up a call/hang up a call, or when the app is initializing itself.

[JoPhiGURU]

What I can test: I read all of the other BugReport. I can try to force all devices to use 48khz. So, maybe tdesktop does not try to change the rate. This may take some time. I'll post my results later.

[JoPhiGURU]

Seems to be perfect. As long as the input/output device(s) is/are on 48khz, tdesktop does not affect other devices.

[JoPhiGURU]

Suggestion: if you have to force a device to be 48000, please do not try to change all the other devices too!!! Please change only those, which are selected. This should solve all the issues in this case. ❤️❤️ (even for windows/linux)

[JoPhiGURU]

By the way, please add a scroll bar..❤️❤️

[JoPhiGURU]

Using tdesktop with external USB audio interfaces has problems on Linux and Windows too: #1548

Maybe this is related.

Thank you so much, you brought me to the clue! 🤗🤗❤️❤️

[JoPhiGURU]

Hold on: I did a call and it changed my internal device.

[JoPhiGURU]

![IMG_20200725_153008](https://user-images.githubusercontent.com/68697037/88458103-c048e480-ce8b-11ea-83e4-028caf29473c.jpg

The Built-In-Output is not used within tDesktop.

[JoPhiGURU]

So, it is changing devices, independently from what it has to. A pity, I cannot use the desktop app.

[JoPhiGURU]

Maybe tdesktop needs an internal converter to bring the signal to 48khz, if it is not out of the box 48khz. Some devices do just support 41.1khz, what then?

[JoPhiGURU]

I could use an Android device with analogue audio in/out to bring people from all over the world into my free German classes again. However, this was my former solution.

When the issue is solved, I'll use this app instead.

[JoPhiGURU]

Maybe it's because if the BITs? Some of my devices use 24bit, others 32. What do you suggest to use? Maybe then tDesktop stops to reconfiguring all other devices.

[ilya-fedin]

Maybe then tDesktop stops to reconfiguring all other devices.

tdesktop uses openal, if there are some reconfiguring, it is done by that library and tdesktop can't do anything to change that probably

https://github.com/kcat/openal-soft

[JoPhiGURU]

When forkes are based on forkes in forkes of forkes by forkes, maybe its getting crazy. I love the thought of open source and I also love the thought of sharing/combining code to build apps, especially to create multi plattform apps. I think that this breaks tDesktop on Mac, when it is related on this lib. What a pity, especially then when core audio is affected by anything else, which is not in control of the main app.

On the other hand, why shouldn't it be possible to just reconfigure the selected device(s)? If it's a missing feature in that lib, shouldn't it be requested by those who need it?

🤔🤔🤔

I would love to use tDesktop on Mac, but I'm afraid of hardware damage.

[ilya-fedin]

On the other hand, why shouldn't it be possible to just reconfigure the selected device(s)?

tdesktop doesn't ask the library to do any reconfiguring. tdesktop just opens the device and writes/reads to/from it.

btw, tdesktop uses different libraries for calls and for any other audio output. libtgvoip outputs and records sound for a call, openal for anything else. Please find which exactly library's the fault is at least.

[JoPhiGURU]

Because most of the (pro-) Apps - independently of open source or proprietary - are sensitive if the audio-conf is changed while a running production. I just use apps that keep a status quo. When they have to change settings, it's ok for me, when this is being done, while app start up. While runtime it's a no-go for me, because in my case, 10 other apps are placing a dialogue, that there is a new audio-device available/an input has been changed.... I don't want to pick up a call, and click all these boxes away, while waiting to the return of the main program audio. All other aspects are described before. I discuss these aspects as a user, not as a programmer.

I don't know how to find this. If I can help please describe where/how I can trigger this.

[ilya-fedin]

I don't know how to find this.

If you have the issue when you listening or recording a voice message, or listening audio file, or getting sound notification - then the issue is in openal (and it is impossible to fix it on tdesktop side, you should report to openal).

If you have the issue when you making a call - then the issue is in libtgvoip and further diagnostic is needed.

[ilya-fedin]

But I also have a feel that the issue is on your machine (maybe some specific audio software makes some global thing, installs some virtual driver, as you specified eralier, for example, and affects openal or libtgvoip, so that you're getting troubles on each usage of tdesktop) since noone else affected :man_shrugging:

[JoPhiGURU]

Yes, when I do a call, tdesktop (or a library of it) is affecting my internal sound card, which is not used together which tdesktop. No other software is changing the audio config. In tdesktop, two virtual audio devices are used, tdesktop has no access to real hardware, at least not through my settings. However, it is affecting the settings of my internal audio device.

By the way, Skype, Zoom and Discord are connected to own virtual devices, with no issues.

I cannot report a bug to others, because I'm not a programmer. I can just describe this phenomenon. And sorry, but this and similar bugs were described before.

[ilya-fedin]

And sorry, but this and similar bugs were described before.

There are only a link to linux issue that has its cause in buggy audio drivers

Yes, when I do a call

Are you 100% sure that listening and recording voices doesn't cause the issue?

[ilya-fedin]

By the way, Skype, Zoom and Discord are connected to own virtual devices, with no issues.

They all are using Electron and just instances of Chrome in the fact, i.e. they all have no issues since they have the same code.

[ilya-fedin]

I cannot report a bug to others, because I'm not a programmer.

Then we're stumped. No one else can report as well since no one else can reproduce your issue.

[JoPhiGURU]

Again, tdesktop (or the - by you told - components) is/are changing the settings for my internal sound output, while picking up a call. This device is not set within the settings of tdesktop. So why is it affecting it. It shouldn't. Isn't it?

What a pity.

[ilya-fedin]

So why is it affecting it

The question is why is it affects any outputs at all. But probably no one here knows answer if the problem is in an external library. I don't think there are any experts in macos audio stack, everything that tdesktop does is uses high-level api provided by the audio libraries.

Are you 100% sure that listening and recording voices doesn't cause the issue?

Btw, you've skipped that question. It is very important.

[JoPhiGURU]

I already told you that I can just describe what happens. When tdesktop is not running, none if those phenomenons is happening.

[JoPhiGURU]

By the way, I never tried to record a call until now, because as former explained, the audio is gone a while, while the change of the audio inputs. After about 3 seconds I can hear the person on the other side of the line, when I pass the virtual device to speakers.

To be compatible with major platforms is a great thought, but please not to the price of not knowing, what classes of others are doing/not doing. When these classes are listening on/changing other devices, isn't this a security issue too? I don't need an other Alexa nor "OK, Google".

When tdesktop needs to have a special audio format, why is it a problem to convert it - on the fly from it's source - to that what is needed?

[ilya-fedin]

I already told you that I can just describe what happens. When tdesktop is not running, none if those phenomenons is happening.

You told only what happens if you making a call. I can't understand why you can't test what happens if you try to record and listen a voice message.

When tdesktop needs to have a special audio format

tdesktop doesn't need any special audio format.

[JoPhiGURU]

Really, so why is it changing the devices input format to 48khz and a certain bitrate (and the internal output, which is not selected within the settings, to the same)?

I do not trust tdesktops behaviour, independently which components are causing this. Sorry, I'm not going to install it again. This is very strange.

[ilya-fedin]

Really, so why is it changing the devices input format to 48khz

tdesktop doesn't change and openal doesn't change according to this, i.e. systems just doesn't provide any API to do that. Sound streams should be resampled to the device sample rate by the library or by the system. Maybe your virtual drivers broke this mechanism thought and here you are. But it is a problem with these virtual drivers then.

Sorry, I'm not going to install it again.

What's the point of this issue if you don't want to give the needed information to solve the problem then? :thinking:

[JoPhiGURU]

Hmmm... I use blackhole (open source, mac native) with two channels, for input and for output (separately for each app), you can see it at the picture above. Only tDesktop is leading to reconfiguring. The reconfiguring process affects my internal sound output... So, when tDesktop (or it's components) isn't responsible, and no reconfiguring is happening, (when it's not in use, then nothing happens), then maybe I dreamed about warm but solid ice cream...

Maybe I just do not unterstand what I should exactly test, or provide. I teach thousands of people on the internet in German, but maybe I'm not able to express myself in English.

What about a step by step guide, what you exactly need? On Thursday I could do some screen-recordings and some tests/verifyings.

[ilya-fedin]

What about a step by step guide, what you exactly need?

Do you know what voice messages is? You need to test if issue happens when you recording it (you can record it by a mic icon in the right side of the chat input field) or listening it. A tip: sound device settings are only for calls, voice messages are always using only the default device, just like anything other in tdesktop.

[JoPhiGURU]

Yes, i know the difference, thx for clarifying. When this settings are always on default, it seems to be logic, why tDesktop affects my internal settings. So, it's not a bug, it's a missing feature.

The solution for this seems to be easy: #featureREQUEST: please make this "default-settings" selectable/defineable/changeable. It seems to be that the settings would be a great place for it.

It does not give any sense to have default settings, when users have a diversity of input devices. Then, in.my opinion, tDesktop should not force users to use a special device, which might be in use for other purposes (the same time).

I think that the issue is now clear: it's not a bug, it is simply a missing feature. Especially when tDesktop is defining/initializing the usage of the default device while startup.

[JoPhiGURU]

With your messages, I was able to see, that different functions are using different devices. And the voice-message-settings are currently always on the OS's default device. Now all is clear for me, why this device is affected. The internal device is used for all the monitoring, so this also explains, why I can't hear anything for about 3 seconds, while the reconfiguring procedure.

[JoPhiGURU]

As soon as this feature is available, I promise to use tDesktop! It's amazing!

[ilya-fedin]

The solution for this seems to be easy: #featureREQUEST: please make this "default-settings" selectable/defineable/changeable. It seems to be that the settings would be a great place for it.

It is already there: #7725

[ilya-fedin]

Especially when tDesktop is defining/initializing the usage of the default device while startup.

There are only getting a list of devices on startup. There was an opening of default recording device on startup, but it was removed in 2.1.3

[github-actions[bot]]

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.