The trick I'm using (at least on laptops, cannot do this on phones AFAICT) is to change the input device to the laptop's own microphone to get my earphones to not use HFP (Hands Free Profile) and instead stay in a better quality codec (AAC, LDAC, AptX, SBC, whatever your devices agree upon).
Sound quality for my calls on both sides improved dramatically! Since I've discovered this, I tell all my colleagues in our zoom meetings to switch microphones and it's immediately better for everyone on the call (not just the user that was using HFP).
This is because if you use the hands free profile, it'll use a codec that encodes your voice in a terribly bad bitrate, and even worse, the sound you hear in the headphones is also using a terribly low bitrate.
They should finally fix HFP (Hands Free Profile) spec as it's literally impacting call quality for billions of people.
Edit:
apparently LE audio is a thing, but device support is still terrible.
I do this same technique, but typically with external mic mounted to my desk. Another benefit beyond higher fidelity audio is that it also reduces the latency for other people to hear your audio by about 100-250ms.
> And using the headset mic is probably better if the room is loud or has poor acoustics.
Not to mention the combination of "microphone in the laptop body + person who doesn't turn off their microphone when they're not speaking + person who seems to never stop typing during a call" tends to be distracting at best.
Sure, but janky $30 wireless gaming headsets have even lower latency, with better audio quality, than Bluetooth handsfree, so it's still sad that anything still uses it.
The problem with this trick is that it's very important for your callers to hear you clearly, and laptop mics usually suck, and pick up fan noise.
Maybe not a problem with Macs, but call quality on most laptops using the built in mic is bad enough that people on the other side will have a bad impression of you.
I have a friend who works in sales and business development. He was fighting with his Bluetooth headset and his laptop all the time. I told him to just get a simple USB podcast microphone. You can get a decent one for next to nothing. Problem solved. Those are designed to make you sound good. And if you do sales, you should want to sound amazing.
I actually told him many salespeople get this completely wrong and sound like an absolute Muppet on their expensive headsets without even realizing it and explained to him that anything Bluetooth is basically never going to sound amazing. There’s a lot of snake oil in the market. I got some nice Sony earbuds recently. Tried it once and I was barely audible apparently. That’s supposedly a high-end option. It’s OK, I got them for music and podcasts and wasn’t expecting much for calls. But it managed to underwhelm me on that front. The weakness is Bluetooth and the standard codecs supported on Mac/Windows. You are basically screwed no matter what BT headset you use. For phones, it depends.
Apple fixes this with AirPods by doing a proprietary codec and probably quite a bit of non-trivial sound processing. None of that is part of the Bluetooth standard, and what little is supported in some newer codecs typically does not work in Windows/Mac. So it will still fall back to that low-bitrate codec that distorts your voice and makes you sound like a Muppet.
If you need to use a phone, getting a USB-C headset can be an alternative. Not that many wired headsets these days, sadly. Even Apple now uses USB-C. And both Android and iOS support most USB-based sound equipment.
I take most calls with my Mac. I configured an aggregate device with the MIDI tool so that my headset doesn’t hijack the microphone. Nice little hack if you have some decent BT headphones. On a Mac, the microphones in the laptop are likely way better than the vast majority of headsets. And that’s before you consider the latency and heavy compression Bluetooth adds to the mix.
> Apple fixes this with AirPods by doing a proprietary codec and probably quite a bit of non-trivial sound processing. None of that is part of the Bluetooth standard
Do you have any sources for that claim?
As far as I understand (and based on what I've seen in some Bluetooth debugging menus at least a few macOS versions back), for HFP they just use regular mSBC.
That's an optional codec for HFP (while SBC is mandated for A2DP), and a step above absolute potato quality G.711/PCM u-law, but still part of the regular Bluetooth HFP specs.
Yes, see my comment about their proprietary codec that is exclusive to Apple platforms only. Won't work on Android. Won't work on Linux. Won't work on Windows. Only works with Apple headphones with Apple phones/laptops.
i get that it's more powerful but I almost consider it an anti-feature. I have very good tools for doing transformations (sed,awk,perl, etc etc) the problem is they all want line oriented format and JSON breaks that. So all I want is a tool to go from json => line oriented and I will do the rest with the vast library of experience I already have at transformations on the command line.
> So all I want is a tool to go from json => line oriented and I will do the rest with the vast library of experience I already have at transformations on the command line.*
The tool for that is likely https://github.com/tomnomnom/gron
It's probably the best tool to go back and forth easily between json and line oriented.
It's great for building large complex queries that will eventually live in scripts, but your zsh plugin seems to hit a real sweet spot of fast feedback for ad-hoc queries too! Huge props!
Yeah, I tend to use that one as well, but for me it just feels 'right' as a line editor plugin. I'm running a lot of kubectl commands and for me this plugin proved to be invaluable.
zshbuiltins(1): Unlike parameter assignment statements, typeset's exit status on an assignemt that involves a command substitution does not reflect the exit status of the command substitution. Therefore, to test for an error in a command substitution, separate the declaration of the parameter from its initialization.
Nice plugin; I got it and will be using it. Browsing the code, I saw a couple of small errors; not too serious, but some error handling is incorrect. In your `jq_complete()` function, for instance, you have
local query="$(__get_query)"
local ret=$?
Unless the `local` assignment to `query` fails, `ret` will always be 0 regardless of the return value of `__get_query`. To fix this, you would need your first line to be
Nice, esp reading Calzifier’s comment above and remembering how many times I’ve cursed the JQ syntax because of quoting issues…another “trick” I’ve been using is for any non-trivial JQ filter, stick it in a file or at least a heredoc and feed it to JQ using -f for much less quote-escaping malarkey.
nice, but... I'd written something like this (as a program you pipe to, not autocomplete) before, but when there's an error, I try to show the error then the last-good-output. The reason for this is that when you're typing a complex command you want to have the json visible to guide your thinking, just displaying the error hides it.
The way I did this was to store both the last working query and the last working output, I'd only reuse it if the last working query was a prefix of the current query - that avoids the awkward case where you are deleting letters from the output, so you need an output further back in history (which I didn't store, wasn't worth the hassle)
Sound quality for my calls on both sides improved dramatically! Since I've discovered this, I tell all my colleagues in our zoom meetings to switch microphones and it's immediately better for everyone on the call (not just the user that was using HFP).
This is because if you use the hands free profile, it'll use a codec that encodes your voice in a terribly bad bitrate, and even worse, the sound you hear in the headphones is also using a terribly low bitrate.
They should finally fix HFP (Hands Free Profile) spec as it's literally impacting call quality for billions of people.
Edit: apparently LE audio is a thing, but device support is still terrible.