If you ask me, I think this should be handled in-kernel for may reasons:
1) You need a process running SCHED_FIFO all for sound otherwise. This is OK but you are still at the mercy of the scheduler when you poll.
2) Letting this happen in userspace resulted in several competing APIs and no standard over more than a decade. While for toolkits this is not serious, for audio this is, because the competing APIs require exclusive access to a resource.
3) Resampling, at the best quality and even in a real-time audio process is extremely cheap, and you only need to do it for a single stream.
Which is what my OP is about, what you suggest we've been there, done that and failed. This is simple functionality that should be handled in kernel with a simple API presented to userspace.
This is not really a problem because, even if you wanted to use the most expensive interpolation possible, you can resample your lower-priority audio outside and feed it through a lock-free ringbuffer. This way the deadline constrained realtime audio has no penalty in practice.
Both Windows and OSX handle real-time audio in the way you mention, so you can have something like Jack and system sounds at the same time. OSS from 4front does this same thing.
The problem is that, for this to work, you have to open audio in real-time with the best possible combination of parameters, and this might involve resampling or dithering audio from lowest bit depth or sample rate. The kernel does not support using floating point code, so integer math needs to be used for the resampling.
Despite that most commercial hardware has for ages used fixed point math for this, and that even a simple spline interpolation would do fine for all cases since you are upsampling, most of the "audio gurus" of the linux audio development comunity of the time (like Paul Davis, Steve Harris, etc) convinced the kernel people that there would be a terrible quality loss and it was a bad idea to do this.
So, the situation of the linux kernel audio is one of those situations when instead of designing by use case, it was designed by designers that would prefer a "clean" solution instead of a practical one (that Commercial OSs and hardware implemented).
Neither ALSA (through dmix) nor Jackd can mix both high latency and low latency audio.
Dmix can mix many userspace high latency streams, or one low latency stream but not both.
Jackd is only for low latency
Pulseaudio can mix both, but it's not as efficient as a kernel solution and it's quite dangerous (because it's SCHED_FIFO)
4Front OSS could do both in kernel and it worked extremely well.
Disclaimer: I wrote plenty of open source audio apps for linux, even worked with professional audio hardware with embedded linux.
Pulseaudio is just another victim of the attitude from the linux kernel developers of kicking a problem to userland when they should really be solving it.
Userspace audio mixers are OK for many applications, such as a video player, desktop sounds, listening to mp3s, etc. as long as such applications don't need low latency. If you need videogames, pro-audio stuff, or even real-time video editing you need low latency and here is the problem happens. You need somehow a way to ensure that the low latency audio thread gets notification quickly and gets priority in the scheduler (because the buffers are small), while the regular latency audio just needs to accumulate more data into buffers.
But the problem is, that you have only one DAC, and different streams might request different configuration parameters, such as bit depth, sampling rate, channels, etc. In any serious OS, the kernel will open a stream with the maximum settings for real-time, and will ensure it gets the needed attention, while it mixes and resamples the audio that comes from the regular OS sound buffers over it. Linux kernel developers are against this, and the justification is that resampling should not happen in the kernel. As a result, asks user space to solve the problem. Pulseaudio is an attempt to solve that problem, and does what the kernel should be doing in userspace, but unfortunately it just doesn't work very well. Linux is not a "real time" OS and scheduling can still fuck you your user-space audio.
Back in the day, OSS handled this perfectly, but when it was replaced by ALSA (an extremely bloated and over-designed API and driver architecture) hell began, so please don't blame PulseAudio for this, this is purely the fault of kernel developers.
This article is spot on. Can a line be draw on H1Bs? Disclaimer: I own part of a company in South America and worked for clients all around the world, outsourcing work (yes, I steal your jobs and I don't even need a H1B).
H1Bs are used for cheap labor, but also are vital for bringing more experienced seniorship into American companies (which there really is a lack of, at the pace the industry is growing). I sympathize with the low end of the scale, (It is terrible that a foreigner steals your job), but the high end is being too greedy. If there isn't enough seniorship to supply positions in the industry, don't be happy that your annual income will be doubled. Think instead that you are putting a stop to the industry and instead allow other seniors to be brought from overseas.
If not.. well, American companies will continue turning to outsourcing and help me make a living. Thank you guys!
I know KDevelop is great and used it for a while. However, Qt-Creator will continue being the best open source IDE because it allows to keep working on projects no matter the platform, and has a much broader appeal. How difficult is it to get it to work on something other than Unixes, given Qt is portable?
Not only that, a guy is decapitated by a british speaking terrorist. The timing was just too good, specially because it helped to move the public opinion away from Israel/Gaza. Coincidentally, the moment Hamas stopped getting press they basically surrendered.
apt-get and yum are similar, but Ubuntu Software Center and Update Manager, (as well as the way they handle PPAs) are miles ahead more friendly than Red-Hat's Package Manager.
More than a decade ago, when they abandoned desktop and regular users and only focused on enterprise, they made their biggest mistake. Where do you think Ubuntu Server users come from?
Even most of us who are highly knowledgeable and understand Linux to it's most profound depths appreciate a good desktop experience. The fact we can compile a kernel or any software does not mean we prefer that to a nice end-user experience.
It is still not too late for RedHat, and given the horrible direction Ubuntu has been going recently (trying to run on Phones and Tablets), and the fact that the tablet fad is starting to pass and the desktop did not die (as evidenced by Microsoft's direction with Windows 9), they have a great chance to re-capture the desktop user. They will definitely not be able to do that by supporting Gnome 3 (something a large part of desktop users hate, even if a small minority likes it), and their very unfriendly package manager. They now have Ubuntu as example of how to do some things right, and as proof that this is a desirable business direction.
Unlike Google which uses ownership to determine size used, you can run out of space in DropBox by someone sharing you a large folder. DropBox also make is impossible from the web interface to see the sizes or usage of files to make room or clean up. I ended up paying Google for 100gb because their service is simply better.
Don't worry, the Lithiumpoly mafia will make sure that no alternative energy is economically viable in the next decades, so their business remains intact.
Even if thee free publicity would lead to more people watching and consuming soccer-related products and services in the long run, It's always good to see honorable institutions such as the Premier League inciting everyone to be a good citizen and abide the law, at the cost of them losing money. A true example to follow.
Google "do not be evil" single handedly decided that OpenCL will never run on Android and instead is pushing for their crappy alternative, RenderScript:
How difficult it can it be to agree on this? This way anyone can use any language they wish. It's a win-win situation for Firefox and Google and probably for Microsoft because their underperforming new platforms will get loads of new applications.
I seriously don't get corporations sometimes..
How obvious is it that, in reality, they want to make killer robots? Start with the synthetic memory, then continue with the synthetic consciousness and put it in a highly sophisticated mechanical armature and you have a killer robot.
Everyone is getting into C# because of Unity, but this is actually a trap.
If you want to make a C# game and publish it on mobile without restrictions you have to pay.
The only portable C# implementation that works on mobile (besides Windows Phone) is Mono. Their class library is LGPL, which is in a grey area, Xamarin says:
"Typical examples of commercial licensees include device manufacturers embedding Mono in hardware where the user is not able to independently upgrade the Mono virtual machine from the source code"
This rules out Android and iOS. Unity has a free version but also has restrictions:
Unity Free, which include the free platform add-on products, may not be licensed or used by a commercial entity with annual gross revenues (based on prior fiscal year) in excess of US$100,000, or by an educational, academic, non-profit or government entity with a total annual budget for the entire entity (based on prior fiscal year) in excess of US$100,000.
So, again, make sure you are doing your research well, because you might end up in an unexpected situation.
The best way is to make games first, then see what language do you need later. Most games do not even need something such as C# and what might seem as " more powerful" can also be seem as "more wasted time doing something more complex than needed".
Web browsers should at this point be able to parse some sort of bytecode that can be translated to native. This way anyone can use whatever programming language he or she pleases. Google did a great work with PNaCL, but I don't think that will ever gain traction from the other vendors.
Mozilla's ASM.JS is much better idea and much closer to a real-life usage scenario, but Google itself is not doing enough to promote it and their support is half assed (even though It would definitely benefit them).
> two thirds of the top 2,000 apps in the Google Play Store use natively compiled C code
Of course, how else would one make code portable between platforms? Yet their support for using their native Java API from C or C++ is horrible. JNI is unsafe and crash prone and the NativeActivity is so limited that barely anyhthing can be made with it.
I know it's not a "standard" (yet?) but asm.js is one of the best things that happened to web browsers. It already works well in Firefox, Chrome and Safari, yet performance in IE is much worse than in the other platforms. Given all platforms support WebGL at this point, we are pretty much only waiting for IE to adopt proper support for asm.js.
Regulation? But this is what America is about! the big rich companies are the ones that dictate the regulation. And hiring overseas is MUCH more convenient to them. Why do you think the American government is one of the highest proponents of free trade treaties? I'm surprised you are american and you don't know this. Next time there are elections you can vote the national socialists if you want more labor protectionism, see how it goes.
Slashdot Mirror
If you ask me, I think this should be handled in-kernel for may reasons:
1) You need a process running SCHED_FIFO all for sound otherwise. This is OK but you are still at the mercy of the scheduler when you poll.
2) Letting this happen in userspace resulted in several competing APIs and no standard over more than a decade. While for toolkits this is not serious, for audio this is, because the competing APIs require exclusive access to a resource.
3) Resampling, at the best quality and even in a real-time audio process is extremely cheap, and you only need to do it for a single stream.
Which is what my OP is about, what you suggest we've been there, done that and failed. This is simple functionality that should be handled in kernel with a simple API presented to userspace.
This is not really a problem because, even if you wanted to use the most expensive interpolation possible, you can resample your lower-priority audio outside and feed it through a lock-free ringbuffer. This way the deadline constrained realtime audio has no penalty in practice.
Both Windows and OSX handle real-time audio in the way you mention, so you can have something like Jack and system sounds at the same time. OSS from 4front does this same thing.
The problem is that, for this to work, you have to open audio in real-time with the best possible combination of parameters, and this might involve resampling or dithering audio from lowest bit depth or sample rate. The kernel does not support using floating point code, so integer math needs to be used for the resampling.
Despite that most commercial hardware has for ages used fixed point math for this, and that even a simple spline interpolation would do fine for all cases since you are upsampling, most of the "audio gurus" of the linux audio development comunity of the time (like Paul Davis, Steve Harris, etc) convinced the kernel people that there would be a terrible quality loss and it was a bad idea to do this.
So, the situation of the linux kernel audio is one of those situations when instead of designing by use case, it was designed by designers that would prefer a "clean" solution instead of a practical one (that Commercial OSs and hardware implemented).
4Front OSS, which was later opensourced, could mix both low latency and high latency streams, and the API was *much* simpler and unix-like.
Neither ALSA (through dmix) nor Jackd can mix both high latency and low latency audio.
Dmix can mix many userspace high latency streams, or one low latency stream but not both.
Jackd is only for low latency
Pulseaudio can mix both, but it's not as efficient as a kernel solution and it's quite dangerous (because it's SCHED_FIFO)
4Front OSS could do both in kernel and it worked extremely well.
Disclaimer: I wrote plenty of open source audio apps for linux, even worked with professional audio hardware with embedded linux.
Pulseaudio is just another victim of the attitude from the linux kernel developers of kicking a problem to userland when they should really be solving it.
Userspace audio mixers are OK for many applications, such as a video player, desktop sounds, listening to mp3s, etc. as long as such applications don't need low latency. If you need videogames, pro-audio stuff, or even real-time video editing you need low latency and here is the problem happens. You need somehow a way to ensure that the low latency audio thread gets notification quickly and gets priority in the scheduler (because the buffers are small), while the regular latency audio just needs to accumulate more data into buffers.
But the problem is, that you have only one DAC, and different streams might request different configuration parameters, such as bit depth, sampling rate, channels, etc. In any serious OS, the kernel will open a stream with the maximum settings for real-time, and will ensure it gets the needed attention, while it mixes and resamples the audio that comes from the regular OS sound buffers over it. Linux kernel developers are against this, and the justification is that resampling should not happen in the kernel. As a result, asks user space to solve the problem. Pulseaudio is an attempt to solve that problem, and does what the kernel should be doing in userspace, but unfortunately it just doesn't work very well. Linux is not a "real time" OS and scheduling can still fuck you your user-space audio.
Back in the day, OSS handled this perfectly, but when it was replaced by ALSA (an extremely bloated and over-designed API and driver architecture) hell began, so please don't blame PulseAudio for this, this is purely the fault of kernel developers.
But high wages ARE caused by job shortage.
This article is spot on. Can a line be draw on H1Bs?
Disclaimer: I own part of a company in South America and worked for clients all around the world, outsourcing work (yes, I steal your jobs and I don't even need a H1B).
H1Bs are used for cheap labor, but also are vital for bringing more experienced seniorship into American companies (which there really is a lack of, at the pace the industry is growing). I sympathize with the low end of the scale, (It is terrible that a foreigner steals your job), but the high end is being too greedy. If there isn't enough seniorship to supply positions in the industry, don't be happy that your annual income will be doubled. Think instead that you are putting a stop to the industry and instead allow other seniors to be brought from overseas.
If not.. well, American companies will continue turning to outsourcing and help me make a living. Thank you guys!
I know KDevelop is great and used it for a while. However, Qt-Creator will continue being the best open source IDE because it allows to keep working on projects no matter the platform, and has a much broader appeal. How difficult is it to get it to work on something other than Unixes, given Qt is portable?
Not only that, a guy is decapitated by a british speaking terrorist. The timing was just too good, specially because it helped to move the public opinion away from Israel/Gaza. Coincidentally, the moment Hamas stopped getting press they basically surrendered.
apt-get and yum are similar, but Ubuntu Software Center and Update Manager, (as well as the way they handle PPAs) are miles ahead more friendly than Red-Hat's Package Manager.
More than a decade ago, when they abandoned desktop and regular users and only focused on enterprise, they made their biggest mistake. Where do you think Ubuntu Server users come from?
Even most of us who are highly knowledgeable and understand Linux to it's most profound depths appreciate a good desktop experience. The fact we can compile a kernel or any software does not mean we prefer that to a nice end-user experience.
It is still not too late for RedHat, and given the horrible direction Ubuntu has been going recently (trying to run on Phones and Tablets), and the fact that the tablet fad is starting to pass and the desktop did not die (as evidenced by Microsoft's direction with Windows 9), they have a great chance to re-capture the desktop user. They will definitely not be able to do that by supporting Gnome 3 (something a large part of desktop users hate, even if a small minority likes it), and their very unfriendly package manager. They now have Ubuntu as example of how to do some things right, and as proof that this is a desirable business direction.
Unlike Google which uses ownership to determine size used, you can run out of space in DropBox by someone sharing you a large folder. DropBox also make is impossible from the web interface to see the sizes or usage of files to make room or clean up. I ended up paying Google for 100gb because their service is simply better.
Don't worry, the Lithiumpoly mafia will make sure that no alternative energy is economically viable in the next decades, so their business remains intact.
And are not trendy anymore. I don't think Chromebooks are only appealing because the hardware is cheap..
Even if thee free publicity would lead to more people watching and consuming soccer-related products and services in the long run, It's always good to see honorable institutions such as the Premier League inciting everyone to be a good citizen and abide the law, at the cost of them losing money. A true example to follow.
Google "do not be evil" single handedly decided that OpenCL will never run on Android and instead is pushing for their crappy alternative, RenderScript:
https://code.google.com/p/andr...
No matter how valid the arguments of those who favor OpenCL are, Google just answers with FUD.
How difficult it can it be to agree on this? This way anyone can use any language they wish. It's a win-win situation for Firefox and Google and probably for Microsoft because their underperforming new platforms will get loads of new applications. I seriously don't get corporations sometimes..
How obvious is it that, in reality, they want to make killer robots? Start with the synthetic memory, then continue with the synthetic consciousness and put it in a highly sophisticated mechanical armature and you have a killer robot.
We are doomed.
"Typical examples of commercial licensees include device manufacturers embedding Mono in hardware where the user is not able to independently upgrade the Mono virtual machine from the source code"
This rules out Android and iOS. Unity has a free version but also has restrictions:
Unity Free, which include the free platform add-on products, may not be licensed or used by a commercial entity with annual gross revenues (based on prior fiscal year) in excess of US$100,000, or by an educational, academic, non-profit or government entity with a total annual budget for the entire entity (based on prior fiscal year) in excess of US$100,000.
So, again, make sure you are doing your research well, because you might end up in an unexpected situation.
The best way is to make games first, then see what language do you need later. Most games do not even need something such as C# and what might seem as " more powerful" can also be seem as "more wasted time doing something more complex than needed".
Web browsers should at this point be able to parse some sort of bytecode that can be translated to native. This way anyone can use whatever programming language he or she pleases. Google did a great work with PNaCL, but I don't think that will ever gain traction from the other vendors.
Mozilla's ASM.JS is much better idea and much closer to a real-life usage scenario, but Google itself is not doing enough to promote it and their support is half assed (even though It would definitely benefit them).
> two thirds of the top 2,000 apps in the Google Play Store use natively compiled C code
Of course, how else would one make code portable between platforms? Yet their support for using their native Java API from C or C++ is horrible. JNI is unsafe and crash prone and the NativeActivity is so limited that barely anyhthing can be made with it.
I know it's not a "standard" (yet?) but asm.js is one of the best things that happened to web browsers. It already works well in Firefox, Chrome and Safari, yet performance in IE is much worse than in the other platforms. Given all platforms support WebGL at this point, we are pretty much only waiting for IE to adopt proper support for asm.js.
Regulation? But this is what America is about! the big rich companies are the ones that dictate the regulation. And hiring overseas is MUCH more convenient to them. Why do you think the American government is one of the highest proponents of free trade treaties? I'm surprised you are american and you don't know this.
Next time there are elections you can vote the national socialists if you want more labor protectionism, see how it goes.