Jump to content

Creative SB [Live!, Audigy, Audigy2, EMU10kX eDSPs] OSX Driver info here!

Oxtie

By Oxtie,
in Archive

 Share
850 posts in this topic

Recommended Posts

  • 4 weeks later...
  • 2 months later...
nst
nst
Posted
Posted

Hi,

 

am also using a SB0350 (Audigy 2 ZS) on Mavericks (10.9.2) on an Asus P8Z77-V LX (i7-2600, 8GB Ram, Nvidia GeForce GTX760 - everything working nicely so far), and having a quite annoying problem with it:

 

Whenever I play back audio, after a random but usually short amount of time (from one minute up to ten minutes) the audio stream starts crackling, sounding as if some kind of buffer would be either shifted or overrun, but the original sound is still noticeable (so it doesn't just start to make random noise). Stopping and starting the stream again (e.g. in iTunes, hit stop and start) fixes it temporarily until it starts to make buffer-shifting sounds again. Having only stereo speakers connected, Audio/MIDI setup is configured for stereo mode aswell.

 

Anyone had this and found a way to work around this?

 

Regards,

nst

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

In my experience, those particular symptoms indicate that there's a timing issue caused by either misconfigured CPU power management, or a basic hardware conflict.

 

To begin with, if you're overclocking, dial back to default clocks while troubleshooting. Make sure your base clock is set/detected correctly and CPU power management is working correctly. To put it simply, if there's a mismatch between what OS X thinks your CPU is doing and what it's actually doing then you get sound crackling.

 

iMac13,1 or 13,2 smbios is recommended on Z77 boards.

 

Sometimes it can be a simple hardware conflict - shared IRQs.

 

First thing to try is to place the card in a different slot (if possible) and disable unused hardware in the BIOS.

 

Going further along this line, you can try removing all fixed IRQs allocated to certain devices in your DSDT. This will allow OS X to distribute them freely. See the topic "fix for slow SATA issue" (or something like that) on ProjectOSX for more information. Note that the information there is for reference, do not copy any code - you must find the equivalent code in your own DSDT and edit it as described in the topic, where applicable.

Doing this may or may not fix the issue but it will not cause any problems either, it's 100% safe.

Link to comment
Share on other sites
nst
nst
Posted
Posted

First, thanks for your hints! :)
 

In my experience, those particular symptoms indicate that there's a timing issue caused by either misconfigured CPU power management, or a basic hardware conflict.


Well, I have a feeling the former was more or less a direct hit. I've been using some old (handmade? don't really remember where I got it from) SSDT matching my particular processor, but seemingly not _fully_ matching. I replaced it by one generated with ssdtprgen, and while once I got the somewhat-buffer-underflow-crackling again, I'm listening to a stream for over 3/4 hour now, without anymore hiccups, which is a huge improvement already.
 

To begin with, if you're overclocking, ...


No, at least not that I'm aware of, but then, the MoBo setup has everything set to defaults, which might do some slight "performance increase", but didn't look yet. However, there's not that much to overclock, since the processor is a non-K variant.
 

iMac13,1 or 13,2 smbios is recommended on Z77 boards.

 
Will try changing to that. Due to the SB-CPU, it's currently set up to pretent it's an iMac12,2 (actually, I upgraded from a P67 MoBo lately and didn't change it since, but the audio issue was already there with that board).

On a side note (missed that in the first posting) - onboard audio (AppleHDA+ALC887) works without any slightest issue, regardless of any workloads.
 

Sometimes it can be a simple hardware conflict - shared IRQs.


At least /proc/interrupts in Linux pretents it isn't sharing anything, but well...
 

Going further along this line, you can try removing all fixed IRQs allocated to certain devices in your DSDT. This will allow OS X to distribute them freely. See the topic "fix for slow SATA issue" (or something like that) on ProjectOSX for more information. Note that the information there is for reference, do not copy any code - you must find the equivalent code in your own DSDT and edit it as described in the topic, where applicable.

Doing this may or may not fix the issue but it will not cause any problems either, it's 100% safe.


Yeah, found that thread, and basically, my DSDT doesn't have any edits regarding the IRQ things in the PIC/HPET/TIMR devices, so probably making adjustments here might help even further, will see - but only one thing at a time ;-)

Again, thanks for the hints!
nst

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

You're welcome, I'm happy to share what I know, especially when I turn out to be right :D

 

If you try removing the forced IRQs later, let me know if anything happens. It shouldn't cause any side effects (never has for me) so try it and see if there's any change.

 

You can use IOJones or IORegistryExplorer to track which IRQs are going where.

 

I've never checked but I'm pretty sure that IRQ distribution in Windows or Linux is irrelevant, OS X probably arranges them in its own way.

 

I guess it's possible that the Audigy is more "timing-sensitive" than your on-board ALC audio is? It could also be the kx driver requiring stricter timing.

Link to comment
Share on other sites
nst
nst
Posted
Posted

Didn't get further yet (so didn't change anything more yet), will have time to fiddle around with the install next week and keep you (and everyone else interested) uptodate.

 

I guess it's possible that the Audigy is more "timing-sensitive" than your on-board ALC audio is. It could also be the kx driver requiring stricter timing.

I had a look at the driver source (which is up on GitHub now for some time at https://github.com/kxproject/kx-audio-driver) and saw two or three spots to add some debug code and maybe find related things, but also one really suspecting spot when thinking of Mavericks and the new "Timer Coalescing", will also play a bit with that :)

Link to comment
Share on other sites
nst
nst
Posted
Posted

I guess it's possible that the Audigy is more "timing-sensitive" than your on-board ALC audio is. It could also be the kx driver requiring stricter timing.

Well, tampered a bit with the driver code, and this little change completely removes the described problem for me, without sacrifying anything output-latency related or system stability or so.

 

So if the change goes in, anyone experiencing this should get the driver source, build+install the kext and check again.

 

@Gringo Vermelho, thanks again for taking your time and your suggestions! :-)

 

nst

  • Like 2
Link to comment
Share on other sites
  • 1 month later...
Forbidden Era
Forbidden Era
Posted
Posted

Didn't realize the OS X code was on github, I didn't see it when I looked.

 

nst, if you're playing with things we should butt heads. I have been coding for 20+ years.

 

I has a 680i LT (with 680i BIOS) hackpro wit an Audigy 2 Internal PCI (SB0244) and an Audigy 2 PCI (SB0280) "External" (break-out box). :D

 

And probably 20 other creative cards in a box (Sb live, audigy, audigy 2 value, etc)

 

I want both cards to work (and internal audio would be nice too since my board has optical out and 6 ports but thats a whole other story) with input, output, low latency.

 

DSP routing etc. would be nice too (aka GUI)

 

The whole reason I set up this HackPro is because I've switched to Logic completely now and my Macbook Pro isn't cutting it. I can use my S4 as a SC but then I have to use the internal audio on the mbp. I'd rather use the S4 of the mbp and the audigy exernal on the hackpro. My m-audio audiophile usb died when trying to get it to work on Mavericks (tried a different driver that fried the firmware) so I want the audigy to work.

 

They don't make cards like this.

 

Now that I know the OS X code is actually up there.. well.. tehe.

  • Like 1
Link to comment
Share on other sites
Forbidden Era
Forbidden Era
Posted
Posted

Output is working on the External (which is the first PCI card), doesn't see the internal yet. Now that the driver's at least working I can start to play.

 

Edit: Also had to get Win7 up and running dual-boot on the HackPro - will be useful for comparisons (eg. Windows driver is more complete)

  • Like 1
Link to comment
Share on other sites
  • 5 months later...
  • 4 weeks later...
cdoublejj
cdoublejj
Posted
Posted

Well, tampered a bit with the driver code, and this little change completely removes the described problem for me, without sacrifying anything output-latency related or system stability or so.

 

So if the change goes in, anyone experiencing this should get the driver source, build+install the kext and check again.

 

@Gringo Vermelho, thanks again for taking your time and your suggestions! :-)

 

nst

 

How does 1 build a kext with zero programming and compiling abilities? 

 

Does any one know where to get the adapter to hook up the front panel connector to a normal cases/s front panel connector. 

 

 

Edit: what's weird is, is that branch was merged in 2014 but, the pre compiled drive is still from 2014. i wonder if we could compile it and upload said kext for others to use.

Link to comment
Share on other sites
  • 2 weeks later...
takeawaydave
takeawaydave
Posted
Posted

How does 1 build a kext with zero programming and compiling abilities? 

 

Does any one know where to get the adapter to hook up the front panel connector to a normal cases/s front panel connector. 

 

 

Edit: what's weird is, is that branch was merged in 2014 but, the pre compiled drive is still from 2014. i wonder if we could compile it and upload said kext for others to use.

 

Installed Yosemite for the first time last night and used my version of kXAudio kext that I've been using for Mavericks and it worked no problem.

 

Haven't given it extensive use yet so can't comment on overall sound quality. not exactly sure on  the version I was using but 11_b sounds familiar.

 

Hook up is possible using custom cable from the break out pins. Like this one:

 

http://audigy2zshowto.blogspot.ch

Can anyone help me to use My SB Audigy card on Yosemite? I tried the driver but it doesn't work. I also compiled from github source but still the same. I will appreciate if you give me a hand.

 PM  me if this is still a problem. Got running last night with no sweat.

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

How does 1 build a kext with zero programming and compiling abilities? 

 

You don't have to be a carpenter to use a carpenter's tools.

 

Register as an Apple Developer, download and install Xcode and the command-line tools, download the source code for the driver, edit relevant source file with a suitable editor, then open the Xcode project file and click the build button. :P

Sometimes you have to fiddle with build settings, for example when compiling for older OS X versions or different architecture (32 vs 64-bit).

Hook up is possible using custom cable from the break out pins. Like this one:

 

http://audigy2zshowto.blogspot.ch

 

Make sure to go through the comments section before breaking out the soldering iron!

Link to comment
Share on other sites
  • 3 weeks later...
XxMr.ManxX
XxMr.ManxX
Posted
Posted

Worked Great with my Pentium 4 Hackintosh!!! I bought a creative sb0350 sound blaster audigy 2 zs sound card off ebay and all I had to do was plug it in, disable the onboard sound in the bios and install this driver

 

Thanks!

Link to comment
Share on other sites
  • 5 months later...
gfkeo
gfkeo
Posted
Posted

Hi everybody.

 

I have an MDD-2003 with OSX 10.4.11 + XCode 2 and i've put an SB Live! into the machine.

I installed the kx Driver 1.3b0, but something is wrong.

The kxctrl says the binary cannot be executed. (chmod +x did not helped)

The kx control center in the applications folder does not work, it just throws up a message, that this version of OSX is not good for it.

I did not found any information on the page, that this binary is for the PPC or the x86 Tiger.

 

I tried to do it from source. I read the readme, it said: no build instructions for Mac. I checked the "macosx" folder, i read the scripts and i understood what they are do, but none of them build the binaries. I tried to open the project file with XCode, but it did nothing, it did not open it, did not show any error.

 

I'm familiar with UNIX-es, but i am new with OSX.

 

Can anyone help me?

Link to comment
Share on other sites
takeawaydave
takeawaydave
Posted
Posted

Hi everybody.

 

I have an MDD-2003 with OSX 10.4.11 + XCode 2 and i've put an SB Live! into the machine.

I installed the kx Driver 1.3b0, but something is wrong.

The kxctrl says the binary cannot be executed. (chmod +x did not helped)

The kx control center in the applications folder does not work, it just throws up a message, that this version of OSX is not good for it.

I did not found any information on the page, that this binary is for the PPC or the x86 Tiger.

 

I tried to do it from source. I read the readme, it said: no build instructions for Mac. I checked the "macosx" folder, i read the scripts and i understood what they are do, but none of them build the binaries. I tried to open the project file with XCode, but it did nothing, it did not open it, did not show any error.

 

I'm familiar with UNIX-es, but i am new with OSX.

 

Can anyone help me?

 

Hi gfkeo - the driver has been compiled for Intel processors not the PPC ones in your G4.

Link to comment
Share on other sites
MacUser2525
MacUser2525
Posted
Posted

I thought, but why can't i compile it with XCode? How can i do that anyway?

 

By having an Intel machine with the correct SDK installed. With this code the platform is Intel processors/machines now you having a PPC means it will never compile on that platform the instruction set the compiler is looking for is not going to be there. Now there is a method called cross compiling where you can compile code on another platform that targets a different platform than it has been compiled on but this does not apply to you Intel code is never going to run on PPC.

Link to comment
Share on other sites
gfkeo
gfkeo
Posted
Posted

I am not sure, if i understand it correctly.

If i compile a C source on a PPC platform, the target platform will be PPC. Why would it be x86, if i try to compile this driver? Cross compiling is when i compile for x86 on PPC, or vice versa, but i try to compile for PPC on PPC.

Link to comment
Share on other sites
  • 1 month later...
  • 2 months later...
kd503_b
kd503_b
Posted
Posted

Well, tampered a bit with the driver code, and this little change completely removes the described problem for me, without sacrifying anything output-latency related or system stability or so.

 

So if the change goes in, anyone experiencing this should get the driver source, build+install the kext and check again.

 

@Gringo Vermelho, thanks again for taking your time and your suggestions! :-)

 

nst

 

I had the same problem and this kext fixed it. I'm using Yosemite.

kXAudioDriver.kext.zip

Link to comment
Share on other sites
  • 2 weeks later...
 Share
Go to topic listing
×
×
  • Create New...