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’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.

Over at tunamedia.co.uk, we’ve released a demo of Flash movie playing Shoutcast streams using the new Sound API features available in Flash Player 10. Take a look.

We’ve been doing quite a lot of stuff using the new FileReference API that allows access to local files without server roundtrips. The current official release candidate seems to limit the allowed file size to somewhere in the region of 512k. This thread on the flash player 10 forums summarises the problem nicely. It’s led us on a bit of mission to find a more recent version of the player, which can be found here:

http://opensource.adobe.com/svn/opensource/flex/sdk/branches/3.0.x/in/player/10/

[The contents of this article are now incorrect. We've been using the players in this package and this one for linux now.]

Thankfully, this newer version does not seem to carry this FileReference limitation.

If you look through previous posts on our blog, there are a couple of posts relating to the location of the most recent player. Once again, the most recent version appears in a different location. This rather begs the question as to why new players are being littered around various places on the adobe website with no apparent consistency.

Why aren’t developers being informed of newer releases of the player that can be publicly obtained? Why are they being “hidden” in the various branches of the Flex SVN repository?

Last week, I updated and rebuilt the Flex SDK from Subversion, and was pleasantly surprised to find that new players had been included in the repository. It was followed by disappointment that my pet project, which leans heavily on the new SAMPLE_DATA events in the Sound API stopped working.

It turns out that in player 10,0,0,591, the SAMPLE_DATA event string, which up to this point has been a property of the flash.events.Event class has been moved to now exist upon the flash.events.SampleDataEvent class. I’d always wondered why the Flash Player team had chosen to create a SampleDataEvent class, but to put the string that defines the event on the Event class instead of the SampleDataEvent class. It appears that this inconsistency has now been cleared up.

It does, however, lead to a situation where a software product labelled as Release Candidate is still having significant changes made to it that will break software developed against it. It leaves me with the conundrum of having examples of the new Sound API extensions on our blog that will either work with the latest (but somewhat obscure) version of the player and leave most users with a broken experience, or to develop against the old API in the knowledge that the pieces will eventually break when newer versions of the player are officially rolled out.

I think it’s time to redefine my understanding of the term “Release Candidate”!

[The contents of this article are now incorrect. We've been using the players in this package and this one for linux now.]

The infomation in a previous post about the location of the standalone debug player for Flash Player 10 is now incorrect as Adobe deleted some locations from the Flex subversion repository around the start of the month.

The player 10 debug versions can now be found here:

http://opensource.adobe.com/svn/opensource/flex/sdk/trunk/in/player/10

As far as I can tell (I’ve only checked Windows standalone and Windows plugin, not the activex version), they’re at version 10,0,0,591, released yesterday. The browser plugin installed is a debug version, which will be handy.

I’m really excited by the possibility of using PixelBender filters for audio processing, but at the moment, it seems to be a neglected area of development for the FP10 team, despite the odd mention here and there of its use in operations other than image processing.

I’ve posted several questions to people who might be able to answer, yet no further information has been forthcoming. I’m publishing a digest of these questions below in the hope that somebody might be able to shed a little light on how it is all expected to work…

Issue #1

There has been mention of using the ShaderJob API for non-image related computation. It’s a subject of interest to me as it could be used for processing audio data. However, it seems to be impossible to create PixelBender filters that allow the processing of one dimensional data. I posted a couple of questions on the Adobe forums about this, but have yet to receive a satisfactory answer. Here’s one of the questions that summarises the problem:

The Flash docs say the following:

To process a ByteArray containing a linear array of data (as opposed to image data) set the corresponding ShaderInput instance’s height to 1 and width to the number of 32-bit floating-point values in the ByteArray. In that case, the input in the shader must be defined with the image1 data type.

What must the output be defined as? Float, right? This would mean a simple doNothing filter could be defined as in the attached code below.

<languageVersion: 1.0;>
kernel doNothing
<   namespace : "flexiblefactory.co.uk";
    vendor : "flexiblefactory.co.uk";
    version : 0.1;
    description : "do nothing filter"; >
{
    input image1 src;
    output float dst;
    void evaluatePixel()
    {
        dst = sampleNearest(src, outCoord());
    }
}

But PixelBender gives the following error:

ERROR: (line xx): ‘dst’ : cannot have 1 or 2 channel outputs

So, either my assumptions are incorrect, or PixelBender does not support this kind of operation.

Can an Adobe head tell me what’s going wrong here? Am I barking up the wrong tree or are we waiting for a new version of PixelBender that supports 1dimensional data?

Issue #2

The default endian-ness for all audio big endian, but the default endian for the Shader API when using it to operate on ByteArray instances is little endian. The only way to convert the endian of a ByteArray full of floating point numbers is by iterating through each value, and copying to another ByteArray with differring endian. When moving high volumes of data, this conversion limits the usefulness of a Shader to only more complex calculations.

For instance: a simple Shader designed for setting the gain of an audio stream becomes pointless if you first have to iterate the contents of the ByteArray in Actionscript to change the endian, and subsequently convert the output back again for playback. This would negate any performance gains made by using the Shader.

So, all this talk of using the Shader for audio operations comes with a major drawback, right?