[jitsi-dev] Audio/video options leaking resources


#1

Hey

When I open the audio or video options and close them afterwards, there are
one or more threads capturing audio staying alive. This causes a constant
CPU load of about 7-8%, equally divided by Jitsi and the Windows Audio
Device Graph (audiodg.exe). In the attached thread dump, two threads peaks
out:
Thread-107: created when the webcam was activated
Thread-126: created when the audio options were first shown (running in
Pa.ReadStream)

Threads are created every time the audio options tab is shown (switching to
codecs and back is enough) and staying alive until the audio tab is shown
again.

Btw, I noticed this because the fan or my laptop gets faster every few
minutes despite the system being idle otherwise...

Regards,
Ingo

threads.txt (56.6 KB)


#2

Thank you very much, Ingo! Will you fix these or should we rather
schedule them to fix them ourselves?

By the way, I discovered a memory leak upon closing a the video
capture devices on OS X and Linux. Anyway, I'll take care of that one.

···

2013/1/23 Ingo Bauersachs <ingo@jitsi.org>:

When I open the audio or video options and close them afterwards, there are
one or more threads capturing audio staying alive. This causes a constant
CPU load of about 7-8%, equally divided by Jitsi and the Windows Audio
Device Graph (audiodg.exe). In the attached thread dump, two threads peaks
out:
Thread-107: created when the webcam was activated
Thread-126: created when the audio options were first shown (running in
Pa.ReadStream)

Threads are created every time the audio options tab is shown (switching to
codecs and back is enough) and staying alive until the audio tab is shown
again.


#3

Hi, Ingo!

SVN r10452 should improve the behavior with respect to audio i.e.
closing/switching away from the Audio configuration form should very
soon terminate the thread executing Pa.ReadStream). If you get a
chance to check it out and it does not solve the issue you described,
please do let us know.

Best regards,
Lyubomir

···

2013/1/23 Ingo Bauersachs <ingo@jitsi.org>:

When I open the audio or video options and close them afterwards, there are
one or more threads capturing audio staying alive. This causes a constant
CPU load of about 7-8%, equally divided by Jitsi and the Windows Audio
Device Graph (audiodg.exe). In the attached thread dump, two threads peaks
out:
Thread-107: created when the webcam was activated
Thread-126: created when the audio options were first shown (running in
Pa.ReadStream)

Threads are created every time the audio options tab is shown (switching to
codecs and back is enough) and staying alive until the audio tab is shown
again.


#4

When I open the audio or video options and close them afterwards, there

are

one or more threads capturing audio staying alive. This causes a constant
CPU load of about 7-8%, equally divided by Jitsi and the Windows Audio
Device Graph (audiodg.exe). In the attached thread dump, two threads

peaks

out:
Thread-107: created when the webcam was activated
Thread-126: created when the audio options were first shown (running in
Pa.ReadStream)

Threads are created every time the audio options tab is shown (switching

to

codecs and back is enough) and staying alive until the audio tab is shown
again.

Thank you very much, Ingo! Will you fix these or should we rather
schedule them to fix them ourselves?

I have no clue about the rendering system and where to start searching. I
guess my (non-existing) time is currently better spent with the various
smaller annoyances to keep you guys busy with the real stuff :wink:

By the way, I discovered a memory leak upon closing a the video
capture devices on OS X and Linux. Anyway, I'll take care of that one.

Thanks!

Ingo


#5

When I open the audio or video options and close them afterwards, there

are

one or more threads capturing audio staying alive. This causes a constant
CPU load of about 7-8%, equally divided by Jitsi and the Windows Audio
Device Graph (audiodg.exe). In the attached thread dump, two threads peak
out:
Thread-107: created when the webcam was activated
Thread-126: created when the audio options were first shown (running in
Pa.ReadStream)

Threads are created every time the audio options tab is shown (switching

to

codecs and back is enough) and staying alive until the audio tab is shown
again.

Hi, Ingo!

SVN r10452 should improve the behavior with respect to audio i.e.
closing/switching away from the Audio configuration form should very
soon terminate the thread executing Pa.ReadStream). If you get a
chance to check it out and it does not solve the issue you described,
please do let us know.

Thanks Lyubo! Audio is good now.

I'm not sure about the video-preview though:
- Memory usages increases about 2 to 3 MB each time I open the preview
- Switching /away from/ the video preview /during/ the Webcam initializing
phase causes that I cannot further use the webcam in Jitsi. Even a restart
of it doesn't help. Re-initializing the cam through another application
works, and the cam also starts working again in Jitsi (even without a
restart) after that.

Best regards,
Lyubomir

Best regards,
Ingo

···

2013/1/23 Ingo Bauersachs <ingo@jitsi.org>: