driver "Latency Timer" fix for macOS 11+ & M1+

ScottThomasMillerScottThomasMiller Brooklyn!
edited July 14 in Cyton

Hi! I am trying to apply the FTDI fix on my MacBook M1 by following these instructions:

https://docs.openbci.com/Troubleshooting/FTDI_Fix_Mac/

When I run this instruction:

sudo kextunload /System/Library/Extensions/FTDIUSBSerialDriver.kext

I get the following error:

Executing: /usr/bin/kmutil unload -p /System/Library/Extensions/FTDIUSBSerialDriver.kext
Error Domain=KMErrorDomain Code=71 "Could not find: No bundle was found at /System/Library/Extensions/FTDIUSBSerialDriver.kext." UserInfo={NSLocalizedDescription=Could not find: No bundle was found at /System/Library/Extensions/FTDIUSBSerialDriver.kext.}

I've tried FTDI versions 1.4.7 and 2.4.4. Both installers run without errors, but neither seem to install the driver into /System/Library/Extensions/FTDIUSBSerialDriver.kext.

I do however find the driver installed under /System/Volumes/Data/Library/Extensions/FTDIUSBSerialDriver.kext, but when I try to unload it I get a different error:

Executing: /usr/bin/kmutil unload -p /System/Volumes/Data/Library/Extensions/FTDIUSBSerialDriver.kext
Error Domain=KMErrorDomain Code=3 "Error occurred unloading extensions: Missing extension with identifier com.FTDI.driver.FTDIUSBSerialDriver : Incompatible architecture: Binary is for x86_64, but needed arch arm64e" UserInfo={NSLocalizedDescription=Error occurred unloading extensions: Missing extension with identifier com.FTDI.driver.FTDIUSBSerialDriver : Incompatible architecture: Binary is for x86_64, but needed arch arm64e}

Please help.

Comments

  • wjcroftwjcroft Mount Shasta, CA

    Scott, hi.

    The VCP page,

    https://ftdichip.com/drivers/vcp-drivers/

    Shows only Intel x64 drivers for macOS.

    The M1 is an ARM chip. Have you tried reaching out by phone or email to FTDI, to see what they recommend for the M1 Macs?

    https://ftdichip.com/technical-support/

    Seems like they should be aware of this situation and working on a solution. In the meanwhile, if you are using the OpenBCI_GUI to gather the data stream, it already performs (by default) some internal buffering operations to reduce the impact of the driver stuttering. But if you are instead using Brainflow or other real-time streaming software to access the Cyton data, expecting that there will be zero latency introduced -- then a fix from FTDI will be more urgent for you.

    I somehow thought that some OpenBCI engineering staff were already testing with M1, but that might be only with the GUI. Mentioning Richard @retiutut.

    Regards, William

  • Hi William. The stuttering happens with the OpenBCI GUI, and with my custom Swift app which uses BrainFlow. Is there no other workaround or solution for the M1? Maybe running in Rosetta mode, or using the WiFi shield?

    I sent an email to [email protected] I'll keep you posted.

    --Scott

  • wjcroftwjcroft Mount Shasta, CA

    Another comment I would have for FTDI, is that they should make adjustments in the driver parameters EASY to do on Mac. As you can see on Windows, this is trivial using their control panel. No such ability on Mac. Which is why the workaround involves editing an 'Info.plist' file.

    It's possible that FTDI would know how to do this for Apple's default driver.

  • FTDI says:

    you are free to try our latest Apple VCP driver for the Mac M1 (also works for x86_64 Mac OS 10.15)

    https://www.ftdichip.com/Drivers/VCP/MacOSX/FTDIUSBSerialDextInstaller_1_4_7.zip

    This dext based driver must be run from the /Applications folder on your Mac.

    I'll give it a shot.

    --Scott

  • wjcroftwjcroft Mount Shasta, CA

    Ask them how to eliminate the 'latency' buffering that happens by default. In Windows this is easily done with a control panel FTDI provides. Are you in contact with a real tech support engineer, or merely some "customer service" agent with little tech knowledge?

  • Will do. It's hard to say if the emails are coming from tech support or customer service. I'll call their US tech support #.

  • I'm working with a support person named Cameron via email. He is responding quickly. I asked him which built-in driver I should unload. He replied that he needs to verify with their Mac team in the UK.

    While I wait, I am trying to hack this out myself. I think I found the built-in driver on my M1. I first did:

    ioreg -w0 -rc IOUSBHostInterface -l |grep FT

    And I noticed in the output a driver named com.apple.DriverKit-AppleUSBFTDI. So I unplugged my dongle, unloaded the driver via:

    kmutil unload -b com.apple.DriverKit-AppleUSBFTDI

    When I plugged the dongle back in and looked for its device in /dev/cu*, it's not there! So far so good. Next I unzipped Cameron's recommended 1.4.7 driver, moved its contents into my Applications folder, ran it, and granted it permission to run via Security & Privacy.

    I can now see /dev/cu.usbserial-DM0258EJ. But I cannot find the Info.plist to edit. There is no such directory /System/Library/Extensions/FTDIUSBSerialDriver.kext.

    --Scott

  • wjcroftwjcroft Mount Shasta, CA

    It might be best to continue the conversation with the actual real engineers at FTDI in the UK. The support person you are emailing with is unlikely to have any detailed information on how to alter the latency timer settings. FTDI engineers really need to test and document how this is done with the new beta test version of the driver and M1. It's frankly daunting the current OpenBCI instructions on how to modify the 'Info.plist' parameters, which are targeted at the previous kext driver version. This new driver is using the new 'Dext' (driver extension) technology.

    I'm going to send you my email address. Please forward your conversation with FTDI. And any future emails you get regarding the M1 support. I'll followup with them and you with more specific tech information on what we are trying to achieve: how that was done in the past and asking how Dext's handle this.

    William

  • While we await word from FTDI, I made a little progress on my own. I found where they keep the Info.plist for the new driver, but when I update it per your doc, it won't run due to a code signing issue. I have SIP disabled, and dev mode enabled, and I even tried signing it myself. Still no luck.

    The file is located in:

    /Applications/FTDIUSBSerialDextInstaller_1_4_7.app/Contents/Library/SystemExtensions/com.ftdi.vcp.dext.dext/Info.plist

    --Scott

  • wjcroftwjcroft Mount Shasta, CA

    Scott, yes, I discovered the Info.plist myself a couple days ago. No surprise that the whole app package is code signed.

    I hope that FTDI replies to the email we sent. They obviously have the ability to alter these driver settings. And should give Mac users the same capabilities that Windows users already have with the driver control panel. I will 'remind' them of this with an email followup.

    William

  • I saw your email. Thanks.

    I used my local ID to sign it, but apparently that's not good enough. The internet seems to think I need to pay $100 for a real Apple developer ID, and use that to sign it instead.

    I did the following to sign it:

    codesign --deep --force --verbose --sign "[email protected]" ~/Downloads/FTDIUSBSerialDextInstaller_1_4_7.app
    /Users/scottmiller/Downloads/FTDIUSBSerialDextInstaller_1_4_7.app: replacing existing signature
    /Users/scottmiller/Downloads/FTDIUSBSerialDextInstaller_1_4_7.app: signed app bundle with Mach-O universal (x86_64 arm64) [com.ftdi.vcp.dext]

    But when I click the install button, I get: "Invalid code signature or missing entitlements"

    I've been meaning to get a real Apple dev ID anyway, so I guess it's time I shelled out the $100.

    --Scott

  • retiututretiutut Louisiana, USA
    edited November 2021

    Can we reduce this thread to set of easily understandable steps with bullet points? @ScottThomasMiller @wjcroft

  • wjcroftwjcroft Mount Shasta, CA

    Richard, Scott will have to comment, but I believe FTDI is the hold-up. They have not released an M1 driver that allows adjustment of the latency. Even though Scott tried contacting them via several channels.

  • wjcroftwjcroft Mount Shasta, CA
    edited November 2021

    Just posted this on the FTDI Community Forum:

    https://www.ftdicommunity.com/index.php?topic=547.msg2009#msg2009


    Quote from: FTDI Community on September 27, 2021, 05:47:33 AM
    Hello,

    That would be the last version of macOS to support .kext drivers, this would be 10.15, but there is an extra notarization step for .kext drivers required by Apple in 10.15, that is not noted in that document. As such it would be safe to assume these instructions work up for drivers up till macOS 10.14.

    Best Regards,
    FTDI Community

    Hi "FTDI Community" / moderator,

    I've been in contact with @ScottThomasMiller regarding his difficulty adjusting the macOS 11 FTDI 'latency' setting. (macOS 11 is required for Apple hardware using the new M1 CPU.) For our Windows customers, this is extremely easy: they just bring up the Windows driver control panel, and type in the new Latency value. In this case '1' ms is the Latency value we need for optimum packet latency with the OpenBCI Cyton product.

    What we are requesting: is a similarly easy way to do this on macOS 11. That should not require modifying Info.plist files, or signing a driver. It should be an external file that you look for, upon driver loading time. This would have fields similar to a .plist, for adjusting values like are possible on Windows. But it would not have to be a .plist, could even be something simple like one line per adjustment: "variablename value".

    Can you give us a timeline for when FTDI will release this macOS 11 compatible driver with adjustable settings? The lack of this is causing great difficulty with our Mac customers.

    Thanks,

    William Croft
    OpenBCI Forum admin

  • William is correct. It might be that FTDI is having trouble getting the necessary entitlement from Apple. Or they've essentially closed shop and have no one around who remembers how to code :)

  • neurosynthneurosynth Valencia, ES

    Hey everyone! Was wondering if there was any update/solution for this? Just ordered a new M1 Macbook (preloaded with Monterrey and un-downgradable ???? might be a whole different ball game than Big Sur) and wanted to head off any potential issues, perhaps there is workaround involving Rosetta, or even Wine?

    Those forum responses by FTDI did not exactly inspire confidence, but @ScottThomasMiller and @wjcroft , perhaps they sent you guys some more encouraging emails? (Thanks for all of the legwork so far)

    Spoke with @retiutut a couple weeks ago, he mentioned that the FTDI buffer is stuck at 16ms. While not ideal, would it be possible just to smooth the incoming data and live with extra 16ms latency? I use the cyton for audio and synthesizer applications; 16ms is right at the upper threshold of noticeable latency, and this will likely much more forgiving than latency felt from playing a physical instrument.

    Thanks!
    -- Calvin

  • ScottThomasMillerScottThomasMiller Brooklyn!
    edited December 2021

    Hi Calvin. Still no help from FTDI. I had to give up and move on. My team decided to live with the jitter we have, for now. We are only at the very earliest, proof-of-concept stage, so we don't yet require extreme precision and accuracy.

    For smoothing we use Mathematica to ingest the EEG and marker streams, and do lots of maths on it. Even still our primary researcher sits in a wooden shed behind his house to run the experiments, so that he doesn't have to deal with the noise from the A/C circuits in his house, which I personally think is pure genius.

    --Scott

  • neurosynthneurosynth Valencia, ES
    edited December 2021

    Hi Scott,

    Gotcha, good to know the performance isn't a total dealbreaker, my work is also pretty early stage right now but hoping this can be resolved by summer 2022.

    I came across a completely unrelated thread of people struggling with FTDI/M1 issues; someone mentioned that the application Serial 2.0 fixed their problem. But I'm not going to speculate too much until I get everything together in the same room, maybe everything is fixed in Monterrey. No experience with Mathematica, do most of my work in Max/PD and Python, hopefully I can find a way in Max to smooth everything over.

    Funny you mention the wood shed, I recently discovered an entire cottage industry of pricey RF-blocking hats on amazon for people afraid of 5G, perhaps one of those would work well on top of an ultracortex

  • wjcroftwjcroft Mount Shasta, CA

    Calvin, thanks for that mention of the Serial 2 product / app / drivers. Found it below. $40. If anyone tries this and sees that it supports adjustable Latency Timer on FTDI, please comment. Free trial offered.

    https://www.decisivetactics.com/products/serial/
    https://www.decisivetactics.com/support/view?article=compatible-devices [supports FT231X, used on dongle]
    https://www.decisivetactics.com/support/view?article=device-notes-ftdi
    https://www.decisivetactics.com/support/view?article=which-driver-is-in-use

    I left this comment on their Contact form:

    Hi, for M1 Macs, the current official FTDI VCP serial port driver, has no means of adjusting the FTDI 'Latency Timer' value. Windows machines can easily do this through a Device Manager GUI control panel. Does your FTDI driver support adjustment of Latency Timer value? We need to set 1ms value. FTDI chip is FT231X, used in the OpenBCI Cyton product. Thanks,

  • neurosynthneurosynth Valencia, ES

    Hi all,

    Just wanted to provide a quick update using with the M1 in case anyone else had had concerns. Overall I've actually had pretty smooth sailing with the Cyton and OpenBCI GUI. Initially, back in January the dongle would only connect to the Cyton via a powered USB2 hub (had a similar problem/workaround with connecting to arduino boards), but after recent macOS updates, this no longer seems to be necessary.

    The OSC streams out of the GUI with no issues, everything in the GUI runs basically the same as it did on an intel based mac apart from some minor font/size issues. The main issues I've experienced had more to do with other applications that are receiving the OSC signals: programs that are not yet built for apple silicon and run in Rosetta tend to behave strangely and are prone to freezing when presented with heavy OSC streams. I've managed some workarounds (OSCulator may be helpful for some) and I think most issues will work out eventually as more and more programs are updated for apple silicon.

  • mkeetermkeeter Cambridge, MA

    I ran into the same issue with the latency timer, and discovered this thread while searching for answers.

    In the end, I wrote a small C program that uses libftdi to adjust the latency timer. This fixed my issue, and may help you all as well!

    You can install libftdi through Homebrew, then compile and run the program with something like

    cc -I/opt/homebrew/include/libftdi1 -L/opt/homebrew/lib -lftdi1 main.c -o adjust_latency_timer
    ./adjust_latency_timer
    

    You'll have to run the program each time you connect the FTDI cable to the computer.

    (There are a bunch of other details in this blog post)

    Hope that helps!

  • wjcroftwjcroft Mount Shasta, CA

    @neurosynth, thanks for that report on your M1 experience. This thread is primarily dealing with the FTDI 'latency' issue on M1 machines, which causes 'stuttering' of received radio packets from the Cyton. The actual bottleneck is in the dongle FTDI usb-serial chip, which is mistakenly buffering and holding onto packet data. This was not so much an issue with earlier Mac, because a workaround was possible using driver Plists. On Windows the fix is trivial, because the setting can be made in a driver control panel UI.


    We just had a new member, Matt Keeter, @mkeeter, join. Who is going to post on this thread regarding his macOS workaround for setting fixing the latency issue. His blog has a section on FTDI:

    https://mattkeeter.com/blog/2022-05-31-xmodem/#ftdi

    And he offers this macOS stand alone C program to set the latency. Matt, where is this latency value stored then, in the macOS driver, or some type of flash ram on the FTDI chip? So this program just needs to run a single time?

    https://gist.github.com/mkeeter/c43c3990ecdb8dcb6547ac3dbac8e881

    I hope you have updated the FTDI community thread on this same deficiency:

    https://www.ftdicommunity.com/index.php?topic=547.msg2009#msg2009

    Mentioning @ScottThomasMiller @retiutut

    Regards, William

  • mkeetermkeeter Cambridge, MA
    edited June 3

    I think the latency timer value is stored in volatile memory on the FTDI chip, so it's reset to the default of 16 if you unplug the FTDI cable from the computer.

    I did a quick test to confirm this – since the program reads and prints the latency timer before setting it, I see

    $ ./adjust_latency_timer
    Got latency 16
    Set latency to 2
    
    $ # re-run with cable still plugged in
    $ ./adjust_latency_timer
    Got latency 2
    Set latency to 2
    
    $ # unplug + replugging cable, and the value resets itself
    $ ./adjust_latency_timer
    Got latency 16
    Set latency to 2
    
  • How exciting! Thanks mkeeter. I will check it out.
    After 8 months I finally heard back from Apple Feedback Assistant regarding this issue. Their reply is:

    • Latency timer can be configured with ioctl IOSSDATALAT.
    • buffer size is not configurable.

    --Scott

  • wjcroftwjcroft Mount Shasta, CA
    edited June 9

    Scott, thanks.

    Regarding the ioctl call, is that with Apple's driver, or FTDI's? Seems unlikely FTDI would not know about their own supported driver calls. On the other hand, if this call is NOT in their driver, should be easier for FTDI to add this to their code than the link I shared via email.

    Most likely this ioctl does not 'remember' the value across dongle insertions.

    Quite a few matches online:

    https://www.google.com/search?q=ioctl+IOSSDATALAT

    William

Sign In or Register to comment.