So, the audio tag, I did give them another try, I didn’t
change my html/js codes, but I’ve updated my firefox.
Chrome is still the same version.
Now, like a miracle, they decided to play music,
even though they refused to do so yesterday.
So, Opera, Firefox and Chrome are capable of
playing IceCast2 streams using the Audio tag
after all.
Yet, it’s not perfect. Chrome’s tab crashed after
an x amount of time. It did so every time I let it
play the stream. Firefox doesn’t show any crash
message, but simply stops playing after an x
amount of time. So even though they passed
the first test, it seems, Opera is still the only
browser with acceptable support for streaming
music.
Next: XMLHttpRequests, their security is rather
script. A request MUST go to the same protocol,
same domain, same port. Since the IceCast2 server
is server it’s current song xml data on a different
port then the webserver, the request will fail.
Flash has a solution to allow connections do a
different port. You need to set up a server
listening on port 843. Since this port is below 1024,
you must have root access to the server to set it up.
See the link below for more information:
http://www.adobeursurvey.com/devnet/flashplayer/articles/socket_policy_files.html
In the past, I’ve been looking, wihtout success, for a
simular feature in JavaScript. Yesterday, I’ve discovered
JavaScript requires a different approach. The server
you are requesting must set a header that tells JavaScript
it’s allowed to proceed with it’s request.
See the links below for more information:
https://developer.mozilla.org/En/HTTP_access_control
http://www.w3.org/TR/cors/
I should take a closer look at the IceCast2 configuration
if it’s possible to insert a header, or else I can modify it’s
source code to include that header. I’ve been doing
some IceCast2 source patching before since there was
a bug in it’s ShoutCast compatibility code. I think I’ve
mentioned it before in my blog. I think it was something
like it was sending one newline in stead of two.