[jitsi-users] Stuttering audio calls on Windows 7 x64


#1

Hi.
I'm using the latest stable 2.2 x64 as of Aug 2013, on Windows 7 x64 Ent.
I have stuttering sound when on an audio call. This reproduces on different machines. The stuttering is so bad it is almost unusable. At the same time Skype calls (and other voip software) works like a charm everywhere.
I have disabled calls security through the Security tab on per account basis. Tried every possible option and combinations.
It is as if soundcard buffers are not big enough and I can explain it like there is kind of buffer underruns. How can we increase the buffer lengths to test?
Also I used the tiny tool TimerResolution which can be used to see the current system resolution (by default 15ms) and to set it to as low as 0.5ms. When I set it to 0.5, the stutter is substantially reduced but still there.
Can this give you some clues why this happens and how it can be cured?
I liked Jitsi very much and it is kind of desperate call because I really couldn't find better alternatives that support audio on the XMPP protocol. And I tested a LOT of them, if not all available.

Thanks.


#2

Please try the latest in Jitsi 2.3 nightly builds and make sure the
audio system in use is Windows Audio Session API (WASAPI) instead of
PortAudio.


#3

I'm sorry if I direct this message to a wrong address but this is the first
time I'm using a mailing list and don't know how to reply directly to the
topic in the list.

It appears that you're using Thunderbird so, as far as my experience
with Thunderbird goes, "Reply to all" should automatically add
users@jitsi.org to the list of recipients of your reply. Anyway,
manually setting users@jitsi.org in To: or CC: should do the trick.

I installed the latest nightly and it seems is better.
If I use WASAPI the audio call is not stuttering now (the latest stable
version is 5 months old and I suppose you did many improvements).

Indeed, we improved the audio quality and stability in major ways by
replacing PortAudio with WASAPI as the default audio system.

But the noise suppression function is doing poor job on noise reduction.

Well, Windows is doing the synchronization between the capture and the
playback for the purposes of the acoustic echo cancellation (AEC).
Anyway, (1) it's working perfectly for us and (2) it's unquestionably
far better than what we had with PortAudio and Speex.

Anyway, still more usable than before.
If I activate PortAudio the stuttering is here again. My experiments and
observations lead me to believe I was right - maybe the sound buffers are
too small, and Jitsi fails to set the system timer resolution. By default it
is 15.6ms in one of the systems in the conversation and it stutters bad.
However if I use TimerResolution.exe tool and set to 0.5ms then the call is
Ok with occasional stuttering but Much less frequent.

Still I think there is a problem with the audio buffers and/or failing to
work on the timer resolution on Windows - any music player lowers the
resolution from 15 to at least 1ms when playing sounds.

By the way, is there any side effects of using WASAPI rather than the
PortAudio choice? PortAudio was the default in the stable, now I see the
default is WASAPI after I installed the nightly.

We are moving away from PortAudio because it has multiple performance
and stability issues. Windows Audio Session API (WASAPI) is what we
expect our users on Windows Vista+ to use. So in the terms of your
question, the side effects should be that the audio should exhibit
better quality and stability.

···

2013/8/24 Teodor Hadjiev <teohad@gmail.com>:


#4

Microsoft have introduced Windows Audio Session API (WASAPI) in

> Windows Vista and have not backported it to Windows XP so,
> unfrotunately, Jitsi is stuck with PortAudio on Windows XP.

> Theoretically, we could use DirectSound to replace PortAudio on
> Windows XP. In practice, we are unlikely to invest into such an
> effort.

So I assume you semi-officially drop support in Jitsi for Windows XP, only Vista+.
Audio (and partly video) is the only reason I would use Jitsi (because of the jingle support) when I get sick of skype as there are many text-only clients with more options and hundreds of times lower memory requirements.
With my little audio knowledge I suppose this PortAudio is the same as the oldest WaveOutput found in some players and other programs. i guess this is the reason for the stuttering, because I guess only directsound works on the system resolution and other acceleration features (or at least all of them but wave_out).
It would be Ok but now we wait for the next stable where also the high memory usage issues/leaks get fixed :wink: .


#5

Microsoft have introduced Windows Audio Session API (WASAPI) in
Windows Vista and have not backported it to Windows XP so,
unfrotunately, Jitsi is stuck with PortAudio on Windows XP.

Theoretically, we could use DirectSound to replace PortAudio on
Windows XP. In practice, we are unlikely to invest into such an
effort.

So I assume you semi-officially drop support in Jitsi for Windows XP, only
Vista+.

I believe we have stated our position quite clearly on several
occasions already, so I am not sure why you need to go assuming things
that kind of sound but are not exactly what we said.

Audio (and partly video) is the only reason I would use Jitsi (because of
the jingle support) when I get sick of skype as there are many text-only
clients with more options and hundreds of times lower memory requirements.

It should probably be noted (and I am saying this as an individual)
that repeatedly stating how you are on the verge of disappointedly
abandoning the client is not the best way of motivating people to
voluntarily look into your issues. That might be just me though, so
feel free to ignore.

With my little audio knowledge I suppose this PortAudio is the same as the
oldest WaveOutput found in some players and other programs. i guess this is
the reason for the stuttering, because I guess only directsound works on the
system resolution and other acceleration features (or at least all of them
but wave_out).

Personally, I couldn't understand what you just said.

It would be Ok but now we wait for the next stable where also the high
memory usage issues/leaks get fixed :wink: .

This is not going to be looked at for the next stable. We acknowledge
the issue but it doesn't seem to appear consistently for everyone
while others do. It would therefore need to wait.

Emil

···

On Mon, Aug 26, 2013 at 2:32 PM, Teodor Hadjiev <teohad@gmail.com> wrote: