allowDomain doesn't solve cross domain issues

If SM2 is able to initialize without errors (eg. soundManager.onload() fires), then the cross-domain stuff is all good, JS and flash can talk etc. This is the harder of the two problems. If you're seeing errors when loading a remote .swf but a local (same-domain) URL works fine, then the remote .swf is apparently not passing the "allowDomain" test.

SM2 is able to load MP3s from remote domains without issue - I do this from the live demo pages, for example. The only limitation in that case is that ID3 information is not provided unless the remote site has a cross-domain policy file (crossdomain.xml) which Flash can access and is granted permission for that data.

Ah, I think I see where your report stems from: You have allowDomain('*') on a remote SWF, but then cannot access files on the local file system when viewing a page locally/offline, on your hard drive. Maybe you have a slightly-different situation, but again the Flash sandbox prevents remote SWF -> local filesystem access for good security reasons. You can see the specific error messaging for this in the debug output of SM2.

Effectively, the security sandbox for SM2 is:

Local filesystem (fs) SWF -> local fs MP3: OK
Local fs SWF -> network MP3: OK
Remote (network) SWF -> local fs MP3: Denied
Network SWF -> Network MP3 (same-domain or cross-domain): OK* (ID3 note for x-domain)

As a way to work around this, when viewing pages offline (eg. not over HTTP), you can have SM2 use the altURL property, load a local SWF and then it will be able to access remote internet (/network) resources.

When you first view the SM2 demos etc. offline, you will likely have already whitelisted it to work via the flash player security settings panel, eg., "allowing" the path which contains your project and the SM2 code so that JS + Flash can talk to one another.


soundManager.url = 'http://example.com/sm2-swfs/';
soundManager.altURL = './swf/'; // path for when viewing via c:/ or file:// etc.

This way when loading SM2 offline, it will load a SWF from the local path, and when online, it will use the internet SWF and thus you avoid security issues by playing within the rules of the sandbox, per se.

I've never compiled the AS2 source using anything other than MTASC, so your note is interesting. For AS3 I use the mxmlc compiler on both Windows and Mac, without issue.