This is not strictly a Linux-issue as I reproduce this issue under Windows 10 as well (but can not reproduce under Android or macOS), but I will be using Linux for any troubleshooting and I wasn’t sure where else to post this....
That looks very similar to mine, except I don’t have AAC and aptX. I guess the WH1000MX5 only supports SDC and LDAC? As far as I know, I need to use the Headset Head Unit to get microphone input. After a system update some time back, it would switch automatically if I e.g. was on a Signal call. Prior to this, I would have to switch manually to get microphone input.
By the way, I am not entirely sure if I am running PulseAudio or PipeWire, as I get the confusing output below, but it seems to be PulseAudio. Is it likely to improve things if I were to switch to PipeWire?
<span style="color:#323232;">$ pactl info | grep "Server Name"
</span><span style="color:#323232;">Server Name: PulseAudio (on PipeWire 0.3.80)
</span>
As for my Windows issue, it seems LDAC is not natively supported in Windows 10, so I guess it is using SDC. Could my problems simply be that I am trying to stream a too high bitrate? I will need to recheck my settings for stream quality.
Hm, yeah. Just checked in macOS, and it is using AAC there. So lack of AAC on my Linux device would mean it is not available here for some reason then I guess, and not an issue with the headset?
I can’t seem find a way to check the same on Windows 10 without using a third-party tool, and since this is a work computer, that is not an option for me. My guess is then that it uses SDC. Seems like AAC is supported natively in Windows 11 though, and the device is scheduled for a Win 11 install soon. Hopefully that will resolve the issue for me during work hours.
For now it seems to work better under Linux with LDAC though, which is my main use case. I swear I’ve had issues with this before, but I just streamed an entire album of high-bitrate FLAC tracks without issue now. Hopefully it stays this way.
I am using ProtonVPN, and have (or so I thought) set up qBittorrent to bind to the network interface that ProtonVPN is using (tun0). The connection symbol turns red if I turn off the VPN, and downloads will stop. However, when checking the torrent address on ipleak.net, it seems that this bind is not working properly - my real...
That is what the interface bind is supposed to prevent, or at least that is what I thought it was supposed to prevent. To avoid IP leaks in case of a lost VPN connection. I wonder if I’ve misunderstood it, or misconfigured it or something else.
Thanks - those were both enabled, and I’ve disabled them now. However, this still happens after I’ve done this and restarted the client. I also tried turning off peer exchange that I found together with these options under the Privacy tab, also without solving the issue.
I’ve tried staring with all my might at the different options in the hopes I might identify something. I did turn off the features suggested above in the comment field, but have still been unable to solve it.
It is the “Torrent Address detection” magnet link I am using, and it is this that reveals my real IP when the VPN is disabled. The traffic in qBittorrent stops though.
EDIT: And as I mentioned in an earlier post, it works as intended if I open the client when not connected to the VPN. It is just if the client is running while I disconnect that this problem occurs, as far as I can tell.
That was the case until the recent update to the Linux GUI client. I had to change the network interface bind in qBittorrent because the proton0-one stopped appearing. I assumed they had just made some changes, but could this mean that something is faulty with my install?
tun0 goes away when I am disconnected, so I don’t think anything is keeping it open. I noticed that connections in Proton VPN were set to UDP, so I changed this to TCP and this seems to have worked. Will still want to do more testing to be sure.
I don’t seem to have v3 installed, by the way. The old GUI tool seems to have been uninstalled when upgrading, and the CLI tool I unisntalled myself.
Yeah, that is true - I didn’t formulate that quite well. This also happens to me when the kill switch is enabled, as it is disabled when I disconnect. However, it would not disable itself if I simply lost connection, which is in the case where I most want the leak protection. In the other cases, I could make sure to always quit qBittorrent before disconnecting from the VPN. Not ideal, as it would be easy to make a mistake.
If I start the client without being connected through the VPN, my IP does not show up. It is only when the VPN connection is disconnected and I transition from one network interface to another. This is also if I have the kill switch enabled, so I imagine that if the connection is lost, I am safe as all internet access would be blocked then. And that it is only if I manually disconnect myself that this happens.
Could this be a Proton VPN issue? I am pretty sure I checked this previously, and didn’t see it before the recent Linux client GUI update, but I am not entirely sure.
Help troubleshooting issues with Sony WH1000MX5 playback
This is not strictly a Linux-issue as I reproduce this issue under Windows 10 as well (but can not reproduce under Android or macOS), but I will be using Linux for any troubleshooting and I wasn’t sure where else to post this....
qBittorrent network interface bind not working?
I am using ProtonVPN, and have (or so I thought) set up qBittorrent to bind to the network interface that ProtonVPN is using (tun0). The connection symbol turns red if I turn off the VPN, and downloads will stop. However, when checking the torrent address on ipleak.net, it seems that this bind is not working properly - my real...