dnalounge update

DNA Update: It's been a month, since I suck, so it's a long one. I took some pictures of the Capacitor show, too.
Tags:

10 Responses:

  1. icis_machine says:

    it was so good even b liked it and he hates formal dance. thanks for housing it.

  2. baconmonkey says:

    re: RA going to static...

    have a machine play RA stream and loop-back the output audio to it's own input.
    analyze input.
    when it goes batshit, communicate with streaming server in some way and tell it to restart the RA Daemon.

    a wall of statis should be easy to detect via one of several methods.
    1. unvarying RMS levels
    2. FFT spectral analysis looking for unvarying wall of sound

    • jwz says:

      It's very hard to do that, because it's very hard to keep RealPlayer running: if there's ever a network glitch, it'll stop, and you have to click "Play" again, possibly after clicking "OK" on the dialog box first. There's no non-GUI batch-mode version of RealPlayer, nor is there (I think) any way to remote-control it. (Maybe something with JavaScript and plugins, but that's a whole other ball of worms: web browsers that can run JavaScript and plugins don't work real well in batch mode either.)

      I'm trying not to just be kneejerk about this, but it really is another example of the superiority of open standards: if the protocol was documented then this problem would be solvable in any number of ways:

      • there would be a way to play audio batch-mode without needing user interaction through the GUI;
      • there would be a way to decode and analyse the stream in software instead of going through a hardware loopback cable;
      • there would be a way to turn on verbose diagnostics in the player, so I could just restart the stream whenever the player started spitting out a lot of messages about bad frames or whatnot;
      • and, realistically, the code probably wouldn't have this bug in the first place, because someone would have fixed it by now.
      • baconmonkey says:

        there's nothing knee-jerk about it.
        well, other than wanthing to KNEE the JERK who started RA in the groin.

        but I digress.
        MS and apple's video standards are not exactly open, but there are SDKs and developers resources, such that one could write a program to monitor a stream, even if one doesn't know the specifics of the innards of the stream. there might be an RA SDK, but it'd probably cost a fair ammount of $$. have you looked for any 3rd part RA tools? I mean, you can't be the only one to have this problem...

        • jwz says:

          As far as I know, there are no third party RealVideo tools. I really wish I could just ditch Real entirely, but there aren't any alternatives. The MS and Apple offerings are, of course, useless to me, because there are no players that work on Linux. (Running Windows emulators doesn't count, saying "Quicktime works fine! Oh, unless you want Sorensen" makes me throw things.)

          I assume other people who do RealVideo broadcasting solve this problem by having staff watching it all the time.

          • baconmonkey says:

            "I assume other people who do RealVideo broadcasting solve this problem by having staff watching it all the time."

            when have you known a large company to view that as a valid response to off-the-shelf products?
            sure it inevetably happens, but that's when there is internal development added on top of purchased products. no company would buy a server that is that unreliable without some sort of software fail-safe. either something is greivously wrong with your config, or there is a product out there to monitor the daemon. or REAL has managed to scam the world yet again.

            • jwz says:

              If you want to do large-scale RealVideo broadcasting, it costs over $100k in licenses alone. Anyone paying that can afford to make it be an admin's job to keep the damned server up, and/or have the fellatio-hotline to Real's developers who actually know how to fix things.

              • baconmonkey says:

                I dunno, I still can't see even the dumbest of corporate buyers purchasing the full thing when the answer to "how reliable is this $100K server you're trying to sell us?" ends up being:
                "Oh very reliable, as long as you have one of our patented Reboot Monkeys (TM) on the payroll. You see, little Bonzo here is trained to press the shiy red reboot button if he hears more than 3 seconds of static in his headphones. He also knows how to make coffee and change his own diaper."

                no company with a brain would buy something that is admitted to being that unreliable - even if they can afford a crack team of slackers to sit and listen to their streams 24/7. would you buy a web server that had similar disclaimers on it's stability? plus there would inevetably be a competitor popping up if it really was that shoddy. MS and QT are not really geared towards real-time broadcasts, so they don't count.

                • jwz says:

                  Who said they admit it's not reliable? Nobody who sells software ever does that, and software is very rarely reliable. Anyway, for all I know, it's 10x more reliable when running on NT instead of Linux (though that's kind of hard to believe.) The manual makes it clear that the NT version of RealProducer is far more polished than the Linux version, so I assume that's where most of their customers are.

                  MS and QT are not really geared towards real-time broadcasts, so they don't count.

                  What sites do realtime 24/7 streaming besides mine? I'm sure there are some, but I can't think of any, which makes me think there aren't too many of them. I suspect that most people either: only do realtime stuff every now and then, for the duration of an event, and have someone to babysit it (and press the start and stop buttons); or, more commonly, they're people like CNN and IFilm who do non-realtime streaming of short-ish pre-recorded clips.

                  • naturalborn says:

                    It's true, the hardest part of large Real deployments is keeping the damn servers running. There have been a number of big deployments which didn't go so well and everybody thought the problem was bandwidth when in fact there was plenty of bandwidth and the servers kept crashing.

                    The ability of people to be incompetent at writing software never ceases to astound me. A Real server has to do encoding and compression on the fly, but it only does that once, and thereafter uses the same data for all downloaders, so as it scales up it's really just pushing the same data to more downloaders. The servers are written in C++, spewing out basically raw data to a large number of downloaders, and yet crash constantly and are frequently CPU hogs. This after years of development by several teams of people.

                    My own networking app can push out huge quantities of data with no glitches and hardly using any CPU, and it's written in Python. I don't know how they do it.