Yes, audio is a bit of a special case, because when the audio hardware needs data, it needs data NOW! That means that the audio thread has to get time from the scheduler and it cant block on some synchronization primative before it completes its job. You can solve that problem using large buffers so that there is plenty of time to prepare the next one before running out. Unfortunately, if you want low latencies, (who wouldn't for a game!) then you cant do that. A good alternative is to instead have "asymmetric multithreading" such that when the audio hardware needs data, it gets unobstructed processor time, on demand, regardless of what is currently occupying the processor.
Asymmetric multithreading (or interrupt level tasks) require a special set of data synchronization primatives. The normal semaphore/mutex will generally cause the high priority thread to block until the low priority one exits a critical region. That is not what you want. You want the audio thread to push through and make the low priority thread move out of the way. Fortunately, atomic operations have this behavior. Making proper use of these tools can be a bit tricky and usually requires that you keep your API simple and straightforward. The current Alsource queue/unqueue is a little bit too complex to do easily with atomic operations. It would be better for this purpose if it was a simple queue (with callbacks, of course!).
I must admit I am a little suprised to see my maccentral post here. I have written quite a bit about OpenAL in the past. This particular one was in response to a user curious whether Apple would adopt OpenAL. Often I take the time to commend the hard work going on at Creative and elsewhere. I regret that I did not say enough positive things about OpenAL or the heroes who keep it alive this time. With that in mind, let me stress...
I dont think OpenAL sucks! I think it is the best cross platform 3D audio API available. It also could be a lot better. I feel about OpenAL in much the same way one might feel about your best friend on learning he has acquired a drug habit -- often frustrated, sometimes confused and always deeply concerned.
Let me address a couple of comments:
You have to realize the reason he doesn't like the API requiring preemptive multitasking is that the "classic" MacOS doesn't have it.
This is not a religious issue. It is something else. The crux of both my OpenGL arguments and the PMT one arises from the fact that sound is necessarily an asynchronous medium. In video, you can afford to drop a frame or two, since the last one you completed will be fine until you complete the next one. Video works fine, even best, with a synchronous API.
Unfortunately, you cant afford to drop any frames in sound at all! For this reason, enforcing a synchronous API onto an audio library makes no sense to me. That is why I criticised modelling it after OpenGL. It is also why I brought up the PMT issue, because only with symmetric multithreading can you write a synchronous audio API and hope to get away with it. However, if you would like to have low audio latencies, as you would in a game, you should not do that. The audio processor thread should not block on anything other than the audio hardware readiness for the next buffer.
If you get rid of the current polling mechanism for removing blocks from the queue (polling is rarely a good idea on any OS) and instead use completion callbacks, then it works everywhere, PMT or no, as an asynchronous API. Even better, you can use the completion callbacks to precisely time audio events (e.g. volume changes) in the future without having to worry about polling at just the right time. This is because the callbacks occur sychronously relative to the important thread, the audio processor thread. The queue could also benefit from being able to queue delays as well.
Timing is critical in any sound API - OpenAL works fine.... there is nothing stopping you from writing a MOD player using OpenAL.
OpenAL works fine for games, where the timing for sounds is not critical, as they dont have to be synchronized with each other. However there is no provision in the API whatsoever to control the timing of when sounds play. There is no latency information available. You do not know when sounds queued will actually start to play. There is no way (such as in Quicktime) to coordinate two different sound sources to make sure they start at precisely the same time. For this reason, though you could write a "MOD player" in OpenAL, it wouldn't be a very good one. There is nothing to keep instruments from playing at the wrong time.
Maybe the key difference is that OpenAL does not give a mechanism to stream data into a buffer object, choosing instead to allow the programmer to queue buffers for sources.
At one point, it did. There is or was a LOKI streaming buffer extension. It was deprecated because the whole concept of a streaming buffer is an oxymoron. That was the right thing to do. The queue that replaces it is fine too. It just needs to do more than just accept buffers. The un-queue is bizarre.
Yes and no. When programming for Carbon (the old MacOS API's) you will probably never call a unix API at all on OS X, except maybe C Std Lib stuff, which may loosely qualify if you are generous. Since most MacOS users are still on OS 9 and not X, that is the current reality for Mac games.
In the future, game programmers will write for OS X only. In that case, the suite of API's that will be most touched will be OpenGL, sockets, pthreads, CoreGraphics (Apple's proprietary API for resolution switching and graphics), CoreAudio (Apple's currently closed source very low latency audio API), and HID (Apple's API for gathering device input.) Notice that not all of these are supported on linux, just the first three. All of the low level graphics config, input and sound will have to be rewritten for that platform.
OpenAL might solve the CoreAudio dilemma -- if there was an OS X implementation, and it doesn't die on the vine now that Loki is out of the picture. I dont know of a good solution for the other two. Maybe Simple Direct Media Layer? It needs to "just work" whatever it is.
This may be a call to arms to get Linux to be a bit more standards compliant.;-)
Gee, my G4/400 seems pretty fast when running OS X. I have no complaints about it speedwise. Certainly resizing a window is not as slow as you make it out to be. Its a little bit jerky, but I think that is more a function of adjusting the layout to accommodate the new size of the window each time.
Finally, I look forward to a time when *all* of the video rendering can be offloaded onto the video card, through something like OpenGL or perhaps a more flexible video language. If you had any real experience programming video intensive operations on PowerPC, you would know that the main problem with doing anything quickly is the speed of the PCI/AGP bus. It is between 10-1000 times slower than the CPU depending on how you want to benchmark the CPU. Sending only high level video instructions to the card is a way to make the most of your limited bandwidth. This is a fact that I think that games like Quake have illustrated beautifully to everyone's satisfaction for years now.
Wouldn't it be nice if all of your GUI elements could be rendered that nicely in real time?
Ian Ollmann
The only thing I learned from LinuxPPC is that it performed poorly and the gui was unstable. I was better off with pre-release versions of BeOS. The MacOS GUI was more stable even without protected memory.
Frankly, I have a feeling that no Apple fan outside of those that work at 1 infinite loop care one bit what kernel it uses, just so long as it works, and does everything you want it to do. If Apple feels it needs a Microkernel to keep the OS flexible and portable, then fine. Heck, we used to have a nanokernel. Some might call that a step up!;-)
The lawyers seem to think its legal, otherwise they wouldn't do it -- they could be disbarred. However, to the average lay person, such as myself, it sure seems a lot like extortion. I suppose it has to be allowed. Otherwise, without the option of a cease & desist letter, people with legitimate complaints would have no simple recourse that did not involve a court case.
Ian
The AltiVec unit requires a couple of things that you dont have to deal with in normal code. The data has to be nicely laid out all in one place, and you have to be willing/able to deal with it more than one element at a time. Most programs are not designed that way (or if they are it is only by chance) so usually it is hard at first to find ways to retrofit Altivec into existing code.
Certain trends in programming (e.g. OOP) make it even less likely that you will see these kinds of data structures. So to make a long story short, to get pervasive use of AltiVec, you have to design around it. I cant speak about the Quake engine, but from John's comments that sounds a little bit like part of the problem.
This is not to say that AltiVec is useless for such apps. AltiVec more often than not just so happens to be very good at accelerating that 10% of the code that consumes 90% of the CPU time. So, a little bit of work often goes a long way.
What you learn working with it is that memory bandwidth is almost always the problem. The result is that certain common old-gen programming techniques for code optimization that rely on memory access to save CPU time (longer code, lookup tables, etc.) are about the last thing you would want to do with AltiVec. You only unroll loops as much as is necessary to get proper scheduling and stop there, for example. Almost everything, including constants are best calculated on the fly rather than loaded from memory. As John points out, you are better off with one big complicated function rather than a lot of simple ones. Accessing memory is so expensive that once you have the data you had better do a lot with it. You typically have about 30-40 cycles of time per 32 byte block of memory that is "spent for you" every time you load memory. If you dont do something worthwhile during that time, it is your loss.
AltiVec is also good for sound code. It is a great way to reduce the overhead associated with single sound channels so that you can have lots playing concurrently without having time spent at interrupt running amok.
Slashdot Mirror
Yes, audio is a bit of a special case, because when the audio hardware needs data, it needs data NOW! That means that the audio thread has to get time from the scheduler and it cant block on some synchronization primative before it completes its job. You can solve that problem using large buffers so that there is plenty of time to prepare the next one before running out. Unfortunately, if you want low latencies, (who wouldn't for a game!) then you cant do that. A good alternative is to instead have "asymmetric multithreading" such that when the audio hardware needs data, it gets unobstructed processor time, on demand, regardless of what is currently occupying the processor.
Asymmetric multithreading (or interrupt level tasks) require a special set of data synchronization primatives. The normal semaphore/mutex will generally cause the high priority thread to block until the low priority one exits a critical region. That is not what you want. You want the audio thread to push through and make the low priority thread move out of the way. Fortunately, atomic operations have this behavior. Making proper use of these tools can be a bit tricky and usually requires that you keep your API simple and straightforward. The current Alsource queue/unqueue is a little bit too complex to do easily with atomic operations. It would be better for this purpose if it was a simple queue (with callbacks, of course!).
I dont think OpenAL sucks! I think it is the best cross platform 3D audio API available. It also could be a lot better. I feel about OpenAL in much the same way one might feel about your best friend on learning he has acquired a drug habit -- often frustrated, sometimes confused and always deeply concerned.
Let me address a couple of comments:
This is not a religious issue. It is something else. The crux of both my OpenGL arguments and the PMT one arises from the fact that sound is necessarily an asynchronous medium. In video, you can afford to drop a frame or two, since the last one you completed will be fine until you complete the next one. Video works fine, even best, with a synchronous API.
Unfortunately, you cant afford to drop any frames in sound at all! For this reason, enforcing a synchronous API onto an audio library makes no sense to me. That is why I criticised modelling it after OpenGL. It is also why I brought up the PMT issue, because only with symmetric multithreading can you write a synchronous audio API and hope to get away with it. However, if you would like to have low audio latencies, as you would in a game, you should not do that. The audio processor thread should not block on anything other than the audio hardware readiness for the next buffer.
If you get rid of the current polling mechanism for removing blocks from the queue (polling is rarely a good idea on any OS) and instead use completion callbacks, then it works everywhere, PMT or no, as an asynchronous API. Even better, you can use the completion callbacks to precisely time audio events (e.g. volume changes) in the future without having to worry about polling at just the right time. This is because the callbacks occur sychronously relative to the important thread, the audio processor thread. The queue could also benefit from being able to queue delays as well.
OpenAL works fine for games, where the timing for sounds is not critical, as they dont have to be synchronized with each other. However there is no provision in the API whatsoever to control the timing of when sounds play. There is no latency information available. You do not know when sounds queued will actually start to play. There is no way (such as in Quicktime) to coordinate two different sound sources to make sure they start at precisely the same time. For this reason, though you could write a "MOD player" in OpenAL, it wouldn't be a very good one. There is nothing to keep instruments from playing at the wrong time.
At one point, it did. There is or was a LOKI streaming buffer extension. It was deprecated because the whole concept of a streaming buffer is an oxymoron. That was the right thing to do. The queue that replaces it is fine too. It just needs to do more than just accept buffers. The un-queue is bizarre.
--Ian
Yes and no. When programming for Carbon (the old MacOS API's) you will probably never call a unix API at all on OS X, except maybe C Std Lib stuff, which may loosely qualify if you are generous. Since most MacOS users are still on OS 9 and not X, that is the current reality for Mac games.
In the future, game programmers will write for OS X only. In that case, the suite of API's that will be most touched will be OpenGL, sockets, pthreads, CoreGraphics (Apple's proprietary API for resolution switching and graphics), CoreAudio (Apple's currently closed source very low latency audio API), and HID (Apple's API for gathering device input.) Notice that not all of these are supported on linux, just the first three. All of the low level graphics config, input and sound will have to be rewritten for that platform.
OpenAL might solve the CoreAudio dilemma -- if there was an OS X implementation, and it doesn't die on the vine now that Loki is out of the picture. I dont know of a good solution for the other two. Maybe Simple Direct Media Layer? It needs to "just work" whatever it is.
This may be a call to arms to get Linux to be a bit more standards compliant.
Ian Ollmann
Gee, my G4/400 seems pretty fast when running OS X. I have no complaints about it speedwise. Certainly resizing a window is not as slow as you make it out to be. Its a little bit jerky, but I think that is more a function of adjusting the layout to accommodate the new size of the window each time. Finally, I look forward to a time when *all* of the video rendering can be offloaded onto the video card, through something like OpenGL or perhaps a more flexible video language. If you had any real experience programming video intensive operations on PowerPC, you would know that the main problem with doing anything quickly is the speed of the PCI/AGP bus. It is between 10-1000 times slower than the CPU depending on how you want to benchmark the CPU. Sending only high level video instructions to the card is a way to make the most of your limited bandwidth. This is a fact that I think that games like Quake have illustrated beautifully to everyone's satisfaction for years now. Wouldn't it be nice if all of your GUI elements could be rendered that nicely in real time? Ian Ollmann
That is precisely the sort of elitism that has prevented linux from becomming a mainstream dekstop OS.
The only thing I learned from LinuxPPC is that it performed poorly and the gui was unstable. I was better off with pre-release versions of BeOS. The MacOS GUI was more stable even without protected memory. Frankly, I have a feeling that no Apple fan outside of those that work at 1 infinite loop care one bit what kernel it uses, just so long as it works, and does everything you want it to do. If Apple feels it needs a Microkernel to keep the OS flexible and portable, then fine. Heck, we used to have a nanokernel. Some might call that a step up! ;-)
The lawyers seem to think its legal, otherwise they wouldn't do it -- they could be disbarred. However, to the average lay person, such as myself, it sure seems a lot like extortion. I suppose it has to be allowed. Otherwise, without the option of a cease & desist letter, people with legitimate complaints would have no simple recourse that did not involve a court case. Ian
The AltiVec unit requires a couple of things that you dont have to deal with in normal code. The data has to be nicely laid out all in one place, and you have to be willing/able to deal with it more than one element at a time. Most programs are not designed that way (or if they are it is only by chance) so usually it is hard at first to find ways to retrofit Altivec into existing code. Certain trends in programming (e.g. OOP) make it even less likely that you will see these kinds of data structures. So to make a long story short, to get pervasive use of AltiVec, you have to design around it. I cant speak about the Quake engine, but from John's comments that sounds a little bit like part of the problem.
This is not to say that AltiVec is useless for such apps. AltiVec more often than not just so happens to be very good at accelerating that 10% of the code that consumes 90% of the CPU time. So, a little bit of work often goes a long way.
What you learn working with it is that memory bandwidth is almost always the problem. The result is that certain common old-gen programming techniques for code optimization that rely on memory access to save CPU time (longer code, lookup tables, etc.) are about the last thing you would want to do with AltiVec. You only unroll loops as much as is necessary to get proper scheduling and stop there, for example. Almost everything, including constants are best calculated on the fly rather than loaded from memory. As John points out, you are better off with one big complicated function rather than a lot of simple ones. Accessing memory is so expensive that once you have the data you had better do a lot with it. You typically have about 30-40 cycles of time per 32 byte block of memory that is "spent for you" every time you load memory. If you dont do something worthwhile during that time, it is your loss.
AltiVec is also good for sound code. It is a great way to reduce the overhead associated with single sound channels so that you can have lots playing concurrently without having time spent at interrupt running amok.