Forgot your password?

Comment: Re:Never gonna happen, because of how OSS works. (Score 1) 299

by Mr Thinly Sliced (#46090051) Attached to: Ask Slashdot: An Open Source PC Music Studio?

> Why on earth would you want to mix your professionally sounding audio with every freaking app that goes "ding" or "boing" or "you've got mail"?

Because at it currently stands any application that attempts to output through pulseaudio will get blocked and possibly hang until you stop jackd.

Having to "stop" jackd and my audio mixing session just because I want to take a skype call is not acceptable in 2014.

Comment: Re:How well does XWayland work? (Score 1) 340

by Mr Thinly Sliced (#45817549) Attached to: X.Org Server 1.15 Brings DRI3, Lacks XWayland Support

Yes. I've hacked aroud(sic) in xlib a lot.

Splendid - then I won't need to copy-paste some of the problems regarding right click menus locking the server and similar issues documented elsewhere - right? The X developers that have moved over to developing Wayland have explained these issues far better than I can.

Would you be kind enough to acknowledge these problems exist?

I get the feeling that people have invested so much energy and effort in X that they're reluctant to acknowledge the problems even exist. It's like some kind of programming Stockholm Syndrome.

I started recording live TV on a Linux box in 2003. I never had problems. What were you trying to make?

A simple application capturing part of the desktop plus a live video feed with V4L and synchronised audio capture.

I started with just trying to capture the desktop + audio. Using either direct ALSA, pulseaudio or jack I would get scheduling issues and dropped X11 frames and/or audio underflow sometimes skipping multiple screen capture frames at once. Once I saw the problems programmatically I tried using the raw ffmpeg binary which exhibited the exact same issues either under a regular or realtime kernel. I did try with a recent compiled version, too.

We are getting way off topic with this discussion however. I feel my original premise (OSX is not behind X in terms of functionality or libraries) still stands.

Comment: Re:How well does XWayland work? (Score 2) 340

by Mr Thinly Sliced (#45811771) Attached to: X.Org Server 1.15 Brings DRI3, Lacks XWayland Support

> You know none of that stuff is in wayland either?

Yep, I was replying to GPs assertion that OSX has to catch up to X11.

> Also what's wrong with X event handling? You can select() on the events just like any others.

Have you ever written a real X protocol application or used one? Xedit, for example. The code is a mess of anachronisms (events targeted to sub-windows - if you are using them - modern toolkits don't now, excessively verbose error handling due to the historical cruft in the protocol etc) that haven't been brought into the 20th century due to the backwards compatibility needed.

Now you can say "yes, but these days everyone uses toolkit ##" - and you'd be correct, and you'd be using the toolkits abstraction on top of the X protocol and events. It gets messier when you want to add a sub-window with a GL or YUV surface. Now you're dealing with X, Toolkit ##, XGL and GL.

> Also, I've touched on OSX video handling. This is not a high point of OSX. Decoding a video and getting at the pixels is far, far better under ffmpeg than OSX.

Back when I moved onto OSX it took me about three days to get a custom screen + audio capture program up and running (with live preview) - something I was unable to getting working under X/ffmpeg and ALSA/pulseaudio without frame drops and synchronisation problems after many days of going grey. Feel free to blame it on my programming skill - but I found Apple's documented examples far easier to use as a base. Even using the ffmpeg binary alone with X11 capture and alsa/jack had frame drops and stalls in capture.

Perhaps this is a case of "better the library you know"? For me the OSX video handling is great and simple to use. Were you using the Objective-C bindings or talking C?

Comment: Re:In a country far away and long ago.... (Score 2) 340

by Mr Thinly Sliced (#45811293) Attached to: X.Org Server 1.15 Brings DRI3, Lacks XWayland Support

Friends, Country Men (and Women)!

This propaganda is exactly that which the Royalists would have you believe - without telling the complete story of waste and unsightliness they would foist upon us once again should we believe their lies!

Our royalist friend has failed to mention that under the Kings rule, some houses would remain half painted for a full day! It was due to the King having only limited time with which to grant delegation powers to the Minister of Composition who was powerless to get painting done without the Kings intervention.

Perhaps our royalist friend would also like to explain the excessive bureaucracy surrounding simple requests like even paint colors? Every simple request had to pass the Kings desk.

I for one would also like an explanation for the massive expense of maintaining a whole legion of Royally Approved color choosers that could only choose baroque antique color schemes that nobody wanted or commissioned.

No my Friends, the Royalists have but one agenda - to return us to the times of half painted houses and top heavy bureaucracy that punctuated our time as a Monarchy.

Comment: Re:How well does XWayland work? (Score 4, Insightful) 340

by Mr Thinly Sliced (#45810751) Attached to: X.Org Server 1.15 Brings DRI3, Lacks XWayland Support

> Having seen terrible X compatibility layers for Mac OS X and Windows

The OSX X (XQuartz) implementation _is_ xorg-server (currently 1.14.4) - you know, the one used on Linux (with certain OSX specific tweaks to allow non-root mode)

The problems you mention with interoperability are largely down to the core windowing systems being vastly different models. We can argue about which model is correct but the interoperability problems are a side effect of different models - not evidence of a particular model being bad.

I'm not convinced from your descriptions here you quite understand the complexity of the interactions.

> The lack of X has been the main technical drawback Mac OS X has been
> having compared to Linux.
> I'd much rather see Mac OS X catch up with Linux than for Linux to go down
> to the level of Mac OS X.

OSX has vsync based updates, sensible event handling and lots of core library stuff (like the AVFramework) that makes it a pleasure to program compared to XWindows.

The Linux desktop _needs_ to get off X. It's an outdated behemoth with a model that is way out of date. Now you could say "well let's update the model then".

Sure, you can do that. And when you do that, you get Wayland.

Comment: Re:C++ can operate at the very limits (Score 2) 371

by Mr Thinly Sliced (#44457611) Attached to: Using Java In Low Latency Environments

There is no reason Java can not run just as fast and predictably as C/C++, given people who know what they are doing.

Yes, yes there is. Well, more than one actually. Here we go again:

(1) Unbounded stop the world of the JVM causing thread stalls (GC being the canonical example)
(2) Other stop the world's in the JVM due to code profiling causing a newly compiled version to be swapped in (maybe they've switched to atomics here, I'm not sure)
(3) Java's internal profiling and housekeeping absorbs CPU cycles
(4) Everything is allocated on the heap. If you have an array of objects - it's an array of pointers to things in the heap. There is no packed array of structs

These are the ones I've run up against when attempting to reduce scheduling latency in Java.

You can reduce the impact of (1), (2) and (3) using a realtime Java VM - but then you're not really writing Java - you can't use standard containers or standard libraries as they allocate memory all over the place. Also, the ahead of time compilation means you've lost the benefit of that lovely JIT re-profiling and optimisation.

(4) Can be mitigated a little by using NIO buffers with long offsets - but it's a mess and adds unnecessary extra computations to something that should just be pointer + offset.

To get down to it - with the standard Java VM I get scheduling latencies occasionally larger than 20ms - with C++ my thread scheduling latencies are measure in nanoseconds (i.e. less than a microsecond).

This is on a real time kernel with all appropriate thread priorities and such.

Comment: Re:performance is not black and white (Score 1) 371

by Mr Thinly Sliced (#44457365) Attached to: Using Java In Low Latency Environments

Being a big "C" booster these days, most of my hate is reserved for C++. It is a language with no home. Overly complicated, not as lightweight as C, and not as easy to use as Java or .NET. I could speak at length about its problems.

I'll be the first to admit to the myriad of problems with C++ (compilation speed and difficulty refactoring being my pet peeves) - but it has things that just make life more pleasant over C:

* Standard library for algorithms, structures and so on
* Abstraction using templates are free - (well, one byte on the stack) and let you do (admittedly sometimes crazy) flexible things
* Abstraction at all
* Exceptions

You're welcome to your opinion, of course. I feel that C is overly simplistic and encourages re-implementation of the most mundane of things.

One look at things like GObject and GTK should at the very least make you question the sanity of accounting for every little thing. C doesn't leave you any choice - you must micromanage everything.

Comment: Re:Warm up is a big deal (Score 1) 371

by Mr Thinly Sliced (#44457183) Attached to: Using Java In Low Latency Environments

The standard fix seems to be to write apps to exercise their own critical paths at startup. This is *hard* when dealing with front-end code on the edge of the system you control. Even when it's easy, it's still something you have to do in Java that is entirely irrelevant in compiled languages.

These people should be using a real time Java VM and an ahead of time compiler for those parts.

It means you can skip the warm up. The only problem with it is you can't hire regular Java guys - real time Java is a little bit special, and you can't use regular Java collections and other things in the ways you'd expect.

Comment: Re:Essential Features.. alpha support, lossless. (Score 1) 86

by Mr Thinly Sliced (#44071253) Attached to: Next-Next Generation Video: Introducing Daala

Have you tried contacting the Xiph guys at all?

If email isn't working try IRC - they probably have a channel the devs hang out in, or their mailing list.

You have a nice suggestion and good grounds for it being a feature - do a little lobbying and see if you can get one of the devs to champion the feature for you!


Intel Streaming Media Service Faces An Uphill Battle for Bandwidth 82

Posted by timothy
from the let's-just-let-the-nsa-sort-it-out dept.
Lucas123 writes "Intel this year plans to sell a set-top box and Internet-based streaming media service that will bundle TV channels for subscribers, but cable, satellite and ISPs are likely to use every tool at their disposal to stop another IP-based competitor, according to experts. They may already be pressuring content providers to charge Intel more or not sell to it. Another scenario could be that cable and ISP providers simply favor their own streaming services with pricing models, or limit bandwidth based on where customers get their streamed content. For example, Comcast could charge more for a third-party streaming service than for its own, or it could throttle bandwidth or place caps on it to limit how much content customer receives from streaming media services as it did with BitTorrent. Meanwhile, Verizon is challenging in a D.C. circuit court the FCC's Open Internet rules that are supposed to ensure there's a level playing field."

Computers can figure out all kinds of problems, except the things in the world that just don't add up.