FlexibleFactory

Some of our readers might have noticed a slightly downbeat tone to our recent posts, especially concerning everyone’s favourite web player! Here’s a more positive post to put the record straight.

Things have been a little quiet here at FlexibleFactory over the last year or so because the team have been busy with the launch of our new website over at TunaMedia Ltd.

Although we’ve kept the Flash content fairly discreet, it really deserves pride of place on the site. Without the Flash Player, this project would not have been possible. Even though we’ve been through a bumpy ride together, now that everything on the site is (quite literally) singing in harmony it gives me great pleasure to introduce you to radiotuna.com. Search thousands of free online radio stations by artist or genre… we’re pretty sure you’ll like it!

…and, despite the bumps and bruises, we still love you, Flash!

We’re developing a fairly complex application that requires communication between Flash players on the same page.

Initially, we went for a solution that uses LocalConnection. At seemingly random times, the browser crashed. I won’t even go into what the problem might be here. I simply ask the user to search the internet and/or the Flash bugbase for “LocalConnection crash”. It’s unusable.

So now we’ve opted for an ExternalInterface based solution. Once again, the browser crashes. Digging around the internet turns up this beauty of a page:

http://riafiles.googlepages.com/ExternalCrashDemo.html
(this is deliberately not a link, as using this page WILL crash your browser. If you do visit the page, just make sure you don’t have anything important open in your browser when you hit the magic button!)

Frankly, this is a fucking joke. I want to make my anger at this situation completely clear, hence the strong language. Apologies if this offends.

So off we go again, trying to establish the cause of these crashes. More time. More money.

It looks like polling SharedObject () might be an option. I wonder how much time we’ll have to invest in this before it all goes horribly wrong again. I’m already eyeballing this search with weary eyes.

If there were any choice here, we’d abandon Flash altogether on this project.

Maybe it’s just the kind of work we do at Flexible Factory that ekes out these kinds of problems, but we now seriously have to budget for working around bugs in the Flash platform. I’d say at least 10-20% of our Flash development time is spent on these sorts of issues. On this project, that moves up to around 80%.

Sorry, Adobe… if we filed all the bugs we found, we’d never have any time to work. I’ve seen the line:

“Comments on blogs, other web sites or 3rd party bug databases are not tracked by our quality assurance team.”

Well maybe, for the sake of hanging on to developers, it’s time Adobe did.

Wouldn’t it be great if Flash Player 11 was exactly the same as Flash Player 10, except without the bugs? Instead of running to cram more features into a buggy platform, wouldn’t Adobe’s time be better spent fixing what they’ve got?

Which leads me on to the big question:

As a business, can we afford offer Flash development in our product portfolio?

I posted this on StackOverflow.com, but maybe one of out readers knows the answer…

Quite simple really:

var req:URLRequest=new URLRequest();
req.url="http://somesite.com";
var header:URLRequestHeader=new URLRequestHeader("my-bespoke-header","1");
req.requestHeaders.push(header);
req.method=URLRequestMethod.GET;
stream.load(req);

Yet, if I inspect the traffic with WireShark, the my-bespoke-header is not being sent. If I change to URLRequestMethod.POST and append some data to req.data, then the header is sent, but the receiving application requires a GET not a POST.

The documentation mentions a blacklist of headers that will not get sent. my-bespoke-header is not one of these. It’s possibly worth mentioning that the originating request is from a different port on the same domain. Nothing is reported in the policyfile log, so it seems unlikely, but is this something that can be remedied by force loading a crossdomain.xml with a allow-http-request-headers-from despite the fact that this is not a crossdomain issue? Or is it simply an undocumented feature of the Flash Player that it can only send custom headers with a POST request?

We’ve been looking into some inconsistent behaviour across platforms when making socket connections. An application that works fine in Windows and OSX fails for no apparent reason when running on Linux platforms. After running a WireShark network capture, we established that, after correctly fetching a socket policy from port 843 of the remote host, the data sent to the target port was corrupted when using Linux Flash Player.

It turns out that the culprit is the Linux implementation of Socket.writeMultiByte, at least certainly when using the “us-ascii” encoding (it’s late and we can’t be bothered to test other encodings).

So, the line:

socket.writeMultiByte("GET somepath HTTP/1.0 \r\n","us-ascii");

fails completely, with garbage getting written to the socket.

We’ve written a naive (and appropriately named) replacement which works for what we’re doing, but doesn’t handle encodings.

private function writeBetterMultiByte2(msg:String):void
{
 for(var i:int=0;i<msg.length;++i)
 {
  socket.writeByte(msg.charCodeAt(i));
 }
}

It appears that we’re not the only ones having trouble with writeMultiByte, but this time it’s with ByteArray.writeMultiByte . Something seems quite broken here.

Using the new features of Flash Player 10, it is now possible to load files directly from the users drive.
Click anywhere to load your image into the Flash Player, and experience the faster, smoother rendering of Flash Player 10 with this psychedelic mandala we knocked together.

Flash Player 10 release candidate required.

[Note: This article now contains incorrect information. Look here for up to date info.]

For anyone interested in debugging applications built for Flash Player 10 release candidate, the standalone debug version of the player can be found at the following locations:

Windows
Mac
Linux

[see comments for more info]

Interestingly, they are now offered as the primary player in the Flex SVN repo. The former location in the repo for the debug players (http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/in/player/10/) contains out of date (beta 2) versions.

Flash Player 10 release candidate has just been released on Adobe labs.

To compile for this new player you need the latest sdk -
there doesn’t seem to be a debug player available quite yet.

Congratulations to the Flash player/Flex Builder teams!

Over the weekend I was taking a look into whether Silverlight might be a better bet than the Flash player for delivering streaming audio (Shoutcast in particular) to end-users. I built an extremely simple application that points a MediaElement at a Shoutcast stream (using the same url tweaking trick oulined in this previous post) and plays it back. Once again, looking through the documentation, it becomes apparent that Microsoft are trying to steer developers towards the use of their own streaming server solution.

So bearing this in mind, is Silverlight a viable browser solution for delivering legacy streams that fall out of the bracket of their own “streaming solution”? It can play back Shoutcast streams across domains in just the same way that Flash can but suffers the same fundamental problem suffered by Flash. There is no means of informing the player that an mp3 stream delivered over http is not intended for download, so the player keeps the whole stream in memory with the expectation that the download will end at some point… with Shoutcast it never does and the player consumes memory (ultimately ALL of the memory, if left playing long enough). So, both Flash AND Silverlight end up in the same basket on this front, slowly consuming all system memory. I think that this is stupidly limiting, and an API extension to drop played data would be a pretty simple enhancement. At the cost of promoting and protecting their own server products, both Adobe and Microsoft are missing a very fat slice of consumer ears.

Here’s a verbatim copy of my reply to a question asked on the FlashBrighton mailing list about online radio stations and Flash:

Question:

Hey,

I’ve been asked to build a little widget that streams a selection of free-to-air online radio stations. I know that this is possible, but does it require a specific server setup or can I just point a netstream object at a URL?

TIA

Answer:

Currently there are 2 options (neither of them particularly satisfying):

Option 1:

Sound.play can be used on audio/mpeg content type Shoutcast/Icecast streams (i.e. standard mp3 Shoutcast). You can establish the stream URL by opening the published .pls (Winamp playlist file) in a text editor.

Shoutcast servers (DNAS) sniff the User-Agent header, and if you are going for the root of the streaming server (e.g. http://shoutcastServerLivesHere.net:8000/), then it will inspect the User-Agent. If it matches a browser type, then it will serve up a page of HTML rather than the stream itself. Unfortunately Flash in the browser does indeed send a “bad” user-agent, as this comes from the browser, not flash. You can work around this by adding a semicolon to the path (i.e. http://shoutcastServerLivesHere.net:8000/; ) which fools the DNAS server into handing you the stream. I’m not sure what the deal is with Icecast (this uses something called mountpoints, so I don’t believe that the root ever resolves to a stream).

When using Sound.play, you can (with limitations), use this across domains… however some of the API that allows inspection of the data is disabled, such as computeSpectrum.

Because the ICY protocol (used both by Shoutcast and Icecast) is infact a superset of HTTP, when you call mySound.play on a shoutcast stream, it is in all respects the same as a normal file download. However, in this case the download never ends. So, somewhat problematic is the fact that a playing Shout/Icecast stream will eventually consume all memory on the client (although I’ve heard that Flash conks at about the 1 hour mark, but I have not proved this). This means that periodically, you will have to kill the sound, drop all references to it and reload it. You can either do this while the current stream is playing (and risk maxing out the 2 connections per domain browser limit), or completely stop and restart the sound (with a short break inbetween). Whichever method you use, the 2 soundswill very rarely sync up perfectly and you’ll be left with a discontinuity in the audio that listeners will hear. Most online examples of this technique seem to do this at around the 10 minute mark (although I reckon you could go to about 1/2 hour). Using this method will never expose the optional metadata that is embedded in the stream because Flash cannot send the “Icy-MetaData” header to switch the server into sending these metadata packets. Even if it could, it would break the integrity of the MP3 stream meaning that the Sound API would not work.

Option 2:

Wowza Media Server offers a Shoutcast/Icecast to Netstream convertion. Pricey, but nice. You won’t suffer memory issues on the client using this, and it will relay the metadata embedded in the stream too. It can also repackage AAC Shoutcasts such that newer Flash players can play these streams too (no server recompression required).

FileReference.load is a nice new feature in Flash Player 10, but the only thing you get back from it is the FileReference.data property, which is a ByteArray. This is useless (well, not altogether, as we’ll see) in the case of MP3 audio files, because the built-in Sound API does not support loading from ByteArray.

When “making-some-noise” wasn’t quite so easy, I invested a bit of time messing around with MP3 data to see if my Flash sound hack for playing PCM audio data could be subverted to use MP3 data instead. While I got this partially working, I realised that it was a library without any application. What use was it? I tried to use it for shoutcast streams, but it is not possible to seamlessly stitch together arbitrarily small frames of MP3 data and fire them with a “silent sound”. Unfortunately the ramp-up time of the mp3 decoder means that the signal audibly drops out at the stitch points.

It turns out that my efforts were not in vain, because with the arrival of FileReference.load, I have been able to repurpose this library so that it is now possible to load a Sound object with the data provided from a FileReference instance.
(more…)