695 replies to this topic

[EdFlyer]

thedopefishlives, on May 11 2006, 07:12 PM, said:

I took a look at the source, but I can't make enough of a correlation between it and the Linux kernel source to quite follow what your driver is actually doing.  It'll take me a few days to get up to speed, but I should be able to help out eventually.

Thanks man, any help is great. As it is, I'll be getting the new laptop in about a week, its in the mail now, so I'll hopefully be able to devote some more time to this.

greggh, on May 11 2006, 09:22 PM, said:

I have an ATI SB400 board in my new laptop.  It came with realtek drivers for the ac97 (Realtek HD.)  Is this going to be the same chipset you are trying to support?  I am willing to test anything.

If the device driver for your sound uses the id 1002 4370 then yeah this driver should support it, if not, check to see if your device driver is already supported by a driver on this website.

Yeah, so that's the latest news for now.

[mito_pm]

Hi, i'm having problems with that sound card.

Well, I really want to help, but my knowledge of drivers is almost null.

I'm learning C++, but I need much more than that.

Could you give me please a link or the topics that I should learn to help on this driver?

I hope you understand what I wrote, i'm from Chile.

Thanks.

[EdFlyer]

apple's developer website has stuff on iokit you can read that.

the big thing with this driver is to study the linux code and figure out how it works, then to study the mac os x code for other drivers and see how they work, compare them, and then come up with something that works for this sound driver.

thanks for the help though, there's some source code posted earlier in the thread with some instructions on how to start with hit.

[mito_pm]

Ok, thanks.
I know C and some C++, Unix commands and Linux. But i'm not an expert

Well, let's see if in a couple of weeks i can do something.

[thedopefishlives]

The lucky thing is that I've been overwhelmed with Linux kernel details due to my OS project coming due, so at least I can take one look at the Linux atiixp.c file and instinctively know how it works Finals are next week for me, I should have some time in between exams to make an effort to understand the Mach kernel driver system.

[greggh]

Is this going to be the same as the SB450's built in?  On linux I use the hda-intel driver for it.

[EdFlyer]

If you use the intel hda audio in linux u'll probably use the AppleAzalia stuff, look around on the forum for that.

This driver is for device id 1002 (ati) 4370 Amc Conexant AC-link audio.

[Peter Gammelgaard]

Good that this project is not dead..

Keep up the good work Edflyer..

[EdFlyer]

for those looking at the source, in the file AppleAC97AudioATIIXP in the function IOByteCount CLASS:getDMAEngineHardwarePointer( IOAC97EngineID engine ) it is supposed to return the position, but it isn't, so that needs to be calculated..........then that will be at least one bug removed from the code. I am going to check the lniux source to see how it handles that, if it does. If anyone comes up with a solution, please post it.

Lines 631-653 seem to be the relevant lines. From http://www.linux-m32...nd/pci/atiixp.c

But i'm not sure how to translate it as of yet, so if anyone can take a look and see what's up that would be nice.

[thedopefishlives]

I'll get that done I don't have anything better to do today, so I should have a patch rolled out by tonight.

[EdFlyer]

thanks, just double check its the same idea in the code. It looks to be the same, based off the comments.

[thedopefishlives]

It's the same idea, but something interesting is happening.  I put in the linux-style timeout code with the while loop, and for some reason, yours is timing out.  That is, it never appears to read a "correct" value.  I think this might be the cause of the DMA engine looping problem, if you care to look into it further.

[EdFlyer]

I was figuring they are related, can you send me the code u changed so I can integrate it into my code and go from there? Thanks.

[thedopefishlives]

Here's the modified .cpp file.  I went from scousi's latest upload.

Attached Files

•  AppleAC97AudioATIIXP.cpp.txt   55.55K   90 downloads

[EdFlyer]

does your volume slider show up with your version of the code? just wondering, cause I have a version of the code that does, but its slightly different code.

yeah, in corporated your code into mine, but it still loops inifinitely. At least we are a little closer than before.

Attached Files

•  AppleAC97AudioATIIXP.cpp.txt   61.58K   102 downloads

[thedopefishlives]

I believe it does, but if it doesn't, no matter.  I am curious, Ed, as to how Apple's drivers handle interrupts.  In particular, I am not so certain that the driver is triggering the interrupt at the end of DMA transfer, which would stop the DMA engine.  I'd like to throw in some debug statements to see if the interrupt executes, but I'm not sure I can find the right spot.

[scousi]

thedopefishlives, on May 15 2006, 02:40 PM, said:

I believe it does, but if it doesn't, no matter.  I am curious, Ed, as to how Apple's drivers handle interrupts.  In particular, I am not so certain that the driver is triggering the interrupt at the end of DMA transfer, which would stop the DMA engine.  I'd like to throw in some debug statements to see if the interrupt executes, but I'm not sure I can find the right spot.

You don't really need an interrupt. The chip is just supposed to loop whatever you inserft in the DMA. Apple's audio implementation needs the HW pointer of the where the CODEC is at so it can make deterministic predictions. That's where I was getting some problems. When I read this IO position, it never changes.

I don't know if you have the latest lastest code I have but I had managed to clean up some of the IO mappings  at the time I was working on the driver. I'm pretty sure that I have the DMA mappings structured correcly. I also had asked ATI for a data sheet but they never even responded.  

Be carefull with the IOLOG. It doesn't seem to print everything. You can't really rely on it.

You might want to stub the getDMAEngineHardwarePointer function and return an incremental value instead of actually reading the chip pointer to see how differently the driver behaves. I suspect that the driver doesn't work because it's not getting moving position. If you fake it , you will at least see how differently the dirver behaves.

Hopefully, I will be able to continue working on it soon.

Good luck.

[Elv13]

is it possible to post the lastest full source and the compilled .kext (for fun or hex hacking)
and is IXP 150 will be suported? (atiixp module in linux kernel)

[EdFlyer]

so far what is supported is the ati ixp sound 1002 4370, if it responds to this device id it would work, we are using the atiixp.c in linux/bsd as our base of idea for code, so it is very possible that it may work, once we have it working it can be tested to see if its compatible with others.

[thedopefishlives]

scousi, on May 15 2006, 07:36 PM, said:

You don't really need an interrupt. The chip is just supposed to loop whatever you inserft in the DMA. Apple's audio implementation needs the HW pointer of the where the CODEC is at so it can make deterministic predictions. That's where I was getting some problems. When I read this IO position, it never changes.

I don't know if you have the latest lastest code I have but I had managed to clean up some of the IO mappings  at the time I was working on the driver. I'm pretty sure that I have the DMA mappings structured correcly. I also had asked ATI for a data sheet but they never even responded.  

Be carefull with the IOLOG. It doesn't seem to print everything. You can't really rely on it.

You might want to stub the getDMAEngineHardwarePointer function and return an incremental value instead of actually reading the chip pointer to see how differently the driver behaves. I suspect that the driver doesn't work because it's not getting moving position. If you fake it , you will at least see how differently the dirver behaves.

Hopefully, I will be able to continue working on it soon.

Good luck.

Ahhhh, okay.  I've worked with a lot of hardware, but sound cards are the one thing I haven't messed with in driver terms.  It makes sense now why the interrupt wasn't firing - it doesn't have to.  So it does indeed appear to be in the getDMAEngineHardwarePointer function.  I just don't understand why the hardware pointer doesn't appear to be incrementing.  I'll keep poking around the Linux source and let you guys know if there's anything of import that we missed.