Qtox: Voice becomes antsy and ragged when making a group voice call

Created on 6 Jun 2016  路  11Comments  路  Source: qTox/qTox

Brief Description

When creating group and only two people talks, voices sounds pretty good. But when in voice call talks more than two people (in my case - three humans), voice becomes antsy and ragged.

OS: Windows 10 (my friends have Linux installed and they have this issue too)
qTox version: v1.4.0-117-g792103f
Commit hash: 792103f
Qt: 5.5.1
Hardware: ASUS T200TA

Reproducible: Always

Steps to reproduce
  1. Create group.
  2. Invite three humans.
  3. Accept talk for all people in group.
    Observed Behavior

Crappy voices.

Expected Behavior

Pretty good voices.

Additional Info

I attached a pretty clean qtox.log in ZIP.

C-bug M-audio

Most helpful comment

Sorry for the late answer. I hope getting some time this evening and will setup a proper PR. @tux3 FYI: I plan to leave OpenAL and current Audio API untouched for the moment and implement RtAudio / Opus based stuff completely independent and in parallel. If everything works at least "as good as now", we can talk about merge.

All 11 comments

@antis81 #3309 would help with this, right?

@zetok Not really. #3309 only removes some dead code, plus cleaning up related code. Though I did not measure any bandwidth or buffer usage, my guess is, that the "noise" is a result from 16-bit at 48kHz sampling rate. In short: A lot of bandwidth is used for streaming of raw audio data alone. Plus, every participant streams to a single buffer, which probably messes up the order and/or may drop frames, while the mutex is locked. This is a quite complex topic by it's nature. Question: How do you see chances, that we can soon switch to the RtAudio library (license similar to MIT) together with the Opus codec, which is linked in qTox for whatever reason already? Concerning this topic I'd like to join forces with @alexeysvrv and @initramfs and people interested in re-implementing the audio API - and setup a complete parallel branch for this purpose. The branch can surely be discussed in a "main" PR within qTox repo. Is it ok to "simply start this off"?

One moment - voices can be heared. I hear it, but sounds like the voice track is losing it parts with static period.

@antis81 I fully support you! You have to start implementation

Question: How do you see chances, that we can soon switch to the RtAudio library (license similar to MIT) together with the Opus codec, which is linked in qTox for whatever reason already?

Well, like with all the stuff, the better it works, the higher chances :)
Opus is linked since that's what toxcore uses for audio.

The branch can surely be discussed in a "main" PR within qTox repo. Is it ok to "simply start this off"?

Why not. I.e. there's no problem with starting something, but as usual for merge into master it would have to work + have docs about dependency change(s).

@antis81 I'm also in with this.

Sorry for the late answer. I hope getting some time this evening and will setup a proper PR. @tux3 FYI: I plan to leave OpenAL and current Audio API untouched for the moment and implement RtAudio / Opus based stuff completely independent and in parallel. If everything works at least "as good as now", we can talk about merge.

Pretty funny situation occurred recently. I tried to establish contact with one another at first, then at the same time with another friend. My friends began to talk among themselves. The resulting "group chat" was slightly better than the original - I could clearly hear one friend, another friend had a ragged voice. Another one could hear us both well.

I hope that this issue will be fixed soon. But It seems like there is a workaround. If invite one person to one group and another person to another group and start this two group calls, the problem is not occur and you can clearly hear this two people. I spoke two hours with two people using this workaround. So you can try.

@Kron4ek Thanks for reporting! This won't be available, until a real concept for group chats is implemented. I do not consider this as bug, but as a non-existing half-hearted implementation of an unfinished concept. Nice to know though it seems to work with the "two group workaround", making it usable anyway.

Someone should close this, it's fixed.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Tcll picture Tcll  路  3Comments

anthonybilinski picture anthonybilinski  路  6Comments

akhilman picture akhilman  路  7Comments

dcapeletti picture dcapeletti  路  4Comments

azymohliad picture azymohliad  路  5Comments