Adobe Is Making Some Noise Part 1
If you have been following the community there has been quite a stir around lack of sound features in the Flash Player. Not only lack of sound features, but the last two dot releases have injected serious bugs in the sound support. This is unfortunate and some of these are squarely my fault, but some of them are design choices for which there are no workarounds.
The big controversy has been around the SOUND_COMPLETE event which has become less predictable. There is a change I had to make for Windows Vista to fix an audio-video synchronization issue. Windows Vista uses a new audio stack and does support the older but still viable WaveOut API through an emulation layer. This emulation layer does not behave exactly like previous iterations of Windows and exposed some bad assumptions the Flash Player made to drive audio-video synchronization and the famous the SOUND_COMPLETE event.
To be clear: the accuracy of SOUND_COMPLETE will get even worse in Flash Player 10. Here, I said it. Why? Because the world moves on and power consumption of devices becomes more important than ever, even for desktops. One of the stumbling blocks of improving power consumption on Windows was the Flash Player and we've gotten an earful from Microsoft and Intel because of it. The key part here was a Win32 API we used which is timeBeginPeriod()/timeEndPeriod(). We were setting the period to 1ms so that events like SOUND_COMPLETE would be more accurate, dispatched at the right time. This worked on Win98 through WinXP but is essentially useless on Windows Vista since the sound stack works in a different way as I mentioned above. So apart from being useless on Vista using this API is deadly for power consumption and a show case of bad engineering. We can not continue to rely on it.
So what does that mean? You should have never relied on SOUND_COMPLETE in the first place to do sound processing. Easy for me to say, but Macromedia did miss putting a big warning into the documentation. Or maybe the real problem was that no one really paid attention to the sound stack for such a long time. I am trying to change this, unfortunately in the process causing havoc for some clients and breaking backwards compatibility.
Continue to read Part 2 to see how we will address the requests from the community in Flash Player 10.
The big controversy has been around the SOUND_COMPLETE event which has become less predictable. There is a change I had to make for Windows Vista to fix an audio-video synchronization issue. Windows Vista uses a new audio stack and does support the older but still viable WaveOut API through an emulation layer. This emulation layer does not behave exactly like previous iterations of Windows and exposed some bad assumptions the Flash Player made to drive audio-video synchronization and the famous the SOUND_COMPLETE event.
To be clear: the accuracy of SOUND_COMPLETE will get even worse in Flash Player 10. Here, I said it. Why? Because the world moves on and power consumption of devices becomes more important than ever, even for desktops. One of the stumbling blocks of improving power consumption on Windows was the Flash Player and we've gotten an earful from Microsoft and Intel because of it. The key part here was a Win32 API we used which is timeBeginPeriod()/timeEndPeriod(). We were setting the period to 1ms so that events like SOUND_COMPLETE would be more accurate, dispatched at the right time. This worked on Win98 through WinXP but is essentially useless on Windows Vista since the sound stack works in a different way as I mentioned above. So apart from being useless on Vista using this API is deadly for power consumption and a show case of bad engineering. We can not continue to rely on it.
So what does that mean? You should have never relied on SOUND_COMPLETE in the first place to do sound processing. Easy for me to say, but Macromedia did miss putting a big warning into the documentation. Or maybe the real problem was that no one really paid attention to the sound stack for such a long time. I am trying to change this, unfortunately in the process causing havoc for some clients and breaking backwards compatibility.
Continue to read Part 2 to see how we will address the requests from the community in Flash Player 10.
posted by Tinic Uro at 11:00 PM
4 Comments:
boo
Hello,
I am in this issue for quite some time. I think Macromedia, but ALSO Adobe, should have been open about the minimal audio sync/sequence possibilities of Flash and the fact that onSoundComplete should not be used as a solution for this. Please also look at http://www.actionscript.org/forums/showthread.php3?t=146032
Hello,
I am in this issue for quite some time. I think Macromedia, but ALSO Adobe, should have been open about the minimal audio sync/sequence possibilities of Flash and the fact that onSoundComplete should not be used as a solution for this. Please also look at http://www.actionscript.org/forums/showthread.php3?t=146032
I'm sorry, but the choice to break the audio playback and blame the users for not knowing better than to use documented class events is pure hubris.
It is not just the SOUND_COMPLETE event that broke when this change was made, you have introduced serious errors into the playback of audio files that are not 44.1kHz (see the public bugbase).
And to tell us that it's only going to get worse is just rubbing salt in our wounds. At least try to be helpful. Tell us how to get needed functionality back if you're going to take away some of the features that we've relied on for more than 5 years.
This is extremely painful for those of us doing Flash development. You should understand that the decision you've made is costing us dearly with our clients.
Post a Comment
<< Home