Scott's dashboard

SM2 has a bit of a learning curve and is not a player that can simply be embedded from other sites, unfortunately, due to the fact that it has multiple external files and dependencies (HTML + CSS + JS + Flash), as well as Flash security restrictions when on external domains. One of SM2's advantages is a more customizable UI and a Javascript-based API people are familiar with, but one of the downsides is it's not a single SWF that you can use <object>/<embed> for.

If you want to use the player on your own site, that is certainly doable; you just need to copy the files to the right directories and perhaps modify the CSS so that images etc. load correctly, and so SM2 can find the Flash movie it needs and so on.

The 360 player demo, examples and code etc., are on the SM2 site:
http://www.schillmania.com/projects/s...
My recommendation is to view the source code of the demo, which has a few comments and instructions on how to get things running as well.

You can download the project including the demos and code you need from the main site at http://www.schillmania.com/projects/s...

I have not tested SM2 under an HTTPS environment, but it's certainly possible that a mix of HTTP and HTTPS could cause problems. I would expect it to work under 100% HTTP or 100% HTTPS, but wouldn't be surprised if it failed when in a mix of both.

Typically browsers like IE will throw an error or warning if your browser loads a HTTPS: URL, but then requests scripts or images over HTTP: - you get the "insecure content" message and so on.

My recommendation would be to try a 100% HTTPS-based test on your production environment where the page and its assets load from the same host/port etc., and see if SM2 throws any errors while starting up or when trying to play a sound.

I should probably close down the other thread and merge it into this one.. Anyway, this issue is the more interesting one and - I suspect - something that can be figured out by narrowing down the possible causes.

With the SM2 demos, I tend to use Flash 9 and useHighPerformance = true, the latter uses position:fixed vs. absolute on the flash movie and I wonder if that might affect how Flash is treated in the browser while the user is in another tab, etc.

But ah, interestingly, perhaps it is as you describe - starting SM2 in the background, eg., loading and having soundManager.init()/onready() fire while the tab is out of focus, may be what does it in (?)..

The SM2 demos start up right away and scan the DOM etc. for links to play, but the sound objects are created only as needed. Basically it's sound.onfinish = player.nextTrack; or some such. The issue I think is that JS <-> Flash is "frozen" when in background tabs or minimized windows in certain cases - so Flash happily finishes playing the current track, but no whileplaying() or UI updates happen in JS because Flash -> JS is not working, for whatever reason - and because of that, onfinish() doesn't fire in JS-land either, and so it does not instruct Flash to create, load and play the next track and so on.

On Flickr, uploading via the JS + Flash widget (part of YUI) that we use is affected by the same thing. Current file will upload and finish the file it started while in focus, when in a background tab, but the progress doesn't update window.title with '(xx% complete) - uploading', and the next file will not start because JS is not notified etc.

So, something is causing the browser to block or prevent Flash <-> JS communication in certain cases for background tabs and minimized windows in Safari, to the best of my knowledge. I'm not certain exactly what triggers it.

My suspicion here is that with Chrome, it's probably high CPU use or something else "freezing" flash while opening a new window, and I don't think there is much that can be done there. FWIW, with the SM2 demos I don't see this happening on the Muxtape-style page, using Chrome on a 3-year-old 1.6 GHz Centrino laptop running WinXP.

Maybe there is a quirk with the way small or off-screen flash movies are treated, or something else specific to the DOM/layout that contributes to either of these issues - I haven't been able to nail it down, but the demos on the SM2 project home don't seem to be affected by the background tab issue in Safari. (eg., the Muxtape-style player happily goes through the playlist, no "freezing" after one sound is done.)

Perhaps there is something specific to your set-up, using MovieStar/AAC playback with or without highPerformance enabled etc., that is affecting the way the browser handles the Flash bit of SM2. It looks like you are not setting useHighPerformance=true, which would be one of the things I'd try flipping to true and seeing if that has an effect. It changes the positioning of the flash movie to use position:fixed vs. position:absolute, which may affect the way the browser treats it when in out-of-focus/background tabs.

FWIW using Safari 4 on WinXP just now, I was able to listen to a few consecutive songs on 8tracks when in a background tab, and with the whole window minimized - but I know the issue you're mentioning re: freezing, we have the same happen with Flash + JS-based uploads in Safari on Flickr.

Odd, sounds like a JS error was breaking things? It's a little funny because of the way JS + Flash start up, sometimes if there is a JS error within the scope of soundManager.onload() the error won't "fall through" all the way to the console, and things will silently fail. I'm not sure if there is a nice way around this, unfortunately.

Glad SM2 is of use to you! – Scott, on December 23, 2009 17:00

Sorry about the lack of support still, it's one of the items on my to-do/to-investigate list. A "Mr. Hash" sent in a slightly-modified version which showed how he might change the source to work, but I would also need to verify that the SM2 API is still consistent and at least mostly works with the RTMP stuff as well - that is, assuming that the same methods are available when loading RTMP content vs. a regular MP3, and so on.

If you download SM2, you will get the AS2 and AS3 source files in the src/ subdirectory; feel free to tinker! I use MTASC for compiling the Flash 8 version from the console, and the "Open source Flex SDK" (Java-based) for the AS3/Flash 9 stuff. Check the .bat and .sh files for the command-line syntax to build the SWFs.

With file:// and widget://, yes. Security permissions must be granted for SM2 when "offline", unless that content is loading over http:// eg. pointing at http://localhost/ even, will work.

Looks like everything is working OK, except the load request - this is odd, as typically the issues people have are with scripting the SWF across domains, and you look to have that problem sorted out.

I might try loading one of my demo MP3s as used on the SM2 web site, and see if things work OK; there's a small chance you may just have something specific to your MP3s that Flash doesn't like, ie., the way they're encoded or served from their respective host.

The SM2 demo on schillmania (loading Flash from there also) is able to load and play examples using MP3s from freshly-ground, another site I run, and they play fine. Perhaps try loading some of the SM2 demo MP3s on freshly-ground from your site using the x-domain version of SM2, and see if Flash throws any errors there.

Hmm. Does the sound stop as soon as a new window is opened, or is it more like the current sound finishes, but then the next sound/track (eg. as in a playlist) doesn't start?

There is a rather weird known issue where JS/Flash communication will be "frozen" in some cases when flash + JS is in a background tab or minimized window, and the next sound starts only after focus has returned (see "background tab issue" for more: http://getsatisfaction.com/schillmani... ) - unfortunately I think this is a browser behaviour triggered by something we haven't figured out yet. It seems to be inconsistent.

SM2 cannot start without whitelisting (security sandbox permissions granted by user) when loading from a web page coming from file:// or widget:// because the SM2 Flash talks to Javascript, which is "insecure" because it is allowed to load resources from file://, widget:// OR http:// on any page, from file:// or http:// or widget:// - it does not have the same security restrictions as Flash, therefore it cannot be "trusted".

A flash widget object/embed that does not use Javascript *can* load and work from file:// or widget://, provided it does not have a Javascript API like SM2. (Specifically, this flash widget does not use ExternalInterface, which is what allows Flash to talk to Javascript-land.) Because of this, your Flash example works without security prompts or dialogs.

I am not sure exactly what other problem(s) you are describing re: security, but there is no way to "force" a connection that I know of with SM2 without security settings being changed by the user.

RTMP support is not supported in SM2 at this time. Its value is debatable, given that RTMP is a "proprietary" protocol designed by Adobe and you must have a special server to support it.

RTMP is also not truly secure, nor more secure than plain old HTTP by any means; tools exist to capture and save RTMP streams to disk.
http://en.wikipedia.org/wiki/Real_Tim...

Attempts to protect audio are mostly futile, and a waste of time. The "analog hole" will always exist. However, there are a few lower-cost tricks you can use to help discourage casual copying of the encoded audio sent to the client - eg., "no-cache" HTTP response headers, serving over HTTPS, single-use/expiring URLs with tokens, and so on.

There is a good discussion on protecting audio, ideas and caveats etc., in this thread:
http://getsatisfaction.com/schillmani...

Finally, the JWPlayer project does support RTMP and may be up your alley:
http://www.longtailvideo.com/support/...

Looks like you'll need to modify the inline player to look for a "playable" class name on links. I thought I had that in there, but it appears that I don't.

Something like this, within inlineplayer.js, which I modified to also check for a "playable" class which should allow it to play:

...
if (!self.classContains('playable') && (!o.href || !o.href.match(/\.mp3(\\?.*)$/i) || self.classContains(o,self.excludeClass))) {
if (isIE && o.onclick) {
return false; // IE will run this handler before .onclick(), everyone else is cool?
}
return true; // pass-thru for non-MP3/non-links
}
...


No go on a JS object, nope. Flash makes a standard HTTP request for audio, typically an MP3, and expects MP3 data in a HTTP response as if your browser was downloading the file directly.

You'll need to make sure you pass the correct headers down as sometimes if you're writing your own PHP script, content-length may be omitted and so on and this will cause problems on the Flash end.

For more fun details on HTTP headers which Flash expects, eg. content-length, see this thread: http://getsatisfaction.com/schillmani...

I *think* a 302 may not work with Flash, it might ignore it for security reasons. Perhaps it'll work if the redirect is to the same domain - I haven't tested this very much. More discussion: http://getsatisfaction.com/schillmani...

If possible I would avoid using Ajax/XHR for these calls, and simply let the server do the work of fetching and serving the file when it's requested. Skip the intermediary step, if you can.

You can add a CSS class to indicate that a link is playable, even if it doesn't have an .mp3 extension.

eg.

<a href="/path/to/some.php?file=x" class="playable">MP3 #1</a>

When clicked, SM2 will then start loading and playing the MP3 content at that URL as data is received.

One note, I'm not certain if Flash will handle HTTP 3xx responses (eg. redirects) to a new URL, so that may be worth testing. You could serve a 3xx pointing to the "real" URL once determined, but you don't necessarily need to do that, either; you could simply have the PHP script open and serve the MP3 content itself.

It sounds like the widget:// URL is probably not being liked by Flash's security model, similar to how file:// doesn't work (eg. when viewing offline HTML on your desktop in the browser) until you make a change in the Flash Player security settings to allow it.

For ExternalInterface to work, Flash must have "network access" which may mean whitelisting in the security settings. This is because with access to Javascript, Flash can then load network content because Javascript does not have the same security restrictions that Flash does.

If the SWF is loading over HTTP, it should not have problems - eg. http://localhost/ when the browser is also viewing content from http://localhost/ following "same domain" rules.

Short of whitelisting the location via http://www.macromedia.com/support/doc... as you mentioned, there is no way to "work around" this because it is a security protocol for good reason.

Heh. The simplest one-sentence summary: "Here there be dragons." ;) Unfortunately it's a rocky road because of the combination of Flash + JS, and the way SM2 starts up.

There are a few really dangerous issues here, but depending on your use case (and willingness to do crazy things with JS), it may be doable. Primarily things revolve around dynamically writing out the lightbox, appending the SWF then and starting SM2 - by design, SM2 only likes to load and start once per page. Only one instance of the SWF can exist at a time per page. Also, other things can break JS-Flash communication which SM2 needs to work.

The issue with post-start-up is that once the .SWF has been added to the document, it cannot be destroyed or made display:none or re-created or have anything done that would cause it to reload or "re-start" (eg. setting display:none and then display:block) because that will break the connection Flash has to JS, destroy any sounds or videos currently loaded and so on.

When SM2 starts up, it tries to append the SWF to a DIV with the id of "sm2-container", eg.

<div id="sm2-container">
<!-- flash movie will go here -->
</div>


If you have this element within your lightbox, SM2 should be able to add the .SWF there and show the movie. However, lightboxes are typically dynamically inserted via Javascript if I'm not mistaken (?) - so you will need to modify SM2 to start only after the lightbox HTML "exists" in the DOM, which is another whole can of worms.

You can set var SM2_DEFER = true; and then load soundmanager2.js, and it will not create and start a new SM2 instance right away. You can then call soundManager.beginDelayedInit() after the lightbox is ready, and it should start.

If you show the lightbox more than once, things get even more complicated. I'm not even sure what I'd do then, maybe soundManager.reboot() or something to get things to restart.

To keep things simplest, I'd try using a standalone Flash player a la YouTube or Vimeo, because when you write the embed code to the innerHTML of your lightbox or what have you, the Flash will start and load as needed reliably.