On 03/02/2011 02:27 PM, Paul Davis wrote:
> On Wed, Mar 2, 2011 at 8:20 AM, Olivier Guilyardi wrote:
>> With this method, notably used by game devs, there's one code base, with thin
Okay, well, I'm not into game development. I just mentioned that because there
are a few game devs who actually rely on that kind of portable toolkit on
Android. But I have no clue of what's really involved in highly complex games.
Now, this discussion is more about audio and music apps.
What I meant is to have the portable code base expose:
And now, yes of course, you need thin drivers which calls this function. And if
you want to support 4 platforms, you may need a dozen of drivers, yeah, but it
sounds ok to me, as long as all the logic resides in the portable code base.
At least in my very case, this should allow me to perform audio I/O on any
mobile and non-mobile platform I can think of.
>> But this later problem could be solved with a simple audio-oriented UI toolkit,
First 5 years is a real lot of time when it comes to computing. I think that
it's very risky to predict what will happen. Maybe you're right about technical
limits evaporating, or maybe that technical approaches will take entirely new
Also, if you are talking about the browser limits, well, browsers are getting
more and more advanced, web UIs are used in a variety of cases, yes. But the
more powerful the machines become, the more audio applications will need to be
powerful as well. And there always will be a gap between native optimized code
and high level interpreted stuff. At least in the foreseeable future.
Also, my OpenGL idea, although merely brainstorming so far, is not only
applicable right now. It could also allow to build innovative 3D audio UIs. You
could even embed 2D plugins UIs into a 3D scene.
My point about OpenGL wasn't only about optimization. It just appears to be very
portable, and yes also suitable for high-performance UIs today. And it seems to
me like it can only get better in the future.
Linux-audio-dev mailing list