The other day I tried a video call with a friend. I am not experienced in that.
We both used Tox chat (qTox) as I thought it would be a much better alternative to the proprietary programs.
Before all that, I installed it in a Whonix Workstation template and when testing between 2 AppVMs everything seemed to work - I could see and hear myself in the receiving VM with a little delay (which seems normal as networking is not instant). The only issue was that I had to reduce the video quality to 240p, as it was not smooth at 360p. Initially, I thought it was a network speed issue that the quality reduction solves.
However, when trying the actual conversation with my friend, there was some terrible interruption and cracking of the sound he was receiving from me. He couldn’t hear me well, even in audio-only mode. I switched the NetVM from sys-whonix to sys-firewall, assuming once again that it might be a network issue. Perhaps it is not though because with speed testing I can download with 83 Mbps and upload with 15 Mpbs through sys-whonix. With clearnet the speeds are higher and 240p requires less than 10 Mbps.
As I said, I am not really experienced in these matters. I am trying to diagnose and hopefully solve the problem.
The only strange thing I see so far is: journalctl -f in the AppVM shows an endless flood of these messages:
pipewire[1271]: mod.qubes-audio: Underrun: asked to read 7524 bytes, but only 0 available
My web camera is Logitech C270. I have used it many years ago on a Windows 7 machine with Skype and there were no issues at all.
I am still in a situation where sound is not optimal, but I have found a way to reduce the problems.
Execute this command on the audiovm and the qubes, where you are facing the problem:
What it basically does is to set the “quantum” value to a forced value which is higher than what is usually used by applications. That way I was able to reduce the stutter, although my mic is still not perfect.
You guys are obviously experts in this. I am not and it is difficult for me to understand everything discussed in the linked thread.
What I can say is:
In my case there is no USB-based audiovm and I don’t have a CPU with P-cores. It is a NitroPC. The audiovm of the AppVM is dom0. I don’t know if that is related to the issue in any way. Just for clarity, my particular setup is:
The USB webcam is attached to the AppVM. qTox uses webcam’s microphone for audio input. The autio output is the line out of the PC in which headphones are plugged.
Execute this command on the audiovm and the qubes, where you are facing the problem:
Considering the clarifications above, does that still apply to my case?
How can I be sure if it fixes the issue without troubling my friend for test calls? He is not a computer expert at all. We just need a way to have a video conversation securely.
I also tried:
using the microphone male jack of standard headphones
using smartphone earplugs with 4-pole jack
with the idea to use a microphone different from webcam’s mic. However, in both cases there is a significant noise, even without any actual sound reaching the mic. These same headphones work fine on another desktop computer and on a smartphone.
I am really clueless about what is happening. As of now, I am not even clear if it is:
I am not an expert at all, I simply faced that issue myself and tried to get rid of it for weeks/months…
My suggestion does still apply for the AppVM qube, dom0 does not have “pw-metadata” installed and I am not sure if it makes sense to change that.
My problem is related to Bluetooth only by the way, not a “cabled” microphone, therefore it might not be the same issue for you.
In my experience, attaching a USB camera to an app qube always causes issues. Have you tried using qubes-video-companion to send the camera video from sys-usb to your qube instead?
As for the audio issue, it could be related to the underruns you are seeing in the logs. There is a config file related for the qubes-audio module that you can check in /usr/share/pipewire/pipewire.conf.d/30_qubes.conf
Try uncommenting the lines and see if that solves your issue.
If you are using an app qube, you can copy this config file to /home/user/.config/pipewire/pipewire.conf.d/30_qubes.conf to make it persistent (if directories are missing, you can create them).
Thanks for the feedback. I am still not sure if we are discussing the same issue, as there is no BT involved in my case. I am also looking for a way to test directly, without network, first.
In my experience, attaching a USB camera to an app qube always causes issues.
Could you elaborate?
Have you tried using qubes-video-companion to send the camera video from sys-usb to your qube instead?
No. I have just learned for this program from your post. Is it a common or recommended practice to use that for video conferencing?
I don’t understand how this will work - same webcam: video transmitted through companion, audio - how? The FAQ section talks about PulseAudio, not pipewire and I have no idea how to do what it says. How will A/V sync? What about the additional CPU load of the companion?
As for the audio issue, it could be related to the underruns you are seeing in the logs. There is a config file related for the qubes-audio module that you can check in /usr/share/pipewire/pipewire.conf.d/30_qubes.conf
Try uncommenting the lines and see if that solves your issue.
Thanks, I can do that. But if it was a pipewire setting, doesn’t that mean that the issue would be there all the time, i.e. also during the test call between 2 VMs? I am still trying to understand what the actual issue is - network, qTox itself, hardware, or the pipewire settings you guys mention.
Thanks for the feedback. I am still not sure if we are discussing the same issue, as there is no BT involved in my case. I am also looking for a way to test directly, without network, first.
that is why I wrote this:
My problem is related to Bluetooth only by the way, not a “cabled” microphone, therefore it might not be the same issue for you.
I think your issue is slightly different, but still can have the cause in the quantum value. Only way to know for sure is trying
Good luck!
As mentioned initially, in a test call between 2 Whonix AppVMs, everything was fine on the receiving side. My friend and I also had a fairly good audio-only conversation that same day. This makes me think it is something else that somehow affects sound in a so-far-unknown-to-me way. But I have no idea what.
What I can confirm is that my audio also starts to break the longer my qubes are running. Restarting the AppVM or AudioVM does not always resolve this issue. It seems that dom0 audio implementation also causes problems, because after a complete reboot things are fine again for some time.
I have a script in dom0 that tries to restart things:
What I can confirm is that my audio also starts to break the longer my qubes are running.
What means longer? Ballpark?
Restarting the AppVM or AudioVM does not always resolve this issue. It seems that dom0 audio implementation also causes problems, because after a complete reboot things are fine again for some time.
Have you reported that on GitHub? Any feedback from devs?
I have a script in dom0 that tries to restart things:
I really cannot tell, that is the reason I never reported it. It is something that does not happen suddenly but slowly degrades. I had cases where it happened from starting work (morning) where mic was good, until evening where it was bad. Sometimes it works for several days… I am not able to reproduce it in a way that a report would make sense. My assumption is that buffering becomes a problem, because raising quantum value to 2048, later to 4096 seems to help.
Doesn’t that restarting itself break sound?
I don’t think so. Sometimes particular qubes loose sound, then I restart those.
I noticed the issue in chromium, when using Teams. There it was really bad. I switched to Teams for Linux where it is better, but still the issue comes back after some time. People are telling me that my mic quality is bad.
I tested multiple bluetooth headphones and those are working perfectly fine when used on a android phone, even on my windows laptop (that I was using before Qubes) it was working fine.
This is somehow related to Qubes, because on another Linux laptop, running Ubuntu, I don’t see this this happening. But my problem is I am not able to determine the exact steps to reproduce it…
Yes, I still see them. I experimented with quantum values between 1024 and 8192 and 2048 was the best choice. The mic audio is better with it but not perfect. There are still underruns and cracks when using the mic, I was not able to get rid of them completely without restarting the whole machine.
By the way, when the machine gets rebootet, underruns do not appear, I tested it.
While trying to find more info, I read somewhere that some web cameras skip frames (perhaps also sound frames) due to insufficient power which they get from the USB port.
By the way, when the machine gets rebootet, underruns do not appear, I tested it.
Is your sound/BT hardware physically connected during the reboot? Or do you connect it after rebooting?
Also what happens if you reboot more than once? Is it back or after the first reboot it is persistently stable and cracking-free (with or without modified quantum)?
Have you also tested without network, e.g. recording something locally, then checking the result?
I am just wondering what might trigger on/off the issue in your case.
sorry for my late response, we were on vacation and I was not really “dealing” with laptop problems
Here are my answers:
Have you experimented with a different mic?
Yes, tried different bluetooth headsets, the problem is the same for all of them. They are working fine on windows laptops, as mentioned before.
While trying to find more info, I read somewhere that some web cameras skip frames (perhaps also sound frames) due to insufficient power which they get from the USB port.
Not related, not using a camera at all
Is your sound/BT hardware physically connected during the reboot? Or do you connect it after rebooting?
I am connecting the headset via bluetooth after boot
Also what happens if you reboot more than once? Is it back or after the first reboot it is persistently stable and cracking-free (with or without modified quantum)?
After reboot no change is required and sound is crack free. After some time the cracking starts. When this happens raising quantum helps, but only for some time. At some point there is no solution but reboot.
Have you also tested without network, e.g. recording something locally, then checking the result?
No, didn’t test this. Wondering how this might be related, can you elaborate?
I am just wondering what might trigger on/off the issue in your case.
