Jump to content
696 posts in this topic

Recommended Posts

thnx for keeping us guys updated :- ))

 

sound is not the most important thing in the world, but it would be really nice to see it working one day (its the last non working thing on my laptop (5024wlmi) beside wifi, but that shouldnt be hard to fix ->because i know what the problem is..)

  • 2 weeks later...

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.

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.

 

 

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.

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.

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.

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 :gun: 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.

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-m32r.org/lxr/http/source/sound/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.

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.

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.

AppleAC97AudioATIIXP.cpp.txt

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.

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.

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.

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.

Guest
This topic is now closed to further replies.
×
×
  • Create New...