Firefox sound vs sound reasoning.
Regarding my experiments with generated sound in JavaScript, I'm officially declaring them a failure, at least for now. HTML5 still seems like a good platform for programming simple games, but I'll be using an embedded Java applet for sound. (Of course, if I'm going to do that, I might as well just abandon HTML5 entirely and program the whole thing in Java, right?)
Mozilla's Audio Data API, in addition to being proprietary (which I actually don't mind), is also not working correctly in current Firefox versions (it actually never worked the way I wanted it to), and it's apparently also already deprecated, despite not having anything good to replace it with yet!
(There is, apparently, a new standard that they're supposedly considering; I even found the specs for it, but the whole thing reads like the ramblings of an Eastern European mental patient who's halfway through his first month of an "English as a third language for mental patients" night school course. My rule is: If I don't understand it, I'm not using it!)
---
During my experiments, I began thinking up a list of criteria for what I would consider a good sound API:
In its simplest, most ideal form, sound programming should be just as simple as selecting a sampling rate, then writing samples to a buffer. If the buffer's empty, the first sample written goes straight to the output; otherwise it remains there until 1/samprate seconds has passed since the last output.
One other thing is necessary, though: A way to determine how many samples are still in the buffer. We'd mainly use this information to calculate when it's necessary to write more samples. (And it's important to note that the Audio Data API in FF does not provide this function at all. This is the primary reason why that API fails so hard. At least we're given a mozGetCurrentSampleOffset() function, which queries how many samples have been played so far, but this is much less useful, and also hasn't worked properly - at least on my computers - since FF15!)
Now, in all practicality, we have to allow for the possibility that hardware and/or driver limitations might not allow us to make things as simple as this. There may be a minimum number of samples that needs to be in the buffer before anything plays, and/or a requirement that samples be written in blocks of a certain size. There must therefore be easy ways to determine whether or not these limitations exist. (Even though, in my opinion, they never should. At the very least, the underlying OS/platform should do its best to shield us from these surprises. That's another of my rules of programming: Anything surprising is bad!)
Optional but useful: A way to query how many samples can be written to the buffer before blocking occurs and/or samples get discarded. And, of course, pause/unpause/clear functions.
With these criteria in mind, a functional API pretty much designs itself. Still, I'll consider typing up a detailed specification later, if anyone seems interested in it. (Even though I don't expect much to come of it!)
(In Firefox's defense, it's possible to do some nifty things with the sound functions provided; it just can't be used adequately for games or any application where one needs to minimize lag.)
Mozilla's Audio Data API, in addition to being proprietary (which I actually don't mind), is also not working correctly in current Firefox versions (it actually never worked the way I wanted it to), and it's apparently also already deprecated, despite not having anything good to replace it with yet!
(There is, apparently, a new standard that they're supposedly considering; I even found the specs for it, but the whole thing reads like the ramblings of an Eastern European mental patient who's halfway through his first month of an "English as a third language for mental patients" night school course. My rule is: If I don't understand it, I'm not using it!)
---
During my experiments, I began thinking up a list of criteria for what I would consider a good sound API:
In its simplest, most ideal form, sound programming should be just as simple as selecting a sampling rate, then writing samples to a buffer. If the buffer's empty, the first sample written goes straight to the output; otherwise it remains there until 1/samprate seconds has passed since the last output.
One other thing is necessary, though: A way to determine how many samples are still in the buffer. We'd mainly use this information to calculate when it's necessary to write more samples. (And it's important to note that the Audio Data API in FF does not provide this function at all. This is the primary reason why that API fails so hard. At least we're given a mozGetCurrentSampleOffset() function, which queries how many samples have been played so far, but this is much less useful, and also hasn't worked properly - at least on my computers - since FF15!)
Now, in all practicality, we have to allow for the possibility that hardware and/or driver limitations might not allow us to make things as simple as this. There may be a minimum number of samples that needs to be in the buffer before anything plays, and/or a requirement that samples be written in blocks of a certain size. There must therefore be easy ways to determine whether or not these limitations exist. (Even though, in my opinion, they never should. At the very least, the underlying OS/platform should do its best to shield us from these surprises. That's another of my rules of programming: Anything surprising is bad!)
Optional but useful: A way to query how many samples can be written to the buffer before blocking occurs and/or samples get discarded. And, of course, pause/unpause/clear functions.
With these criteria in mind, a functional API pretty much designs itself. Still, I'll consider typing up a detailed specification later, if anyone seems interested in it. (Even though I don't expect much to come of it!)
(In Firefox's defense, it's possible to do some nifty things with the sound functions provided; it just can't be used adequately for games or any application where one needs to minimize lag.)