I'll answer your questions backwards with more information than you'd ever care to know.
There are 2 types of sounds in a SWF (not counting Flash Lite's device sounds): Event and Streaming. Event sounds are not tied to the frame based engine of Flash. Therefore, they will play indenpendently of the Flash Player's frame rendering. Meaning, if you play your SWF on a slow system, Flash Player may drop (visual) frames to compensate, much like digital video does, but the sound will not stop, nor be re-synced. If you click a button, and expect it to play a sound, you really don't care if it's synced, so for this it works well. However, for eLearning (SWF's produced from Captivate (formerly RoboDemo)) and other voice over scenairos (or actual animation movies), it is integral that the sound be synced with visuals. I'm sure you may have seen some DVD's accidentally do this where the audio gets out of sync. This is unacceptable, and for this, Flash has Streaming sounds. They are called streams because they are embedded with Flash's frames, and since SWF's stream their frames down so you can immediately start playing them even if they haven't finished loading, so to must the entire sound... so it streams, whereas event sounds must be downloaded in their entirety (pretty sure about that last point). However, the only way to create Streaming sounds is using Flash. If you want to sync voice overs to presentations, you're only alternative is Captivate for Breeze. I'm not sure how Captivate makes its SWF's; if you import a CP file into Flash, they use event sounds which boggles my mind, because every Captivate SWF I've ever used syncs perfectly, which leads me believe they have code in there ensuring your Captivate SWF's sync to your audio. In essence, they coded their own timer engine to compensate (but I really really think they are using streaming sounds, it's just the Flash MX 2004 import messes up). So, that's the code scenario. I think Breeze, since it's recording an FLV, is just recording the events, like "your power point slide changed", so when you play it back, that event fires at the appropriate time since it's embedded in the FLV. That's another example. Now, to answer your question, I'd use a Remote Shared Library in your case. Compile all of your sounds into a seperate SWF; like a DLL. This SWF will be included at runtime, and added to the total SWF's preload time, so even if your final app is only 180k, the sounds SWF file size will have to be downloaded fully before you can even use 1 sound. I'm sure in your case, though, that's ok. attachSound really means, "Hey sound object, when you run your start method, please play this resource." The string parameter you pass into attachSound is just the linkaegID/resource name of the sound embedded in your Flex APP/SWF (in this case in a remote shared library SWF). That reminds me, can't remember if an RSL can have it's sounds used... I think it can.. hrm. Anyway, yeah, for you, attachSound is the way to go. If you need to play another sound, either call attachSound again, OR make a new sound object. You can only, currently, play 8 sounds at once in Flash. If the RSL solution doesn't work with 2 sounds as a test, then loadSound I guess would be ok. It'd be latent the first time you called it since the sound isn't cached on the user's cache, but the 2nd time it it would be... or you could just preload them. ----- Original Message ----- From: "Tom Fitzpatrick" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, July 28, 2005 5:31 PM Subject: [flexcoders] attachSound vs. loadSound (was: onSoundComplete) At 05:13 PM 7/28/2005, you wrote: >attachSound I reckon has less overhead because the sound and header are >already embedded in the SWF. Additionally, attachSound is a syncronous >opertion, where as loadSound, both streaming and non, is asyncronous. > >attachSound requires a sound asset be embeded in your SWF, increasing >compile time, final SWF size, and loading overhead. As such, the sound is >immediaetly available first frame. My application will have a large number (200+) of very short sounds, which will need to be able to be played one at a time when needed. Will this work with attachSound without performance problems? Seems that attachSound only embeds one sound at a time, or am I misunderstanding this? Synchronization with visual events could be an issue as well. In reference to synchronization with loadSound, you refer to having "code to handle that for me" - can you be more specific? - Tom -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
