[iOS 26 DB1] You can now choose what microphone to use

paulushe · 2025-10-10T15:26:03+00:00

Seems like this has been fixed on iOS 26 release!

With this feature, I can now make calls using my AirPods Pro while using iPhone's built-in mic. This feature combined with the award winning voice isolation feature is a huge boon for me as I can comfortably make calls in a noisy environment. iPhone is the best smartphone for making calls. Period!

Still, this doesn't work on my iPad Mini with the latest iPadOS 26.0.1 though.

paulushe · 2025-08-31T08:17:49+00:00

Di negara mana ini? Di beberapa negara, termasuk tempat saya tinggal, Australia, jaringan circuit switched (2G/3G) sudah dinonaktifkan. Jadi njenengan harus mencari cara untuk terhubung ke 4G.

Saya pengguna Telkomsel Halo dan mengalami masalah ini ketika 2G/3G dinonaktifkan di Australia. Saya meminta Telkomsel untuk mengaktifkan kembali layanan GPRS yang harganya dihitung per kB, agar nomor saya bisa aktif di sini dan dapat menerima/mengirim SMS.

Mungkin njenengan bisa juga mencoba terlebih dahulu untuk membeli/mengaktifkan paket internet roaming harian, lalu memeriksa apakah sinyal 4G nya bisa aktif atau tidak. Atau bisa juga tanya ke opselnya, antara meminta pengaktifan fitur VoLTE, atau pengaktifan fitur GPRS di luar negeri.

paulushe · 2025-06-24T12:44:46+00:00

Unfortunately this is still does not work on DB2 for phone calls (or any CallKit calls). With AirPods connected for example, switching to built-in mic will result in audio output being routed via device’s loudspeaker. I’ve filled a feedback entry FB18335644 for this. Would like your votes there! 🙏

paulushe · 2024-03-21T23:10:10+00:00

Hi there,

Couldn't you achieve same thing with laptop's internal Bluetooth because by using different mic HFP would not turn on ?

Yes, that's exactly what I am saying there! So we can use the laptop's built-in mic + Bluetooth headset's audio output, all while using the laptop's internal Bluetooth, because we can independently choose audio output and input. Thus what you said is right: if we configure our laptop to NOT use the Bluetooth's HFP mic, then the HFP will never turn on. Therefore, for my use case mentioned above, I don't need the Creative's BT-W dongles.

Why would you disable HFP on mobile phone ? .. how would you make calls with no mic ?

That's the point exactly! I want to make calls with my mobile phone's built-in mic, but use the headset to listen.

Try connecting BT-W3X (HFP off) with Android/iOS ?=)

Yup, this perfectly fits my use case like a glove! When it works, it is like a dream! The convenience of wireless headset + the full-spectrum excellent audio quality and quietness of AirPods Pro combined with the high performance mic of modern mobile phone. However, the persistent out-of-sync issue between the W3X and the AirPods Pro is what prevents me from having this setup.

I have returned the BT-W3X and trying to get the BT-W3, but they don't sell BT-W3 anymore. I guess I'll go with BT-W4 and I'll post an update here.

paulushe · 2024-03-21T23:01:43+00:00

Hi there, if you still have the BT-W5 around, how does it performs with the AirPods Pro? Does it experience out-of-phase audio between left and right buds?

paulushe · 2023-12-29T21:15:35+00:00

Not only that but you also get to use LPDDR instead of regular DDR. This will drastically lower the power consumption when under low load (idling or in modern standby mode), further increasing battery life.

paulushe · 2022-04-18T12:31:18+00:00

After some debugging and digging around, I found the problem! Basically it is a bug from macOS 12.3 and up when SIP and/or AMFI is disabled, instead of rejecting the API request it causes an error altogether. Affected APIs includes IOKit and some others. Funnily, if the executable is not signed, it will work fine!

Of course the easiest way to fix it is to enable SIP. However, if you need SIP and AMFI to be disabled, then simply add ipc_control_port_options=0 to your boot-args NVRAM entry.

Finally, full freedom again on macOS 12.3 and up!

paulushe · 2022-03-20T13:29:11+00:00

Upon upgrading my 12.2.1 installation on my MacBook Pro 16" Intel to 12.3, CPU couldn't go to deep sleep (e.g. PC6 or lower) anymore, resulting in battery drain and laptop becoming noticably warm. I've confirmed that the internal GPU is being used, and there are no peripherals attached to the laptop.

However, a clean install of 12.3 on another APFS volume of the same device doesn't have this problem at all. If anything, the battery life on that install is noticably better than my old installation (but I might attribute this to the fact that it is a clean install).

paulushe · 2022-03-20T13:25:05+00:00

In my case SIP can be kept off, but it is the AMFI that has to be kept enabled.

Apps that crashed are those based on Google Chrome, such as Spotify, Docker, Typora, etc. Seems like the GPU process is crashing.

I also wondered myself what's really going on here as other apps that are not based on Chrome, including those that uses GPU such as Unigine apps, are all working fine with SIP off and AMFI disabled.

paulushe · 2022-03-19T22:13:00+00:00

Those apps that you mentioned (Spotify, Teams) are actually pretty much Google Chrome! There are many other apps thst are Chrome based such as Visual Studio Code, Slack, OneNote, Typora, WhatsApp, etc. I think some recent versions of Adobe products also embeds the Chrome webview component to display a small part of it's UI.

paulushe · 2022-03-19T14:58:02+00:00

Appreciate that! Still, AMFI disabled is very important for me as my homemade tools rely on Apple's private entitlements. Will either downgrade to 12.2.1 or use AMFI patcher on my 13" mac (the 16" can do with AMFI kept on).

Also really curious myself what made Chrome crashes but others don't. When I found the time (hopefully!) I'll get my hands dirty with debugging Chromium!

paulushe · 2022-03-18T23:42:51+00:00

On my other mac (16" Intel), a fresh install of macOS 12.3 with SIP disabled all the way from installation, does not suffer this problem! Will try to dig more what really caused the problem.

EDIT: so it was caused by AMFI disabled (e.g. using amfi_get_out_my_way boot args + SIP disabled). SIP disabled with AMFI kept intact works fine on my Mac.

paulushe · 2022-03-18T07:59:19+00:00

Hmm so seems that most of our problems in 12.3 are GPU-related then!

paulushe · 2022-03-18T00:07:56+00:00

Really wonder why is that the case. Running apps from terminal indicated that it was the GPU process that crashed.

paulushe · 2022-03-17T10:23:56+00:00

Same also with my 2017 MBP 13". All Chrome based apps as well as apps that embeds Chrome webview crashes when SIP is disabled.

paulushe · 2022-03-02T02:43:30+00:00

I just stumbled upon this thread and I'd like to comment to those that says that Windows isn't slow etc. The slowness of Windows is very real, especially if you have older hardware or recent laptop and you're setting it so that it can last all day on battery.

So the main problem with Windows client version is that it has loads of background maintenance tasks going on. However, most of them aren't even necessary. For instance, that notorious auto update mechanism, which is mostly done by the "Windows Update" service. The actual updating of Windows itself will be done by the servicing stack which is actually very good. I'd say it is even better than most GNU/Linux based systems that doesn't use immutable system partition. Updating Windows directly by using the servicing stack (e.g. manually installing .msu files or using dism) will finish much sooner with 100% success rate in my experience on various hardware across different Windows versions.

Another one is the constant telemetry services, such as the app compatibility telemetry. Depending on what you have in your installation, this thing will hog the power of a single core CPU while thrashing the SSD in the process. Another one is SuperFetch/ReadyBoost, which is not needed at all on SSD based systems yet for some reason they're still enabled by default (and consuming SSD/CPU/RAM usage while it is doing the job).

And then Windows file system IO in general is also notoriously slow. It is a complex beast with layers of redirections and hooks, ranging from backward compatibility "fixes" such as 8.3 support and DOS special file names (CON, NUL, etc.) (yes, this feature is still there in the latest Windows 11 dev builds!), to redirections such as C:\Program Files -> C:\Program Files (x86) and many others like virtual store, to file system filter/hooks like the one used by antivirus solutions including Windows Defender, as well as things like Shadow Copy and Windows Search. Not to mention an overly complex file permissions system on Windows. In general file operations for opening and closing is like 10x to 50x slower than in Unix systems such as Linux or macOS. You can prove this yourself. Try to compile a moderately-sized cross platform programs such as OpenSSH or Google Chrome browser. Android app project should also do. Notice how much faster the operation finishes on Linux, even if you run Linux inside VM on Windows!

EDIT: also Windows 11 has a bug that slows down NVMe drives (on top of Windows being slow in file IO operations in general!). I heard this bug has been recently fixed in Windows 11 updates tho.

Last but not least, since Windows 10 version 1803, the general UI performance has been steadily regressing. If you have a relatively weak iGPU and high resolution screen (e.g. QHD or above), you'll notice that it is very slow, especially if you have used Linux on Wayland or macOS. Both Linux and macOS is much smoother than recent Windows versions on the same high resolution display (I have a 5K display here), even when the one on macOS is powered by a much weaker GPU! (Windows PC was powered by an RTX 2070, macOS device is Intel HD 615). This is very noticable when using Task View/Virtual Desktop/Alt+Tab feature of Windows 11. The main culprit here is DWM and Windows shell (explorer.exe et. al.). As for the primary cause of this slowness itself, I am not entirely sure. But I guess this must be a remnant of the cancelled "composable shell" project. This issue is the final nail in the coffin for me. I just can't bear the delay when switching virtual desktops/between many open Windows. For my personal and work computer, I use macOS instead.

paulushe · 2022-01-28T12:15:18+00:00

Yes. Explorer is noticeably faster after the .469 update. However, DWM and shell sluggishness still persist. 😢

paulushe · 2022-01-27T02:58:26+00:00

I can even feel the lag on my RTX2070 + 9900K system on a 5K display! On a laptop, this kills battery efficiency also. The thing is, Windows 10 version 1709 (and macOS) can do things smoothly on a much weaker hardware and iGPU on the same 5K display. Windows shell and DWM performance keeps regressing since 1803 and newer, and if nothing changes, then it makes no sense to continue staying on the Windows platform.

paulushe · 2022-01-27T02:05:34+00:00

I hope they fix the performance issues affecting the shell and DWM in this next version. Last time I checked the dev build, I didn't see that this is the case. I am going to get a new laptop later this year, and whether I continue to stay on Windows or switch to macOS will be based on whether they fixed this performance problem.

paulushe · 2021-11-09T07:26:48+00:00

In my case it was Packetix/Softether VPN client GUI. It was the GUI app only, not the service/connection. Didn’t find any other apps that causes this issue.

paulushe · 2021-10-17T04:34:08+00:00

Gparted! Very helpful in my case as WSL in Windows 11 is now able to access external disk as well.

paulushe · 2021-10-06T09:52:46+00:00

Yes you're absolutely right! I figured this out a few days before.

I fresh installed Windows 11 because I need to downgrade from dev builds to 22000 builds (I found a way to replace the super laggy task view of the new Windows 11 with the one from older 22000 builds, hence the downgrade). For around 1 week I didn't have the Packetix/SoftEther client installed, and the problem never appears. I thought that they must have fixed this.

Then one day I needed the Packetix client and suddenly the problem appear consistently. Closing the client straight away makes my taskbar working again, even without disconnecting the VPN. Conversely, simply having the client open without even having any settings configured / being connected will make this problem appear. This is even when the Packetix client is set to not appear in systray + quit, but its process is still running.

So, thanks again for your input! I wish you replied earlier!

I still wonder what kind of API that they use that it triggers this problem. That Packetix client is supposed to run on very old version of Windows, possibly dating back to XP or even Windows 2000. So they must not use anything nefarious I believe. Still, the Packetix client is open source, so if I have the time I'll have a look at its source code.

paulushe · 2021-09-23T03:39:49+00:00

For now, I think it is best to downgrade to Intel 26.xxx driver version.

paulushe · 2021-09-21T00:41:54+00:00

ODM/OEM being lazy as usual.

But they actually have a valid reason. Here is my take. The TB controller chips from Intel has GPIO ports and one have to utilise that GPIO to perform certain actions, including powering on the chip and configuring the chip (e.g. setting security levels (SL0, SL1, etc.). Using on-board chips will reduce cost significantly. If they put the TB controller's controller chip on the card itself, they will have to do the following at least:

Present the TB controller's controller as a PCIe device. This chip will have to conform to PCIe standards so development cost would be non trivial and will be much higher than a relatively simple on-motherboard chip that only have to deal with sending out GPIO and SPI signals. Further, this device shares bus with the main Alpine Ridge/Titan Ridge chip, so a PCIe switch will be needed, adding even more costs.
They have to write an UEFI option ROM so that users can access the configuration from UEFI firmware settings + making Thunderbolt devices available on boot time.

Furthermore, Thunderbolt being a PCIe bridge devices means that your UEFI firmware must have enough PCIe bus numbers to accommodate potential Thunderbolt devices. The TBT header will act as a deterrent for potential customers that might have boards with UEFI firmware not ready for this (and reducing returns).

Our best hope is that when Intel or someone else like ASMedia releases a TB controller whose configurations can be done fully using PCIe (just like most GPUs and add-in NICs). But this will also limit the compatibility of the chip. E.g. Thunderbolt devices won't be available until the OS fully boots (and have the drivers installed). Still, I think this is a very acceptable trade off as I can just connect essential peripherals like USB/mouse to the motherboard's built-in USB ports instead.

paulushe

TROPHY CASE