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!

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.

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”!

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?