I'm not saying it's not fast, I'm saying that tight timing related things (like nano sleeps to wait until the soundcard buffers are ready to be filled again) have too much jitter to be useful.
I can happily get 10 ms audio latency in Java, but going any lower is where it just doesn't cut it. Letting the thread busy wait isn't really an option when the machine has to be doing other things at lower priority too.
In short, using Java's nanosleep with tight timing tolerances seems to randomly get wakeup jitter when the VM chooses to do some internal stuff. This is with a no-allocation loop confirmed with tracing tools.
My best guess from profiling the system calls is that Java is doing some mutex related things that's causing the jitter. I neither have the time nor inclination to "fix" this problem, as the solution is quite simple. Write it in a language where I have control over it.
Don't forget, fast != predictable and that's where C/C++ earns its paycheck.
Unfortunately, when you really get down to it you will have similar problems in C or C++.
Not quite - I do realtime audio processing and when you get down to millisecond / submillisecond timing issues, you simply can't do this in standard Java - even when using a no-allocation loop (as you mention). I know, I've tried apples to apples.
You can go down the route of using the special realtime JVM as I mentioned above, but then you get other problems (you're not really writing Java, you can't use any of the standard libraries etc).
I prototype my audio stuff in Java, simply because writing and debugging the DSP code is so much easier with good tools, but the bare metal implementation is C++.
That's why Vuze doesn't have an integrated video player or a native, cross platform GUI.
Given Vuze does have (kinda) those things, I assume you're advocating that Java does?
I'd hardly say using third party toolkits and/or native blobs written in another language (for both of those you mention) adds weight to the strengths of Java....
In fact, it confirms what I said - you don't do those things in Java.
Fair points but I'd say there's a few places that Java just doesn't cut it - strict scheduling and / or real time needs. O, and GUI stuff, too.
So basically, no GUI, no audio, no video. Which only more or less leaves what it currently is king of the hill for - server side business processing.
I've tried real time and Java, and the jitter that garbage collection introduces (yes, even with parallel garbage collection and all that stuff) makes it hugely unpredictable.
Strangely enough, the company formerly known as SUN knew this, and tried to create a "real time" flavour of Java with such extensions - but it takes so much effort to port your code (and the JVM is slightly less than brilliant) that you're far better off going to C/C++.
Yeah, but if you go down that path, you wind up with mathematics being nothing but a tool, more a part of the process of science than science itself.
It's an interesting point that gave me pause. Without doubt it is a tool, but I'm not sure that it's a given that research around the tool isn't science.
Your suggestion started to make me consider science as only being related to subjects with probabilities where we can measure and test how close we are getting - but my gut is saying that view is too narrow.
I won't dispute the thin air plucking of axioms - but that wasn't what the original poster alluded to - with which you swept all of science under the same rug:
Their only connection to science is that they attempt to use statistics, often improperly.
My point remains that Mathematical logic (alone?) is a science concerned with tautological proofs, not based on "closest enough" statistical significance.
I think the real problem with "refusing to buy their products" is the fact you still have the rest of society that are continuing to buy their products - perpetuating these dynosaurs.
Their view on piracy as lost sales partly comes from the fact that people do indeed still pay for and want these products at the prices they choose.
Until there is enough of a majority of the population that it truly breaks their business model they'll keep on I suspect.
One last thing since you commented on the google bug.
This isn't really an Android issue, it is down the phone manufacturers not supplying high end audio hardware. What do you expect from sub £500 phones and tablets?
Are you really saying that Apple is shipping high end audio hardware where android manufacturers can't?
First time around I compiled a custom kernel to get raw ALSA and managed around 10ms latency - where Android gives me 200ms!
I haven't got time to fix google's audio layers - I've got better things to do.
(Aside - Slashdot still can't do UTF8 in 2011? Shame on you, Slashdot)
I noticed you didn't actually technically retorn anything, just some hand waving.
(*) That list of requirements isn't mine. Because you disagree with one of the points doesn't negate the general need to fix the problem. Android audio SUCKS.
(*) Saying "Android phones will never be super-duper studio level audio grade equipment" is one valid point - but then moving the latency high enough an old Pentium II 800 Mhz with integrated audio can beat it sounds pretty poor.
(*) These days, sound cards / audio devices ARE up to the job, this is crappy software layers getting in the way of letting us talk to the hardware.
Why do you give Android a free pass? Invested in it?
The Android that phone builders download and customise is based on Alsa in the kernel - but Android doesn't define access to ALSA in any way (and the phone manufacturers could use something completely different.)
The audio "layers" (and it really is that) are quite complex, with OpenSL along with the defined Java sound APIs as the only userspace methods to play sound.
Unfortunately due to the way the layers are defined (multiple mixers for various devices, incoming call interrupt etc) it's not "Alsa" available in userspace and you can't rely on that being there.
So to answer your question:
(yes) Jack could be compiled on Android - but the use of Alsa is not necessarily reliable and/or available on all devices.
(no) Using native Alsa might not solve the audio latency problems - since that's a function of audio buffer size and throughput.
Don't ask me why, but Google define 45ms as low latency....... Meanwhile, in Apple Land, both the iPhone and iPad are happily realtime audio scheduling around 4-5ms...
The difference is only in the technology, and the ease of use.
I'd personally go a little further - there is also the (perceived) anonymity and freely available nature of the required equipment.
* Everyone (more or less) has the necessary PC and internet connection nowadays - previously shelling out for the 8-track _and_ the record player was a larger barrier to entry and along with the required physical effort and time made the activity non-casual.
* Trading physical things vs the internet p2p model offers some perceived anonymity. It's not really the case (unless you are going the TOR or freenet route) of course. This does make people more comfortable / confident in using it.
I'm not saying it's right, just wanted to add to the reasons why this generation seem to be more invested in it than previous generations who seemingly had the same opportunities.
As long as you're not seduced by template fuckery (You know who you are, "lets factor prime numbers at compile time" template people!) or dynamic link libraries, it's a fine language!
I agreed with you until you discourage dynamic link libraries.
I'm someone currently making the move back to C++ from Java (reason - predictable scheduling) after 10 years in the J jungle. If you don't have dynamic libraries how would you do plugins? (Never mind that dynamic libraries are necessary for anything larger that a simple standalone application.)
Admittedly the tooling for building is still messy (autotools work, sure, but are a pain to have to deal with).
As an aside, the new c++0x features have really changed C++ from the "new" "delete" fiasco I remember from 1995. STL plus boost makes C++ rather natural and use of threads is pleasant after I previously had to jive with pthreads.
So you are saying you're willing to pay some scratch for it (rental).
This is it's worth to you, crappy movie or not.
The fact you indulge in pirate downloading actually validates some of their arguments (you acknowledge it has _some_ worth, but take the convenience route).
The best thing that can happen to the open source / free software movement is that enforceable / unbreakable DRM exists - so idiots like you who think convenience justifies pirating content can't play your pirated games or movies any more. (This also goes for Office, Windows etc)
If you had to pay the real price for the things you pirate - you wouldn't - so it clearly isn't worth that much to you, right?
O wait, I forgot, we have a few generations now who believe they should get stuff for free. Sure you should, but only the things people have decided they want to give you for free.
With shutter based technology you halve the framerate. Polarised glasses halve the resolution.
Being a pendant - this isn't true.
It's the use of screen-field polarisation that halves the resolution (having a filter infront of the LCD that polarises even pixels one way, odd pixels the other).
There is nothing stopping for example two full resolution polarised screen images over the same screen real estate having full resolution.
TL;DR - it's not the glasses that halve the resolution - it's the choice of the screen / projection technology.
Slashdot Mirror
I'm not saying it's not fast, I'm saying that tight timing related things (like nano sleeps to wait until the soundcard buffers are ready to be filled again) have too much jitter to be useful.
I can happily get 10 ms audio latency in Java, but going any lower is where it just doesn't cut it. Letting the thread busy wait isn't really an option when the machine has to be doing other things at lower priority too.
In short, using Java's nanosleep with tight timing tolerances seems to randomly get wakeup jitter when the VM chooses to do some internal stuff. This is with a no-allocation loop confirmed with tracing tools.
My best guess from profiling the system calls is that Java is doing some mutex related things that's causing the jitter. I neither have the time nor inclination to "fix" this problem, as the solution is quite simple. Write it in a language where I have control over it.
Don't forget, fast != predictable and that's where C/C++ earns its paycheck.
Unfortunately, when you really get down to it you will have similar problems in C or C++.
Not quite - I do realtime audio processing and when you get down to millisecond / submillisecond timing issues, you simply can't do this in standard Java - even when using a no-allocation loop (as you mention). I know, I've tried apples to apples.
You can go down the route of using the special realtime JVM as I mentioned above, but then you get other problems (you're not really writing Java, you can't use any of the standard libraries etc).
I prototype my audio stuff in Java, simply because writing and debugging the DSP code is so much easier with good tools, but the bare metal implementation is C++.
That's why Vuze doesn't have an integrated video player or a native, cross platform GUI.
Given Vuze does have (kinda) those things, I assume you're advocating that Java does?
I'd hardly say using third party toolkits and/or native blobs written in another language (for both of those you mention) adds weight to the strengths of Java....
In fact, it confirms what I said - you don't do those things in Java.
Fair points but I'd say there's a few places that Java just doesn't cut it - strict scheduling and / or real time needs. O, and GUI stuff, too.
So basically, no GUI, no audio, no video. Which only more or less leaves what it currently is king of the hill for - server side business processing.
I've tried real time and Java, and the jitter that garbage collection introduces (yes, even with parallel garbage collection and all that stuff) makes it hugely unpredictable.
Strangely enough, the company formerly known as SUN knew this, and tried to create a "real time" flavour of Java with such extensions - but it takes so much effort to port your code (and the JVM is slightly less than brilliant) that you're far better off going to C/C++.
Yeah, but if you go down that path, you wind up with mathematics being nothing but a tool, more a part of the process of science than science itself.
It's an interesting point that gave me pause. Without doubt it is a tool, but I'm not sure that it's a given that research around the tool isn't science.
Your suggestion started to make me consider science as only being related to subjects with probabilities where we can measure and test how close we are getting - but my gut is saying that view is too narrow.
I won't dispute the thin air plucking of axioms - but that wasn't what the original poster alluded to - with which you swept all of science under the same rug:
Their only connection to science is that they attempt to use statistics, often improperly.
My point remains that Mathematical logic (alone?) is a science concerned with tautological proofs, not based on "closest enough" statistical significance.
dig deep enough, and you find out all the other 'sciences' suffer from exactly the same problems.
As a recovering Mathematician I take issue with that.
Hint: There is one science founded (mostly) on logic that doesn't let reality get in the way of quality navel gazing.
I think the real problem with "refusing to buy their products" is the fact you still have the rest of society that are continuing to buy their products - perpetuating these dynosaurs.
Their view on piracy as lost sales partly comes from the fact that people do indeed still pay for and want these products at the prices they choose.
Until there is enough of a majority of the population that it truly breaks their business model they'll keep on I suspect.
Nautilus seems to be missing some crucial components at this point, like letting me associate a program of my choice to a certain file type.
Find a file of the type you want to associate - right click properties -> opens with
I know, it's not immediately obvious, but the functionality is there.
One last thing since you commented on the google bug.
This isn't really an Android issue, it is down the phone manufacturers not supplying high end audio hardware. What do you expect from sub £500 phones and tablets?
Are you really saying that Apple is shipping high end audio hardware where android manufacturers can't?
First time around I compiled a custom kernel to get raw ALSA and managed around 10ms latency - where Android gives me 200ms!
I haven't got time to fix google's audio layers - I've got better things to do.
(Aside - Slashdot still can't do UTF8 in 2011? Shame on you, Slashdot)
Gibberish - the things he pointed out he copy pasted from the android bug I linked to THAT I DIDN'T WRITE.
And no, he hasn't shown any such thing that hardware is the issue.
And you failed to read anything I said.
Jeez the Android fanboys are out in force today.
I noticed you didn't actually technically retorn anything, just some hand waving.
(*) That list of requirements isn't mine. Because you disagree with one of the points doesn't negate the general need to fix the problem. Android audio SUCKS.
(*) Saying "Android phones will never be super-duper studio level audio grade equipment" is one valid point - but then moving the latency high enough an old Pentium II 800 Mhz with integrated audio can beat it sounds pretty poor.
(*) These days, sound cards / audio devices ARE up to the job, this is crappy software layers getting in the way of letting us talk to the hardware.
Why do you give Android a free pass? Invested in it?
The Android that phone builders download and customise is based on Alsa in the kernel - but Android doesn't define access to ALSA in any way (and the phone manufacturers could use something completely different.)
The audio "layers" (and it really is that) are quite complex, with OpenSL along with the defined Java sound APIs as the only userspace methods to play sound.
Unfortunately due to the way the layers are defined (multiple mixers for various devices, incoming call interrupt etc) it's not "Alsa" available in userspace and you can't rely on that being there.
So to answer your question:
(yes) Jack could be compiled on Android - but the use of Alsa is not necessarily reliable and/or available on all devices.
(no) Using native Alsa might not solve the audio latency problems - since that's a function of audio buffer size and throughput.
Don't ask me why, but Google define 45ms as low latency....... Meanwhile, in Apple Land, both the iPhone and iPad are happily realtime audio scheduling around 4-5ms...
Yeah sadly it's a general latency problem with Android that doesn't seem to get mentioned.
I write audio software and it's the poor red headed stepchild of IOS in comparison:
http://code.google.com/p/android/issues/detail?id=3434
Yeah but no, but yeah. But no.
build a 520 mile-high speed rail
it gives great views from up that far - plus the pumping music and free drugs is certainly something I'd get behind.
If you can be more productive than a single click to a fixed point on my monitor, I'm sold.
I know it's not Gnome/KDE/LXDE/... specific, but I find key bindings work for me.
<ctrl><f1> launches new terminal ....
<ctrl><f2> launch new browser window
<ctrl><f3>
Actually I've got a keyboard with "G" keys (18) that I use (logitech G15) and that works a treat.
Meanwhile - outside the U.S. of A....
We can't see them in the U.K. or Ireland, where we only get "chosen" episodes.
Same goes for Comedy central shows like Jon Stewart + Colbert.
Gee, you guys are getting me all misty eyed for the old slashdot.
Browsing at -1 used to be such fun here, but kudos to Taco he really killed the fun off.
Now I'm going to go drink a bottle of whisky and jerk off my cat.
Release 8.2; Feb. 24 2011 released and expected EOL is Feb. 29 2011. That is one year.
It's 5 days.
You haven't heard? They're trying to beat Ubuntu for release early release often.
Best of luck to them I say!
The difference is only in the technology, and the ease of use.
I'd personally go a little further - there is also the (perceived) anonymity and freely available nature of the required equipment.
* Everyone (more or less) has the necessary PC and internet connection nowadays - previously shelling out for the 8-track _and_ the record player was a larger barrier to entry and along with the required physical effort and time made the activity non-casual.
* Trading physical things vs the internet p2p model offers some perceived anonymity. It's not really the case (unless you are going the TOR or freenet route) of course. This does make people more comfortable / confident in using it.
I'm not saying it's right, just wanted to add to the reasons why this generation seem to be more invested in it than previous generations who seemingly had the same opportunities.
I agreed with you until you discourage dynamic link libraries.
I'm someone currently making the move back to C++ from Java (reason - predictable scheduling) after 10 years in the J jungle. If you don't have dynamic libraries how would you do plugins? (Never mind that dynamic libraries are necessary for anything larger that a simple standalone application.)
Admittedly the tooling for building is still messy (autotools work, sure, but are a pain to have to deal with).
As an aside, the new c++0x features have really changed C++ from the "new" "delete" fiasco I remember from 1995. STL plus boost makes C++ rather natural and use of threads is pleasant after I previously had to jive with pthreads.
O I see it, I just don't see the current approach (piracy) as changing the status quo in any way.
All you are doing is encouraging the **IA to enforce harsher penalties and stricter control.
Not funding or pirating the content at all would be the way to change it. But people _need_ their pirated games and movies, right?
So you are saying you're willing to pay some scratch for it (rental).
This is it's worth to you, crappy movie or not.
The fact you indulge in pirate downloading actually validates some of their arguments (you acknowledge it has _some_ worth, but take the convenience route).
The best thing that can happen to the open source / free software movement is that enforceable / unbreakable DRM exists - so idiots like you who think convenience justifies pirating content can't play your pirated games or movies any more. (This also goes for Office, Windows etc)
If you had to pay the real price for the things you pirate - you wouldn't - so it clearly isn't worth that much to you, right?
O wait, I forgot, we have a few generations now who believe they should get stuff for free. Sure you should, but only the things people have decided they want to give you for free.
Being a pendant - this isn't true.
It's the use of screen-field polarisation that halves the resolution (having a filter infront of the LCD that polarises even pixels one way, odd pixels the other).
There is nothing stopping for example two full resolution polarised screen images over the same screen real estate having full resolution.
TL;DR - it's not the glasses that halve the resolution - it's the choice of the screen / projection technology.
Sorry but I'm paranoid, maybe I'm doing stuff already done, but maybe, just maybe, it's new stuff.
I'm not renting or placing my data on servers I can't trust.
This means "the cloud", "virtual server" or anything where I can't get root and play with the file system key.
Yeah, it's a pain in the butt, but I've noticed how "aggressive" the U.S. is in maintaining no 1 at all costs.