Qtox: Partner don't hear me while I'm not in Audio/Video tab

[gsv91]

Brief Description

OS: Windows 10
qTox version: v1.4.1-1-g06d78dc
Commit hash: 06d78dcdee7bfe9a320fe91662f34227d74c3916
toxcore: 0.0.0
Qt: 5.5.1
Hardware: Realtek High Definition Audio

Reproducible: Almost Always

Steps to reproduce

1. Log in
2. Audio call
3. Go to Audio/Video tab
4. Capture Device is always None(This is issue also) so I need to choose my microphone
5. When microphone is chosen and i go to other tab my partner don't hear me anymore. So i need to stay at audio/video tab.

Sorry but i didn't find log files, i will be grateful if you'll help me.

[antis81]

1. Capture Device is always None(This is issue also) so I need to choose my microphone

This should be fixed by now -> upgrade helps. "None" now correctly states "Disabled" and is just a string notifier. By upgrading

1. When microphone is chosen and i go to other tab my partner don't hear me anymore. So i need to stay at audio/video tab.

Yeah I had that exact same situation in a ~30 minutes call with a friend. Another time it worked without problem. I'm currently in the process of converting to another audio api, that better fits our needs. This in turn solves such situation. In the meantime, there's only one way to get this right.

@Diadlo @sudden6 (@zetok)
The qTox settings GUI (each and every tab and resource) is created right at program start and kept in memory throughout the program's lifetime. Instead of creating the widgets when needed, they are hidden and shown - and this causes the trouble (also valid for video subscription). Instead of this, the SettingsWidget should actually be created when clicking on the gear wheel and actually destroy itself on close. @Diadlo Mind to take that PR?

[Diadlo]

@antis81 What the problem with show/hide instead of create/destroy?

[dolohow]

I am having the same problem. I need to stay in audio/video tab in order to send voice.

[antis81]

@Diadlo First, whenever the program calls hide, devices are "unsubscribed". That means, a dumb counter runs down to 0. If that happens (which is obvious here), the audio (and video) device is closed. Second, create/destroy allows for much better resource management. To show/hide a widget, it is required to be in memory (this is valid during whole runtime!). All it's resources are being occupied as well, which is the actual reason behind this shitty "subscribe" mechanism. Last not least, create/destroy eases code flow for coders, needing to focus only on the resources in use. WIP 3584 #3564 will fix this.

[Diadlo]

For me this issue reprodused only after 81df534c9a1b392cab136c6b84a58d2e5028a425

[antis81]

@Diadlo Thanks! This even proves more for that I'm on the right track!

If you search for Audio::unsubscribe usage, you'll see, that there are exactly 2 places:

1. ToxCall destructor
2. AVForm::hide

And there's no other place! The input device cannot be closed from outside the audio class, but it can be reopened. That's when changing the input device during a call. There's even a "boolean guard", that prevents a double unsubscribe by calling AVForm::hide() accidentally twice, etc. etc. And yet it keeps failing in certain situations!

With creation/destruction, this bullshit vanishes! Usually, you would want to do something like this:

AVForm()
{
…
  audio.subscribeInput();
…
}

~AVForm()
{
…
  audio.unsubscribeInput();
…
}

That's exactly what happens in ToxCall constructor/destructor! And that's it!

With current solution, this would keep the resources (audio & video) open during qTox's whole run-time wether used or not and the reason, why we put a heck of an effort in it to make it somehow usable at all.

Btw. #3564 also introduces a RecursiveSignalBlocker and removes redundant events, which allows for blocking any changes during initialization.

[Diadlo]

@antis81 Maybe it will be intresting for you (maybe not):
Audio::subscribeOutput called from CoreAV::groupCallCallback, CoreAV::audioFrameCallback and ToxCall::ToxCall.
But Audio::unsubscribeOutput called only from ToxCall::~ToxCall

[antis81]

It doesn't matter. The first call to subscribe opens the input device and any further subscription just counts up. So in worst case, the device is kept open until qTox quits.

[yatsenkoanton]

I have exactly the same issue on Ubuntu 16.04 (qTox version v1.5.1-obs, commit hash f05b7e040a073c7afadaf763dda5beaf130c6dbd)

Even though I have this issue on two ubuntu systems, I don't have it on the Windows version.

[nazar-pc]

Good news, I've just updated to v1.5.2-191-g0669bce-obs (0669bce820f39f7bc5c51bb75cc4b60c016aafd6) and it seems to work outside of Audio/Video tab.
Can anyone double check?

[yatsenkoanton]

Yeah, I don't have this problem anymore, thanks guys!

[dolohow]

Will you guys release 1.5.3 with this fix?

[zetok]

Will you guys release 1.5.3 with this fix?

Nope. Patch releases are only for fixes that are needed ASAP, which constitutes things that would leave qTox ~broken if not patched.

Doing them for something more would require a lot of maintenance effort, and qTox doesn't have enough of people to go with that kind of thing.

Fix will be included in v1.6.0 release.

[dolohow]

Nope. Patch releases are only for fixes that are needed ASAP, which constitutes things that would leave qTox ~broken if not patched.

For me qTox is almost broken, I stopped using it because of that bug.

Doing them for something more would require a lot of maintenance effort, and qTox doesn't have enough of people to go with that kind of thing.

I understand. Thank you for doing qTox, will wait for 1.6 then.

[zetok]

For me qTox is almost broken, I stopped using it because of that bug.

Using qtox-alpha package is not an option?

[dolohow]

I did not know about it existence, will try that then. Thanks.

[zetok]

@dolohow since I wasn't 100% sure whether there's no one interested in maintaining patch releases, I did ask: https://github.com/qTox/qtox-irc-logs/blob/91032b48147449b1de1ff57c48ff6ef384f4ac20/2016/10/%23qtox_20161020.log.txt#L110

So, yeah.

[dolohow]

qtox-alpha fixes this issue.