Jump to content

ITzTravelInTime

Developers
  • Posts

    1,055
  • Joined

  • Last visited

  • Days Won

    13

ITzTravelInTime last won the day on August 20 2021

ITzTravelInTime had the most liked content!

Reputation

967 Excellent

About ITzTravelInTime

Profile Information

  • Gender
    Male
  • Location
    Italy
  • Interests
    Computer science, programming, hardware, gaming and collecting games/hardware

Recent Profile Visitors

11,690 profile views
  1. Hi, it isn't possible, it is not supported by this driver in any way, this driver basically just supports 3 specific chip families and that doesn't include the emu20k series used in the x-fi pci series. Although some of the pcie (and i mean pci express not the old pci) cards can be made to partially work using voodoo hda with some settings in it's internal info.plist file.
  2. There seems to be a compatibility issue with the bridge chip used by my e-mu 1616m pcie, because in ioreg i can see the bridge chip but not the pci device it's attached to, while i can see and use my audigy rx that uses a different bridge chip manufacturer, but ha s a similar architecture and uses the same driver and it works. So be carul, some pci bridge chips might have issues. I might have to test it further, but so far it seems that they have changed stuff reguarding pci bridge chips. Of cource booting back into my ventura install everything is fine, i hope this is an issue they might fix in the next betas or i have to try filing a bug report for it.
  3. So I have tried the kx audio driver on macOS Sonoma, and it works, however it doesn't seem to want to work with the bridge chip inside the pice e-mu cards supported by this driver, so those might definitely be problematic, but at least I can say that the audigy rx works as it should and the install procedure is the same as ventura.
  4. Are IOAudioFamily and IOPCIFamily still there? if yes then drivers like the voodoo hda and the kx audio driver will still work. EDIT: Aslo any success with haswell? When i have time i will try it on my haswell and my broadwell machines.
  5. At this point I think there is more going on with your hackintosh, you should look for specific help for this, the fact that the driver doesn't want to work might just be a consequence of those issues. About me, I can't really help you because I am very busy and no longer so in touch with the current hackintosh methods, especially on the AMD side.
  6. Are you sure you are not confusing sip with safe mode? because that sound like your gpu drivers are not loaded, to disable sip you must change the csr active config setting in clover's config.plist file to a 0xFEF to completely disable it.
  7. So there are 2 things to do: 1) The driver needs to be installed properly to /Library/Extensions from Big sur and up, due to apple removing some needed dependancies from their kernel boot artifact. Here is how to do that: You mus have SIP disabled to use the kext (because it's unsigned), then copy the kext over to that foler and do the following commands: ``` cd /Library/Extensions sudo chmod -R 755 ./ sudo chown -R 0:0 ./ sudo touch -f ./ sudo kextcache -i / sudo kcditto ``` then reboot, if the kextcache -i / command fails don't warry too much about it, at reboot you should have the kext loaded anyway. 2) You might need a version of the kext that doesn't need vector instruction sets to work, you find it attached top this post (from my latest source code). kXAudioDriver_LibraryLess.kext.zip
  8. I suppose the e-cores thing is caused by some new kernel (or system kext) code made specifically to error out in case some wired configurations in the cpu topology are detcted, since the x86 code in macOS is made just for cpus without a hybrid topology. Perhaps you can achieve boot by enabling the e-cores and disabling hyperthreading, but this is just an idea, it might as well just not work at all, for the moment it seems that work needs to be done to spoof the cpu tology detections being made by the kernel or to at least patch them with somenthing like a lilu plugin. BTW if you have the text from the e-cores panic, even a picture, posting it will be very helful, remmeber to use the keepsyms=1 and debug=0x100 boot args and to enable your bootloader config option to disable logging of loaded kexts in the panic text, so the system will not reboot after a panic and it will display some additional info about what pieces of code causes it, but also not display info we don't need. Thanks for the attention.
  9. Update: i managed to fix the cracking sounds on the audigy rx but not the e-mu 1212m pcie (all running on the same pc, using the same driver, the only major difference is that the e-mu is attached to the 1616m dock, i am investigating this issue) Anyway since it's ready to test, at least for audigy rx users, i have attached to this post the new driver build in 2 flawors (the normal one and the libraryless one that is more AMD CPUs friendly since it drops the usage of vector instructions). Those binaries are compiled for High Sierra onwards, but they should work with some older versions too, test them and let me know, if you need it, i can compile the from snow leopard to get a more compatible binary. To enable recording you must also setup the ac97 app like so (see the spoiler): kXAudioDriver_LibraryLess.kext.zip kXAudioDriver.kext.zip
  10. Update, on my x99 system, using ventura and catalina, when i use the E-MU pcie card i have a sudden kernel panic caused by an unreleased spinlock that times out, this happens only after having the fpga programmed, so there must be something wrong with what gets called, to program it, i am trying to find it and fix it. Edit : This doesn't seems to be a problem while using the sound card on big sur, on my sandy bridge test system (without cpu power management thought), to be really sure that this seems to be related to my cpu platform i must also do some tests using my mac pro 2010. The kernel panic messange, if you are interested: mp_kdp_enter() timed-out on cpu 16, NMI-ing mp_kdp_enter() NMI pending on cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 14 15 17 18 20 21 22 23 24 25 26 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 mp_kdp_enter() timed-out during locked wait after NMI;expected 44 acks but received 4 after 11948971 loops in 1100000704 ticks panic(cpu 16 caller 0xffffff80117e2f96): Ticket spinlock[0xffffff8011cf6c80] timeout after 1100000975 ticks; cticket: 0xf0, nticket: 0xfc, waiting for 0xf8, current owner: 0 (on CPU -1), start time: 1374267755462, now: 1375367756437, timeout: 1100000704 @lock_ticket.c:386 Panicked task 0xffffffa028e13218: 300 threads: pid 0: kernel_task Backtrace (CPU 16), panicked thread: 0xffffff9b5d39a598, Frame : Return Address 0xffffff80ea0eb7b0 : 0xffffff8010fedf9d 0xffffff80ea0eb800 : 0xffffff801115b786 0xffffff80ea0eb840 : 0xffffff801114aa10 0xffffff80ea0eb890 UPDATE: I think i have fixed it, it was a lock not being released in some circumstances, it's located in the DSP.cpp file and it's in the kx_update_microcode function. So far it seems to work, i will keep you updated.
  11. Good point, i forgot about the address in the name, but, In my code i have modified the card names (for a multitude of reasons, mostly for user friendliness, so instead of "SB1550" it shows "SB Audigy RX") that's why i have introduced a model name string, so that i can have this information still available, and i also plan on eventually removing the address from the names too, that's why i have included the address into the id itself explicitly, using this: hw->actualPort >> 8 (I introduced this property for my PowerPC port, but it's of reliable usage on x86 too, it's shifted by 8 bits, because, for alignment reasons the first byte of the address is usually 0, so what really makes a difference are the bits above, and with this, i can shove some characters off the id, which helps since my id string is on the long side) So in my case the name is way less unique, (and i will also eventually remove the address from it, eventually) so that's why i am using the model name, and the address explicitly, in my ID string. BTW i can recommend you to change your code as well and to transition, to using the System's functions for accessing the I/O address space, since this will remove this responsibility from the driver and make it more portable, i have already done it in my fork, so that i don't have to worry about implementing the I/O ports stuff for any platform i'd like to support. For that take a lot at those commits: https://github.com/ITzTravelInTime/kx-audio-driver/commit/5f09fdb814e80dfadaa35789b63e0b8dd2c72bdc https://github.com/ITzTravelInTime/kx-audio-driver/commit/67753b11f462d6c726833721bd664a767389a411
  12. I think the build i testes was actually an early build, from like the first forum post, was all of this implemented yet? Btw this is my implementation, i have added an extra string to the kx_hw struct so that i have a model id based off the subsystem ids (different to the user-friednly name that people could see in their device listings in various apps), and i am also using PCI and I/O locations, because the audio engine index number is a per-driver instance value and not a global value, so that i have something else to identify the card with. About your code, in case someone uses more of the same model of sound card at the same time, both cards will have the same uid, so in ventura just one will show up, so you must add something more soecific like i did. OSString* kXAudioEngine::getGlobalUniqueID(){ //const OSMetaClass * const myMetaClass = getMetaClass(); char uniqueIDStr[KX_MAX_STRING]; bzero(uniqueIDStr, KX_MAX_STRING); //const char* className = (myMetaClass) ? myMetaClass->getClassName() : NULL; snprintf(uniqueIDStr, KX_MAX_STRING, "%s:%x:%x:%x:%x:%x", /*className,*/ hw->card_model_name, hw->pci_bus, hw->pci_dev, hw->pci_func, hw->actualPort >> 8, (const UInt32)this->index); //OSString* value = super::getGlobalUniqueID(); OSString* value = OSString::withCString (uniqueIDStr); debug("kXAudioEngine[%p]::getGlobalUniqueID() -- Returned value: %s\n", this, value->getCStringNoCopy()); return value; }
  13. I tested an old build from the hardware heaven forum thread, only on ventura, and it didn't work. If you use the setIndex function to get more than one sound card to show up, i can confidently say that it's broken on ventura and it will not work. According to some documentation attached to the open source release for apple's IOAudioFamily kext, overriding the audio engine's getGlobalUniqueID function, like i did , is the way to go to ensure that all the devices will show up. I recommend you to implement it too, it's and easy fix. BTW i did some 5 cards testing today and everything worked as expected with this new driver build i made (see attached pictures).
  14. So after i got a second pcie sound card supported by the kx audio driver i made some more tests on macOS ventura with 2 sound cards, and i found out that my fix for multiple cards (and the one used by @>Alejandro in his current github source code) is no longer working, so i figured out a solution that will solve this problem once and for all. All the info on the fix can be found in this commit: https://github.com/ITzTravelInTime/kx-audio-driver/commit/d32fe400612bb61d5974c46a3641e4b0656229f3 I am still working on that code, so it will be changes, but basically the bulk of the fix is that i am now overriding the getGlobalUniqueID from the IOAudioEngine class to calculate an unique id from scratch, using various information about the current sound card that the driver is using. In the pictures you can see an exmple of this multiple cards fix working and what the new calculated UID value is. BTW i have also made another important change in my driver fork, i have migrated from using custom functions implemented using x86 I/O ports instructions (or direct I/O memory space access for the PowerPC port) to now using the system-provvided I/O Read/Write functions, this not only allows for safer driver operation (delegating I/O comunication responsibility to the OS) but could allow for way better driver potability, potentially also allowing an ARM port in the future. For now the driver seems to be working well even for inputs on the E-MU card, however there are still issues i have yet to understand how to fix, so would like to at least tackle those before ever pubblishing any new releases out. If you want i can also post some early build for you to test out. Anyway, thank you for the attention and support.
×
×
  • Create New...