Hello Tyronet and thank you for compiling a definitive, clear guide, foolproof even for a noob like me. I had arrived at a similar process after consulting every single thread online about the topic, collecting all the links, all the texts, and feeding everything to ChatGPT. Despite this, ChatGPT, which is unfortunately lazy and stupid, responded with the following when I asked it to compare the two guides: Comparison and Conclusions Accuracy and Details: The guide by "tyronet" is more detailed regarding the configuration of "Startup Security Utility" and the management of kernel extensions, which is a critical step for allowing unsigned extensions. My guide lacks specific details about the configuration of "Permissive Security." Flexibility and Methodology: The "tyronet" guide focuses exclusively on a specific workflow (installation via package and then fixing permissions), while my guide offers alternatives such as using extraction tools like "Suspicious Package." Reboot and Authorization Details: The "tyronet" guide mentions a double reboot and the need to confirm the use of kernel extensions in security settings, something not covered in detail in my guide. Security Recommendations: Both guides emphasize the importance of re-enabling SIP, but the "tyronet" guide is more explicit about potential warning messages and necessary actions if the device does not function after re-enabling SIP. Conclusion: The "tyronet" guide is more specific and detailed in some crucial steps, especially regarding advanced security settings and the reboot process. It is advisable to integrate the missing details, such as "Startup Security Utility" settings, into the initial guide to ensure a more complete and robust solution. Given this, I attempted to integrate a section into the guide regarding "alternative solutions" or to cover the possibility that AppleFWAudioVentura.pkg might not work correctly: Appendix: Alternative Solutions and Troubleshooting This section provides an in-depth look at alternative methods and solutions to issues that may arise during the installation and configuration of kexts on macOS, particularly for AppleFWAudio.kext. These solutions are intended to address specific code signing errors, permission issues, and other technical obstacles. Manual Extraction of the Kext If the installation of the AppleFWAudioVentura.pkg package does not work, you can manually extract the kext using tools like Suspicious Package or Pacifist. Using "Suspicious Package" and "Pacifist" Suspicious Package: A macOS application that allows you to examine the contents of installation packages (.pkg) without installing them. It is useful for verifying the presence of specific files and extracting them if necessary. Download and Usage: Download the application from the official website. After installation, drag the .pkg package into the application to explore its contents. Pacifist: Similar to "Suspicious Package," it allows you to explore and extract the contents of installation packages, particularly useful if Suspicious Package is not sufficient. Download and Usage: Available on the CharlesSoft official website. After downloading and installing the application, you can search within packages and extract specific files. Extraction Procedure Open the Package: Open AppleFWAudioVentura.pkg with "Suspicious Package" or "Pacifist." Locate and Extract _AppleFWAudio.kext:_ Find the AppleFWAudio.kext file within the package and extract it to a temporary location, such as the desktop. Copy to /Library/Extensions/: Copy the extracted kext to the /Library/Extensions/ directory using the command: sudo cp -R /path/to/extracted/AppleFWAudio.kext /Library/Extensions/ Permission Fix: Ensure the permissions are correct: sudo chown -R 0:0 /Library/Extensions/AppleFWAudio.kext Loading the Kext: Load the kext with: sudo kmutil load -p /Library/Extensions/AppleFWAudio.kext Details on Kext Loading and Authorization Issues Code Signing Errors When a code signing error occurs, it is necessary to check if the kext has been properly signed or if it has been altered. Check Code Signing: Use the command: codesign -vv /Library/Extensions/AppleFWAudio.kext This command verifies the status of the code signing. If the kext is not properly signed, macOS will prevent its loading. Disabling Security Protections: Disable SIP: If SIP (System Integrity Protection) is enabled, it might block the loading of unsigned kexts. Ensure SIP is disabled: csrutil disable Kernel Extension Management: Enable kernel extension management in "Startup Security Utility" to allow the loading of unsigned kexts. Modifying Security Preferences: Go to "System Settings" > "Privacy & Security" and allow the use of the kext. You may need to confirm the decision and restart the system. Manual Permission Fixes Correct permissions are essential for loading the kext. Fix Permissions: Set the owner and group of the kext to root: sudo chown -R 0:0 /Library/Extensions/AppleFWAudio.kext Ensure read and execute permissions are correct: sudo chmod -R 755 /Library/Extensions/AppleFWAudio.kext Reload the Kext: After applying the changes, reload the kext: sudo kmutil load -p /Library/Extensions/AppleFWAudio.kext Monitor System Stability: Monitor the system for any stability issues, such as crashes or kernel panics. If issues arise, consider removing the problematic kext or re-enabling SIP. I have no idea if this will be helpful as it was compiled by ChatGPT, but I hope it can be useful in some way. Here are all the links collected online on the topic, hoping they can be helpful as well: final_grouped_sorted_links_by_domain.txt

Hi friends, For the past 14 years, I have been using a Focusrite Saffire Liquid 56 sound card paired with a mid-2011 Mac mini running Mavericks 10.9.5 (FireWire cable -> FireWire-Thunderbolt adapter). A few days ago, I bought a Mac mini M1 running Ventura 13.1, convinced that I could still use this old sound card via the Thunderbolt 3 (USB-C)-Thunderbolt 2 adapter (which I do not yet possess). However, I discovered, after contacting Focusrite support, that the sound card is not compatible with the new ARM processors (or at least they have not tested it) and that the latest supported operating systems are Catalina and Windows 10 (Build 1809). Additionally, I learned that with Ventura, compatibility with core audio FireWire has been lost, but there is still compatibility with Monterey but not with all versions. At the same time, I stumbled upon some videos on the web that attest to partial functionality of some FireWire protocol audio interfaces with the connection FireWire cable -> FireWire-Thunderbolt adapter -> Thunderbolt 3 (USB-C)-Thunderbolt 2 adapter. I thought, alternatively, that I could emulate a compatible x86_x64 operating system on a virtual machine using UTM in the hope that the USB signal would "pass through" and operate, albeit at much slower speeds, on the same machine. Or I could perform a downgrade to a specific version of Monterey that maybe someone here can confirm works with FireWire. Due to my limited knowledge and skills in the field, I doubt I am capable of using the hack proposed by matt9, to whom we surely owe much. I was wondering, in case I can't get it to work with one of these methods, what might be the solution (or advice) to not permanently abandon the sound card. Could I use ADAT with any compatible card? Do you have any other ideas? Thanks to anyone who responds/helps me.