Great job. Having done something similar for a prototype (using JS to control Flash players), I must say that it takes a great deal of work to get it all nicely. I'm assuming that you're using ExternalInterface to communicate with the player?
Also, is there any reason why you guys didn't replace the Flash with HTML 5's <audio> tag for browsers that can support it? Security issues maybe?
I've been writing Grooveshark's players since the beginning, so I'd pretty much consider myself at an expert at getting flash to communicate with other moving pieces by this point.
We've gone through some pretty crazy revisions, including one (ancient) version, back when the actual playback was performed by a locally installed client application written in java, yet the actual playback controls were located on the website in a small flash widget. That involved the use of the script-tag hack (I think nowadays most people call that JSONP) in javascript to confirm that the local client was running, ExternalInterface to tell flash that it was safe to attempt to load the crossdomain.xml file from the local client (it would quite stubbornly refuse to try again after a failure), and then an XMLSocket connection between the local client and the flash widget on the page in order to pass back and forth user commands and the current playback state.
It actually worked surprisingly well, but I'm really glad we've since moved to centralized server streaming. The current version is just as you said, an invisible flash widget that syncs to the javascript on the page via ExternalInterface.
Also, is there any reason why you guys didn't replace the Flash with HTML 5's <audio> tag for browsers that can support it? Security issues maybe?