Jump to content

Sound Blaster (EMU10K1) Driver Development


17 posts in this topic

Recommended Posts

This thread is dedicated to the development of a Kext for a Sound Blaster (EMU10Kx) driver based on the research from Brian Souder, formerly of Creative. Right now, we are trying to gather coders who are interested in this project.

 

If you are interested, you should promptly post under this thread. Then, you can either PM me or just contact Brian directly.

 

Brian's email address is: creativemail@mac.com.

 

Mac Kx Project Site: MacKx

 

Brian's work thus far:

 

I have not worked on it in a while, but I would be happy to share the information. I am wondering if the OS X MacIntel machines are using the A and D register to move the data to the PCI bus. I found example code for the AC97 driver for the Intel version of Darwin. In the code as I followed it along, there was a segment of code that was embedded machine code in the C code. When I broke it down, it was the routine that was pushing the data to the PCI bus using the the Address (A) and Data (D) registers of the Intel Processor. I could not figure out how this translated to the PowerPC, and no one was willing to tell me. One of the big problems with trying to incorporate the accelerated audio cards (Live, Audigy (and up)) is that core audio does not have anywhere to hook into the framework to force the audio to be rendered on the card and not the CPU. They did not want to help either. You may have to come up with your own audio system that bypasses or even removes core audio. If you can get the basic data passing working, I think I have all of the registers mapped to get the basic audio functions working.

 

I have the linux code that was used. I believe a lot of it could be used. There are two sections of this project that were going to be a pain in the ass. Based on the information, you would build a lower level BSD type code that you could use pieces of the linux code for. It was easy to see what you would need to implement (I Think). The problem spots I had were figuring out how to implement the passing of the data to the PCI bus. None of the documentation I had told you this and Apple would not tell me. Someone with the premiere Developer Status might have the documentation, or it might be really obvious to anyone who has written a PCI driver on Mac before. You are going to need this documentation to get going, and you will need to modify the linux code routines to work with this. I think trying to directly cut and paste all of the linux code would be a huge mistake. It should be built cleanly from the ground up since this will be the framework. Once you have this BSD level linux piece to directly interface with the hardware, you will have to figure out this NIB thing. Basically, you have to create a connector through the layers of OS X (correctly) to present the upper GUI part with the connects for the volume sliders - etc. The upper level GUI stuff was easy. In fact, I pretty much had it completed a couple of times (roughed in), and it was a matter of assigning the nibs to the correct interface device. They will also have to figure out a way to control the sleep functions. On the PowerPC units, Apple just cuts the power to the bus. It does not use the other power states. Now for something like a sound card, this presents a problem because you will have to write all of the states of the registers from the lower BSD layer to a temp location, and then let the system power down the card. When the power up routine calls your set of code for wake up, you need to restore all of the register data to it's original state, and return your wake routing to the rest of the power up state. This did not look too tricky, just a little intensive. I am not sure what they are doing with the MacIntel machines.

 

Now, Lets COLLABORATE! :gathering:

 

Update: Research Information and Tutorials: Mac Kx Project.zip

 

UPDATE: WE NEED CODERS!

Edited by REVENGE
Link to comment
Share on other sites

  • 1 month later...
  • 1 month later...
  • 4 months later...

i just looked into this, its seems the problem is that alot of core audio is hard to find documentation for?

 

would be great to get working tho, for use with audio apps

 

the card is actually quite powerful ( judging by results on windows kx driver)

Link to comment
Share on other sites

Apologies node64, but as of right now this project is dead in the water at least in this community. I am unable to find and/or contact any coders willing to collaborate with Brian. You're correct though, creating a driver to work with CoreAudio is not going to be possible right now apparently. Brian has said that if you want to get it working, you'll have to bypass CoreAudio and directly access the card via pci bus.

Link to comment
Share on other sites

  • 6 months later...
  • 4 weeks later...

I'd be down to help out. As a senior CS student you'd think i'd be an awesome coder but honestly it all goes gray between projects and I haven't had a true coding project since this time last year. I know c++ and ASM but don't know any thing about the apple or linux apis. So if someone else gets the documentation and the basic and I could monkey out some code. I don't really have a lot of free time but still can help.

 

I have an Audigy ZS 2 that I wouldn't mind having support for. I actually just took a glance at the emu10k1 ALSA code and then found this thread. I'm not sure if my card is actually compatible though. The alsa site says it has an emu10k2 but points to the emu10k1 code, so maybe it's backwards compatible. I don't care about hardware acceleration. It's pretty futile these days just to listen to some iTunes. I just want multi port so I can have my spdif speakers on one port and my headphones on another to switch back and forth with.

Link to comment
Share on other sites

REVENGE is it possible to reanimate this project? Cause I've done initialization of chip myself, but for the next step I need help .

 

Daemon, what do you need in order to continue? Have you examined the information Brian has at his website yet?

 

And Bcas, do you have any low level driver coding experience?

 

If you guys really think you can make some progress, I'll be sure to set up an X-Labs development forum. This could solve major headaches for many Creative users.

Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...
  • 1 month later...
  • 11 months later...
 Share

×
×
  • Create New...