Since the latest update, I'm having trouble with Audio on Vidyo. When I join a meeting, after a certain amount of time (this time, 25 minutes), audio just entirely cuts off. You have to stop Vidyo and restart it to get it working again. This is on Ubuntu 12.04 LTS.
I'm experiencing the same problem. I've been using Linux Mint 13 (which is mostly ubuntu 12.04). It's worked perfectly for the past year, and I started getting this exact problem on every vidyo call since the update. I also run into the situation where VidyoDesktop won't restart unless I reboot the computer. I've uninstalled and reinstalled vidyo desktop and that made no difference. Skype seems to work fine. I also have a 12.04 running on a laptop I was going to try, but it's in being serviced right now.
After the problem, I tried to restart Vidyo from the console and see the following: 580 >VidyoDesktop main(): called getrlimit(RLIMIT_CORE, ...), return value 0, rlim_cur = 0 rlim_max = 18446744073709551615 main(): will call setrlimit(RLIMIT_CORE, ...), rlim_cur = 18446744073709551615 rlim_max = 18446744073709551615 main(): called setrlimit(RLIMIT_CORE, ...), return value 0, rlim_cur = 18446744073709551615 rlim_max = 18446744073709551615 main(): called getrlimit(RLIMIT_CORE, ...), return value 0, rlim_cur = 18446744073709551615 rlim_max = 18446744073709551615 main(): getenv( HOME ) returned /home/dhylands main(): PATH_MAX = 4096 main(): pathToLogDir = /home/dhylands/.vidyo/VidyoDesktop/ main(): VidyoRect has: 0 0 0 0 got fs = ext 4 supports ext4 get_tag_value-101-56-49-49-49-98 OnOutEvent: User message for conference: Dummy data messageType: 86 messageString: p* messageCodes: 32749 9115076 0 main(): could not start VidyoClient!
Rebooting wasn't enough. If I uninstalled and reinstalled Vidyo, then the VidyoDesktop would start and I got my audio back.
Fwiw, this is still happening. Killing VidyoDesktop and restarting it fixes the problem for me. It happened at least four times yesterday in a 20 minute meeting. After the fourth time, I rejoined and my voice was apparently high pitched. Even a restart of Vidyo didn't fix that, and we switched to Skype.
Just got it again. This is very inconvenient.
Got this from Desktop/Vidyo, maybe it can help: # Try to set the pulse audio latency as described in - http://arunraghavan.net/2013/08/pulseaudio-4-0-and-skype/ For system wide change: 1. Open terminal and type: nano /etc/xdg/autostart/vidyo-vidyodesktop.desktop 2. Change, Exec=VidyoDesktop -AutoStart to Exec=env PULSE_LATENCY_MSEC=60 VidyoDesktop -AutoStart To change only for that session: Type below command and launch VD from terminal: PULSE_LATENCY_MSEC=60 VidyoDesktop
The solution in comment 7 fixed this for me but I had to apply the fix in: /usr/share/applications/vidyo-vidyodesktop.desktop as I do not have Vidyo autostart on login. This will address launching from the application menu.
We picked this fix for Skype after some investigation. It would be better to actually understand why Vidyo is behaving this way rather than blindly changing their latency parameters.
I'm sure if they'd open source their stuff people would happily dig in and figure out why... Until then, it's likely hard to do for anyone other than people with access to the source.
Confirming that setting PULSE_LATENCY_MSEC=60 prior to starting Vidyo re-enabled audio output for me, which had broken upon upgrading from Ubuntu 13.04 to 13.10 (and thus Pulseaudio from 3 to 4).
After upgrading Debian to the current testing, I don't get any sound from Vydio unless I set it to output to "simultaneaous output". I didn't try the env variable yet.
Another update: I updated my Debian again (still to testing) and Vidyo seems to work well now. I haven't changed anything else (esp not Vidyo).
(In reply to Julien Wajsberg [:julienw] (away until March 24) from comment #13) > Another update: I updated my Debian again (still to testing) and Vidyo seems > to work well now. I haven't changed anything else (esp not Vidyo). It worked like this only once and then back to comment 12. The env variable didn't help at all. Setting Vidyo output to "simultaneous output" yields very low volume even with a 150% gain on all output sliders in pavucontrol. Setting to "internal audio" yields no sound (probably too low). Does anybody have any solution for this?
(In reply to Julien Wajsberg [:julienw] (away until March 24) from comment #14) > It worked like this only once and then back to comment 12. Is that with Vidyo 2.x or 3.0? I found that the latter seems to do better.
The Debian package's version is 2.2.1-00417.
It might be worth pointing out that the audio problem (at least the one I experience) is one way: other people can hear me but I can't hear them.
I got this issue with the recent packages as well.
The problem has become much worse since the latest update to Vidyo. I am on Fedora 20 FWIW.
Could someone give me instructions to reproduce the problem? I'm on Fedora 20 too.
For me it's been "be on a call more than 10 or 15 minutes, notice you can't hear the other person/people, see CPU usage go very high (just looking at top or whatever), |pkill VidyoDesktop; VidyoDesktop&|". Sorry I don't have a clear STR.
I'm encountering this problem after updating to Vidyo 3.3.0-027. It was not an issue with Vidyo 3.0.4. I'm on Ubuntu 14.04. The env var workaround in comment 7 did not work for me. Trying different combinations of audio device settings from within Vidyo did not stop the problem from happening, either.
As mentioned on Yammer, it has happened for me since version 2. Some hints: - Sometimes it's fine for one hour, sometimes 10 minutes, sometimes 20 seconds. - The env variable seem to help, but I'm not sure - Last time it happened I noticed Ubuntu updating system had just kicked in, causing a spike in CPU usage at the same time so I suspect high CPU usage triggers it. I've tried various video settings to reduce Vidyo CPU usage, but that doesn't seem to have helped. - I've seen it happen with both Ubuntu 13.10 and Ubuntu 14.04, on different machines. Again, I suspect CPU usage because it happens less on my more powerful laptop.
(In reply to Andrew Overholt [:overholt] from comment #21) > For me it's been "be on a call more than 10 or 15 minutes, notice you can't > hear the other person/people, see CPU usage go very high (just looking at > top or whatever), |pkill VidyoDesktop; VidyoDesktop&|". Sorry I don't have > a clear STR. Note that I don't need to kill VidyoDesktop since v3, I merely need to restart the conference. In v2 I had to kill VidyoDesktop.
Looks like I can't access the client quite as easily as I'd thought. I've asked the Vidyo folks for a trial or some such, will try to take a look once that's sorted.
So the Vidyo folks asked for this to be brought up with your (i.e. Mozilla's?) Vidyo representative. If someone knows how to do that, I'd be happy to help continue this conversation with them. If not, the person who contacted me said they'd be able to get me a technical contact.
Hello All, (Closing the loop w/my response to the Yammer thread) I have submitted this case to Vidyo on your behalf. They may be reaching out for system logs and other information as they try to squash this bug.
There is a follow up Robb Carroll opened a new case with Vidyo. Case - 35819
Created Service Now Incident: INC0015618
Why do you change the bug summary in a way that it's hard to decipher and search for? The old one was much better for that, the new one just doesn't say at all what's actually going on.
Linux is not even mentioned anymore.
Christian - can you confirm the following: "Can you also verify if you have 'VIDYO_AUDIO_FRAMEWORK=ALSA' set in /etc/environment? If not can you add it to there and reboot and see if the issue is still present? If it is, please provide updated logs."
(In reply to Robert Kaiser (:firstname.lastname@example.org) from comment #30) > Why do you change the bug summary in a way that it's hard to decipher and > search for? The old one was much better for that, the new one just doesn't > say at all what's actually going on. Migrating tickets to Service Now. Trying to keep the ticketing in order. Apologies for the confusion.
(In reply to Tony Recendez from comment #33) > Migrating tickets to Service Now. Trying to keep the ticketing in order. > Apologies for the confusion. This is here for people to be able to follow it and search for it, which SN just can't do reasonably. Though with this changed bug summary, nobody will find it anyhow.
I experienced this issue on Fedora 22 every time I joined a Vidyo conference. I got audio for the first 5 to 20 seconds, after which it cut out. The video remained, I can see all participants, but I can't hear anything. The system sound is unaffected (bleeps when changing the system volume, etc) but no audio comes through in Vidyo after the initial few seconds. I did not have a VIDYO_AUDIO_FRAMEWORK environment variable set while this was going on. After I set it (by adding "export VIDYO_AUDIO_FRAMEWORK=ALSA" near the top of /usr/bin/VidyoDesktop), audio works correctly. In my Vidyo settings under Devices, I have also found that I must select 'HDA Intel PCH' rather than 'Same as system' in order for audio to work. My system is a Lenovo Carbon X1.
I tried starting Vidyo from the command line with "VIDYO_AUDIO_FRAMEWORK=ALSA VidyoDesktop". Every time I started a call the program said it couldn't acquire access to the microphone. I tried all input devices in Vidyo's Devices settings, no luck. I'm running Ubuntu 14.04 with a USB headset.
VIDYO_AUDIO_FRAMEWORK=ALSA also seems to make audio (both incoming and outgoing) not function in Fedora. FWIW, this bug is still driving me crazy and happens almost every single time I have to use Vidyo. Is there any update from Vidyo?
I agree with Andrew's previous comment: I stopped using Vidyo on my computer because of this, I only go to office rooms where I can use the in-room equipment.
No response from Vidyo so far, but I noticed that the problem was a conflict when running with PulseAudio (which is not supported by Vidyo yet) To make sure this doesn't happens to you, run /usr/bin/pulseaudio --kill before running Vidyo. You can also do it during a conversation and re-enter the room. I know it looks like an hack, but you will need it until Vidyo supports pulseaudio.
The workaround from #comment7 works fine for me (Fedora). Audio is lost in rare occasions now and all I have to do to fix it during a meeting is to (re)select the audio device and hit Apply on Vidyo settings.
If you find Vidyo fighting with PulseAudio for the device, you can use pasuspender (pasuspender <command>) to suspend PulseAudio for the duration of a program. This will make all PulseAudio clients not work during that period, but is a bit more elegant than having to kill the PA process (which will automatically respawn).
Oh I didn't know that. Thanks, I will try it.
(In reply to Arun Raghavan from comment #41) > If you find Vidyo fighting with PulseAudio for the device, you can use > pasuspender (pasuspender <command>) to suspend PulseAudio for the duration > of a program. > This did not work for me. The audio still cuts out if the system has any load.
System load appears to trigger this bug reliably. Running a disk backup program or doing a software update during a call can drive up the system load to 5.00, and under that level of load the audio will cut out in a matter of seconds.
I found a workaround for Ubuntu 14.04. No audio cut-outs after a week of use, but I have to manually switch pulseaudio on and off depending on the program I am using. Setup: 1. Disable pulseaudio autospawn: http://www.linuxplanet.com/linuxplanet/tutorials/7130/2 To use Vidyo: 1. $ pulseaudio -k 2. $ VIDYO_AUDIO_FRAMEWORK=ALSA VidyoDesktop To use other programs: 1. $ killall VidyoDesktop 2. $ pulseaudio -D 3. # Start program First time you try this, check Vidyo Settings->Devices, verify your hardware input/output (see comment 35). You may need to restart Vidyo if the hardware changes. You may also be able to remove the environment var by amending /etc/environment per comment 32.
Still hitting this under Ubuntu 15.10, fwiw. Setting the PULSE_LATENCY_MS env variable seems to fix it.
Is there a reason the latest version is not proposed on https://v.mozilla.com/download.html?lang=en ? I've been told version 3.6.3 doesn't have this issue, but only 3.3 (with the issue) is proposed on v.mozilla.com.
3.6.3 is available from https://vidyoportal.cern.ch/download.html?lang=en for those who don't have it yet.
(In reply to François Marier [:francois] from comment #48) > 3.6.3 is available from https://vidyoportal.cern.ch/download.html?lang=en > for those who don't have it yet. I tried installing this now, but it does not work here, it still has problems with these dependencies: libaudio2; libqt4-gui. I searched for new guidance, I saw this topic in Discourse, I created falses dependency for missing dependencies (libaudio2; libqt4-gui), but I'm surprised with a new problem when trying to run > root@geraldobarros-PC:/home/geraldobarros/Downloads# VidyoDesktop > /opt/vidyo/VidyoDesktop/VidyoDesktop: error while loading shared libraries: libQtWebKit.so.4: cannot open shared object file: No such file or directory  https://discourse.mozilla-community.org/t/installing-vidyo-on-ubuntu/13320/6 =( Cheers, Geraldo Barros
(In reply to Geraldo Barros [:geraldobarros] from comment #49) > (In reply to François Marier [:francois] from comment #48) > > 3.6.3 is available from https://vidyoportal.cern.ch/download.html?lang=en > > for those who don't have it yet. > > I tried installing this now, but it does not work here, it still has > problems with these dependencies: libaudio2; libqt4-gui. I got around this by repackaging Vidyo with its dependencies list updated for 16.04. This Ask Ubuntu question has the exact steps for repackaging Vidyo with the needed deps: https://askubuntu.com/questions/766615/how-to-install-libqt4-core-and-libqt4-gui-on-ubuntu-16-04
Yeah, I usually create a false package for libqt4-gui (using equivs) but still install the QT package libqtgui4. I never had to manually install the webkit package though I have it currently installed -- maybe the older vidyo already triggered the installation. Repackaging with the proper deps is cleaner but also slightly more work :)