Kx audio driver mod [Sound blaster live!, audigy 1/2/4/RX emu edsp]

[psycmos]

Thanks a lot my friend for your work. I'm using hi sierra and works good!

[Belzebubek]

ITzTravelInTime: thank you very much for the driver. Audigy4 works just perfectly. I owe you a beer, or any other drink you like.

[ITzTravelInTime]

9 minutes ago, Belzebubek said:

ITzTravelInTime: thank you very much for the driver. Audigy4 works just perfectly. I owe you a beer, or any other drink you like.

 

tank you, but mine is just a small mod to keep the mac driver going, you have to say thank you to eugene garnilov who's the developer of the original driver and he did the most of the job. But i am happy that you are enjoying your sound card, if you have a normal audigy 4, it's still a very good budget card even for today's standard and a lot better of most of the on board sound cards, and if you have an audigy 4 pro, it's one of the best pci audigy cards ever made.

[ITzTravelInTime]

i also have an announcement for the other guys, i am working on a system to let you use a custom channel mapping using a boot arg, this is because the channel assignment using the midi utility of mac os does not always works with all the programs, and also because i have some requests from the guys with broken audio ports, so i am trying to get it to work and if i can make it to work, it will be included into a new release of the driver, and i will also try to add support for custom samplerates using a boot arg bot as the channel mapping, only if i succed to made it to work, the problem i am having is reading values from a boot arg. then the next things i will add are a cuple of new sample rates, the first is 7khz because it's the standard used in some phones, so i think that it could be usefoul, the other sample rate i have added is 49,716 khz which is the standard used for the fm syntesis in old school dos sound cards, because it'used in dos and old conosoles emulators for the fm sound, which is done using a bit-accurate emulation logic, which outputs sound at the same sample rate as the original fm sound chips, and using it will allow you to get a more accure sound in some emulators, like dos emulators, without resampling fm sound, so you will have a better experience using those programs by using this sample rate, because you have a more detailed sound from the emulator, with the details you normally loose when the sound is resampled for standard sample rates, i hope that this feature will be added to other sound drivers as well, it's a nice addition for emulator's users.

Edited August 20, 2018 by ITzTravelInTime

[biohazardx9]

I must say, top work mate.

As you say the RX can still be had as well as alot of other cards.

 

Personally own the RX and some PCI based Audigy 2's.

 

Would this work on a real mac? I am guessing it would. I have a 2009 4,1 Pro and the RX should work absolutely fine.

Keep at it, you are doing great! - and fixing one of the many mysteries known to the Mac Pro (why no internal audio cards?). As you say only professional solutions exist and these can be in the £££ (or €€€ if in Italy). 

 

I can certainly test the RX for you no problem.

 

Also anyone who knows the RX there is an unknown 2 pin jumper on the board, not mentioned anywhere but if you bridge it, it turns on the mic 'gain' essentially for condenser mic's. the same feature is present on another card where it was mentioned (was also part of the audigy family).

 

For those who don't know, the audigy series including the RX are actually AC97 cards with some I2S parts. The original KX for audigy1 actually swapped the green over to the black output because it bypassed the AC97 circuitry. the Audigy 2 has the P16V which essentially does everything at 24bit 96khz (essentially HD) and the Kx driver had this mapped as an output which routed through the P16V and then to the epilog (output jacks).

 

The reason no X-Fi/Re-Con/Z series are supported is because these cards are based on the Azalia system (HDA Audio) completely different.

 

Eugine was working on an X-Fi Kx driver but it never saw the light of day, and in reality the original Kx was never finished. (so much so the windows driver had an alpha update but only got released in hardware heavens forum) - lots of things unfinished. Essentially did work though. That driver also had crackling issues under windows so something deeper was amiss.

 

To get any Emu10k based card to be recognized in MacOS and playing sound out one port is a huge step. I am sure more developers will jump at this. Definitely worth going to the Kx forums at hardware Heaven and releasing there as well as here. Some ex Kx bods will probably pick it up and help you.   

[ITzTravelInTime]

4 minutes ago, biohazardx9 said:

I must say, top work mate.

As you say the RX can still be had as well as alot of other cards.

 

Personally own the RX and some PCI based Audigy 2's.

 

Would this work on a real mac? I am guessing it would. I have a 2009 4,1 Pro and the RX should work absolutely fine.

Keep at it, you are doing great! - and fixing one of the many mysteries known to the Mac Pro (why no internal audio cards?). As you say only professional solutions exist and these can be in the £££ (or €€€ if in Italy). 

 

I can certainly test the RX for you no problem.

 

Also anyone who knows the RX there is an unknown 2 pin jumper on the board, not mentioned anywhere but if you bridge it, it turns on the mic 'gain' essentially for condenser mic's. the same feature is present on another card where it was mentioned (was also part of the audigy family).

 

For those who don't know, the audigy series including the RX are actually AC97 cards with some I2S parts. The original KX for audigy1 actually swapped the green over to the black output because it bypassed the AC97 circuitry. the Audigy 2 has the P16V which essentially does everything at 24bit 96khz (essentially HD) and the Kx driver had this mapped as an output which routed through the P16V and then to the epilog (output jacks).

 

The reason no X-Fi/Re-Con/Z series are supported is because these cards are based on the Azalia system (HDA Audio) completely different.

 

Eugine was working on an X-Fi Kx driver but it never saw the light of day, and in reality the original Kx was never finished. (so much so the windows driver had an alpha update but only got released in hardware heavens forum) - lots of things unfinished. Essentially did work though. That driver also had crackling issues under windows so something deeper was amiss.

 

To get any Emu10k based card to be recognized in MacOS and playing sound out one port is a huge step. I am sure more developers will jump at this. Definitely worth going to the Kx forums at hardware Heaven and releasing there as well as here. Some ex Kx bods will probably pick it up and help you.   

 

I personally own a large collection of 10kx based cards, a lot of sound blaster live cards, audigy 1, 2 zs, 2zs platinum pro, and the audigy rx as well (no problems for rx testing ebcause it's my main testing card) and also i own an emu em0404.

For the original driver there are still some contibutors of the original driver working on it and uploading new code on the github repo, i just merge what is important to the mac driver inside of this driver.

 

And if i figure out how to make the inputs working on mac (presumebly i must do some auto routing inside the kext to let it to work, because input routing on the windows drivers was done using the kx manager app which is not implemented on mac) the condensor gain could be very usefoul, because with it you can avoid spending money on more expensive cards.

 

But for the real macs yes, it is confirmed to work on a real mac as long as you can use 64 bit intel kexts, i have already tested it with some mac pros.

 

And yes i did know how the 10kx based cards works and some of the x-fi series can work on mac using a special version of voodoo hda.

 

 

[biohazardx9]

Of course i know you knew

 

was for the others out there.

Well, as my Mac Pro 4,1 is 64bit I shall give it a try tonight bud. (I don't use the mic so be ok for me).

 

 

[ITzTravelInTime]

4 hours ago, biohazardx9 said:

Of course i know you knew

 

was for the others out there.

Well, as my Mac Pro 4,1 is 64bit I shall give it a try tonight bud. (I don't use the mic so be ok for me).

 

 

 

in your mac with a firmware mod and a metal capable gpu you can install mojave and use it on mojave, this kext is already tested to work with mojave

[ITzTravelInTime]

for the driver development i have sucessfully implemented a boot arg which will allow you to use a custom outputs layout , this is ment for whose having problems changing it from the midi configuration app or with issues after doing that, or for people with physically missing or not working outputs, so they can change which is their main output of the sound card.

 

This is as announced some time ago, but now thanks to some help from @vit9696 about the function to get values from boot args, i was able to make it to work.

 

So this new driver is currently in testing, more info about the release and how to use this feature later.

Edited October 4, 2018 by ITzTravelInTime

[cdoublejj]

so whats the last version of OSX or MacOS one could use in a hackintosh? Mojave? Guess i should use my Audigy 2 ZS SB0350 instead of my X Fi Music Extreme SB0730? I also have an Audigy 2ZS. i figured the Audigy 2 ZS and non ZS were the same card minus the addon thingy? Does the X - Fi sound that much better?

[ITzTravelInTime]

6 hours ago, cdoublejj said:

so whats the last version of OSX or MacOS one could use in a hackintosh? Mojave? Guess i should use my Audigy 2 ZS SB0350 instead of my X Fi Music Extreme SB0730? I also have an Audigy 2ZS. i figured the Audigy 2 ZS and non ZS were the same card minus the addon thingy? Does the X - Fi sound that much better?

 

The driver is compatible with mojave, so if you have the possibility to install a 10kx compatible card you can use it on mojave, and yes you should use an audigy because no cards from the x-fi series are supported by this driver and the difference between 10kx compatible cards and x-fi cards is that that x-fi cards does uses on board ram with a more modern and simpler protocol based on hda, so this reduces latency, ram usage, and CPU usage, but 10kx cards are cheaper and easier to find, with better compatibility with older machines and older oses and there isn't a significant difference in sound, maybe the x-fi has a slightly better on board amplifier. And the difference between the audigy 2 and audigy 2 zs cards is that the zs Introduces some slight improvements for recording and latency, I personally own a couple of audigy 2 zs , an audigy rx , and audigy 1 sb0090 and a lot of sound blaster live series and an emu em0404

[>Alejandro]

Hello! I tried to add support for inputs and it succeeded. I tested on the EMU-1616m. I do not have SB Live and Audigy cards to test the inputs, but I know SB0090 inputs are working. It would be interesting to know on which sounds cards the inputs work, and on which not. Please download the driver from here.

To install, use the "install creative" script, it will install the kext in the S/L/E folder and kX AC97.app in the applications folder. To uninstall, use the "uninstall creative" script.
For EMU, use the "install emu" script, it will install the kext in the S/L/E folder and the mixctrl.app in the applications folder. To uninstall, use the "uninstall emu" script.

[ITzTravelInTime]

4 minutes ago, >Alejandro said:

Hello! I tried to add support for inputs and it succeeded. I tested on the EMU-1616m. I do not have SB Live and Audigy cards to test the inputs, but I know SB0090 inputs are working. It would be interesting to know on which sounds cards the inputs work, and on which not. Please download the driver from here.

To install, use the "install creative" script, it will install the kext in the S/L/E folder and kX AC97.app in the applications folder. To uninstall, use the "uninstall creative" script.
For EMU, use the "install emu" script, it will install the kext in the S/L/E folder and the mixctrl.app in the applications folder. To uninstall, use the "uninstall emu" script.

 

Can you explain me how this works? i will try to add it to my branch of the driver and to the install pack of my driver, if you agree, so can you help me adding it to this driver?

[ITzTravelInTime]

1 hour ago, >Alejandro said:

Hello! I tried to add support for inputs and it succeeded. I tested on the EMU-1616m. I do not have SB Live and Audigy cards to test the inputs, but I know SB0090 inputs are working. It would be interesting to know on which sounds cards the inputs work, and on which not. Please download the driver from here.

To install, use the "install creative" script, it will install the kext in the S/L/E folder and kX AC97.app in the applications folder. To uninstall, use the "uninstall creative" script.
For EMU, use the "install emu" script, it will install the kext in the S/L/E folder and the mixctrl.app in the applications folder. To uninstall, use the "uninstall emu" script.

 

please relase the source code of your kext so i can put in it the most important fixes from this driver like imrpoved sound blaster audiogy rx support, increased n_frames variable to amke the cracking more rare, and i want to see how you implemented sample rates switching, i have implemented a lot of supported frequencyes in my version because they can be usefoul and also i actually need some of those for some programs, and i can also add more features like the custom layout mapping from a boot arg, so you can avoid issues by remapping inputs using the midi configuration app. So we can make a better driver for everyone, and also without the fixes for the audigy rx, users of such cards will experience issues like the not working outputs except for the main one.

[ITzTravelInTime]

i have also tested your driver, but imputs works just with all the consumer cards i tested after tuning some settings in the kx ac 97 app, the mix control app give me an error telling that i don't have any cards installed, but you driver still lacks a decent audigy rx support, to make the front audio connector on that card to work add this to the friver/frname.cpp file at line 415

 

case 0x10241102:
            strncpy(tmp_str,"SB1550",KX_MAX_STRING); // audigy rx experimental
            is_a4=1;
            break;

@>Alejandro

 

And also recording prduces cracking noise at high sample rates, so consider maing a seoparate audio engine istance for the input with it's indipendent frequency, because the driver code does allows for indivual channels

 

But i have to say that after testing for a while your driver i am quite impressed with your work, you fixed some of the persistant problems of this driver and you also managed to getting inputs to work, so great job, but there are still a lot of things to be made.control for smaple rates.

Edited October 8, 2018 by ITzTravelInTime

[>Alejandro]

Source code on GitHub. To avoid crackling try to change the value separately for 10K1 and 10K2 in AudioEngine.cpp line 127

 

    if(hw->is_10k2)
    {
        // setSampleOffset(28); // 28 samples
        //setSampleLatency(28+1);
        setSampleOffset(40);
    }
    else
    {
        // setSampleOffset(32); // 32 samples
        setSampleLatency(32+1);
    }

My value is probably wrong, but it works for me. setSampleOffset is deprecated, maybe need use setInputSampleOffset and setOutputSampleOffset.

Also try to increase n_frames. With an increased n_frames, my recorded sounds crackling.
mixctrl app is designed for EMU.

 

 

[ITzTravelInTime]

5 hours ago, >Alejandro said:

Source code on GitHub. To avoid crackling try to change the value separately for 10K1 and 10K2 in AudioEngine.cpp line 127

 

    if(hw->is_10k2)
    {
        // setSampleOffset(28); // 28 samples
        //setSampleLatency(28+1);
        setSampleOffset(40);
    }
    else
    {
        // setSampleOffset(32); // 32 samples
        setSampleLatency(32+1);
    }

My value is probably wrong, but it works for me. setSampleOffset is deprecated, maybe need use setInputSampleOffset and setOutputSampleOffset.

Also try to increase n_frames. With an increased n_frames, my recorded sounds crackling.
mixctrl app is designed for EMU.

 

 

 

Thank you very much for the suggestion, problaly we need toi use different values for the conumer 10k2 based cards, professinal 10k2 based cards and consumer 10k1 based cards, and also we need to do a lot of testing, on my audigy 1 i don't have the cracking recording, but on my audigy rx i have it, but i still have to test my audigy 2 cards and my emu em0404 card, so i am not sure if your values will work on all the cards, probably we still have to do a lot of testing to figure this out.

 

now i am trying by appliyng some modifications to your source code, to create a driver which has both the features of yours and mine, and also with improves audigy rx support, and consumer cards compatibility.

 

Can you add the sound blaster audigy rx support to your driver? just add 3 lines in the driver/frname.c file (see prev. posts)

 

 

Edited October 14, 2018 by ITzTravelInTime

[>Alejandro]

15 hours ago, ITzTravelInTime said:

Can you add the sound blaster audigy rx support to your driver? just add 3 lines in the driver/frname.c file (see prev. posts)

I will add, thank you!
Are you testing sound cards on the same hardware or on different ones? What version 0404 do you have, pci or pcie? Inputs do not work on it?

[ITzTravelInTime]

1 hour ago, >Alejandro said:

I will add, thank you!
Are you testing sound cards on the same hardware or on different ones? What version 0404 do you have, pci or pcie? Inputs do not work on it?

 

 i am testing the driver on a couple of different computers, one with pcie only (i7 4770k, sabertooth z87, gtx 960, mac os high sierra) and the sound blaster audigy rx, and the other is a socket 775 machine (asus p5q3 deluxe, q8400, gtx 650, yosemite, sierra, mojave).

 

The sound cards i have and i am testing are: sound blaster audigy rx (sb1550), audogy 2 zs (sb0350), audigy2 zs platinum pro (sb0360), audigy 1 (sb0090), e-mu em0404 pci (em8852) but currently without the adapters to use the outputs, sound blaster live series cards: CT4830, SB0060, SB0100, SB0220.

 

I will try different values for the n_frames and the sampleOffset to solve the cracking issues on some consumer cards (for exaple i didn't experience the cracking recording on the audigy 1, but on my audigy rx i did)

 

And also i need to remap the inputs, because some apps will not working with the mic inputs mapped on channels 3 and 4, but with the mic inputs mapped on channels 1 and 2

[semson]

24 minutes ago, ITzTravelInTime said:

 

 i am testing the driver on a couple of different computers, one with pcie only (i7 4770k, sabertooth z87, gtx 960, mac os high sierra) and the sound blaster audigy rx, and the other is a socket 775 machine (asus p5q3 deluxe, q8400, gtx 650, yosemite, sierra, mojave).

 

The sound cards i have and i am testing are: sound blaster audigy rx (sb1550), audogy 2 zs (sb0350), audigy2 zs platinum pro (sb0360), audigy 1 (sb0090), e-mu em0404 pci (em8852) but currently without the adapters to use the outputs, sound blaster live series cards: CT4830, SB0060, SB0100, SB0220.

 

I will try different values for the n_frames and the sampleOffset to solve the cracking issues on some consumer cards (for exaple i didn't experience the cracking recording on the audigy 1, but on my audigy rx i did)

 

And also i need to remap the inputs, because some apps will not working with the mic inputs mapped on channels 3 and 4, but with the mic inputs mapped on channels 1 and 2

That's a lot of work. thank you! start expecting the new release

[>Alejandro]

56 minutes ago, ITzTravelInTime said:

And also i need to remap the inputs, because some apps will not working with the mic inputs mapped on channels 3 and 4, but with the mic inputs mapped on channels 1 and 2

Try remove condition in microcode.cpp line 509. I made reassigned inputs only for e-dsp cards. 

     if(hw->is_edsp){
         kx_connect_microcode(hw,prolog_pgm,"in0",epilog_pgm,"asio0");
         kx_connect_microcode(hw,prolog_pgm,"in1",epilog_pgm,"asio1");
         kx_connect_microcode(hw,prolog_pgm,"in2",epilog_pgm,"asio2");
         kx_connect_microcode(hw,prolog_pgm,"in3",epilog_pgm,"asio3");
         kx_connect_microcode(hw,prolog_pgm,"in4",epilog_pgm,"asio4");
         kx_connect_microcode(hw,prolog_pgm,"in5",epilog_pgm,"asio5");
         kx_connect_microcode(hw,prolog_pgm,"in6",epilog_pgm,"asio6");
         kx_connect_microcode(hw,prolog_pgm,"in7",epilog_pgm,"asio7");
     }

In fact, the microcode is loaded into dsp 10Kx the same as in the Windows version of the driver, since the microcode.cpp file is common to both operating systems. But in the section "#if defined (__ APPLE__)" (line 501) there is an additional action for mac.

[ITzTravelInTime]

14 minutes ago, >Alejandro said:

Try remove condition in microcode.cpp line 509. I made reassigned inputs only for e-dsp cards. 

     if(hw->is_edsp){
         kx_connect_microcode(hw,prolog_pgm,"in0",epilog_pgm,"asio0");
         kx_connect_microcode(hw,prolog_pgm,"in1",epilog_pgm,"asio1");
         kx_connect_microcode(hw,prolog_pgm,"in2",epilog_pgm,"asio2");
         kx_connect_microcode(hw,prolog_pgm,"in3",epilog_pgm,"asio3");
         kx_connect_microcode(hw,prolog_pgm,"in4",epilog_pgm,"asio4");
         kx_connect_microcode(hw,prolog_pgm,"in5",epilog_pgm,"asio5");
         kx_connect_microcode(hw,prolog_pgm,"in6",epilog_pgm,"asio6");
         kx_connect_microcode(hw,prolog_pgm,"in7",epilog_pgm,"asio7");
     }

In fact, the microcode is loaded into dsp 10Kx the same as in the Windows version of the driver, since the microcode.cpp file is common to both operating systems. But in the section "#if defined (__ APPLE__)" (line 501) there is an additional action for mac.

 

thank you i will test it immediatly, in your driver try to do this too: in the audioDevice.cpp file of the kext code, after the declaration ofn the variables in the initHardware function's body, insert this, this enables the use of a boot arg, which is "-kxoff" which in this implementation, prevents the driver from starting, this can be usefoul in case you messed up something and you want to be able to boot the system anyway

 

	char tmp[16];
    
    if (PE_parse_boot_argn("-kxoff", tmp, sizeof(tmp) / sizeof(char))){
        debug(DBGCLASS"[%p] Driver disabled by disable boot arg\n",this);
        return false;
    }

 

[ITzTravelInTime]

1 hour ago, >Alejandro said:

Try remove condition in microcode.cpp line 509. I made reassigned inputs only for e-dsp cards. 

     if(hw->is_edsp){
         kx_connect_microcode(hw,prolog_pgm,"in0",epilog_pgm,"asio0");
         kx_connect_microcode(hw,prolog_pgm,"in1",epilog_pgm,"asio1");
         kx_connect_microcode(hw,prolog_pgm,"in2",epilog_pgm,"asio2");
         kx_connect_microcode(hw,prolog_pgm,"in3",epilog_pgm,"asio3");
         kx_connect_microcode(hw,prolog_pgm,"in4",epilog_pgm,"asio4");
         kx_connect_microcode(hw,prolog_pgm,"in5",epilog_pgm,"asio5");
         kx_connect_microcode(hw,prolog_pgm,"in6",epilog_pgm,"asio6");
         kx_connect_microcode(hw,prolog_pgm,"in7",epilog_pgm,"asio7");
     }

In fact, the microcode is loaded into dsp 10Kx the same as in the Windows version of the driver, since the microcode.cpp file is common to both operating systems. But in the section "#if defined (__ APPLE__)" (line 501) there is an additional action for mac.

 

UPDATE: This worked like a charm!

 

Now there is a new problem i found, the perfom format change does not changes the sampling rate of the inputs on consumer cards, so the pitch is totally wrong.

[>Alejandro]

On ‎10‎/‎14‎/‎2018 at 10:32 PM, ITzTravelInTime said:

Now there is a new problem i found, the perfom format change does not changes the sampling rate of the inputs on consumer cards, so the pitch is totally wrong.

At 48 kHz, do all cards record sounds without cracking?
If remove code from performFormatChange and record at frequencies other than 48, the pitch is correct?

[ITzTravelInTime]

1 hour ago, >Alejandro said:

At 48 kHz, do all cards record sounds without cracking?
If remove code from performFormatChange and record at frequencies other than 48, the pitch is correct?

 

At 48 khz, it seems to work fine, but there is some noise in some applications, which can be reduced or solved using the kxac97 app toi control the gain, at least in final cut, audacity and discord, but at higher or lower frequencyes the pitch is totally wrong or i have some periodic interferance and distortion into the recording which i think is caused by some sample frames overlapping, because the system expects another sample rate, but the card does only produces a 48 khz stream.

 

The code in perform format changes does only affects the outputs for the consumer cards, so i think that we must implement some other code specific to the inputs