Considering most large enterprise distros (RHEL, SUSE, etc) ship with KDE as the main DE
While that might have been the case some time ago, for quite a while now most of the major distro's have been heavily focused on gnome
Kubuntu plays second fiddle to ubuntu, and a lot of ubuntu users have never even heard of it before. On fedora while kde is still well supported the default install does gnome, etc.
Have you filed bug reports and tried to help fix the issues, or are you just complaining uselessly?
The problems I had were known existing ones, so why submit an identical bug report when one already exists? (yes I actually checked their bug database for it before submitting)
While I could provide stack traces and debugging information, I have no doubt they already have this. Also before you say I should start fixing it myself, while I do occasionally help maintain OSS software, this is specialized enough and enough of a core service for me to know when to leave it to people whom sound coding is their specialty.
If it's a known issue with that level of severity and not already fixed, somebody with not a terribly good knowledge of the codebase would likely find it a gigantic waste of time trying. Even if I succeeded the cost (in time) to benefit simply isn't there.
As it stands everything I like except flash supports jack, but the kinds of programs I use aren't even dependent on QT/GTK so my usage is abnormal. I just tend to see pulseaudio as superfluous, the tasks it is useful for jack is better at, the only main advantage it has is very good support for oss/alsa/esd/arts backwards compatibility, which as direct backends are basically all heavily deprecated anyway.
"Linux has enabled a weak form of ASLR by default since kernel version 2.6.12"
Very little information about the faults of the default ASLR seems to be readily available.
Although while hunting I did learn linux has a software implementation of the NX bit if you don't have it in hardware, which is nice. Nothing on the details of why the windows implementation is superior emerged.
It is odd for the kernel guys to accept something which isn't the superior design choice, they are perfectionists like that to an extent.
same here, been using this desktop keyboard for about seven years, only rebooting for new kernels, num lock always on, just put caps lock on and they are the same brightness.
That is likely because you don't do anything that requires low latency, even with high latency you won't be able to tell while watching youtube or movies if it's been done right.
Other tasks like live midi stuff tend to require low latency or it will sound extremely off.
PA and jack can coexist (and the developers of both have been working together for some time now to ensure this is so)
Yes, they have been trying to work together, but serious question have you ever tried this setup? It's not pretty, the pulse audio sink for jack has a myriad of problems, and most of the time it just plain doesn't work.
This may improve in future, but for now it is extremely hit or miss, with most of the time being miss.
Feel free to read up on things so you understand them before posting.
if you have to have tactile feedback then how do you use a touchpad that is on every single laptop sold? The touchpad provides no tactile feedback until you click it. Are laptops useless to you too?
Quite simple, on a laptop I look at the screen, with my n95 I can quite successfully navigate and do as I wish without ever looking at the screen. An ability which I do need of my phone at times. An ability which the iPhone utterly lacks.
the N95 while half way decent, has a horrible user interface, one that is cumbersome, hard to navigate, and can't be done with simple motions.
People have dealt with phones with menu systems for far longer than even the basic smartphone existed. I have given people my phone to use, for typical phone usage it is instant, push numbers and press a green button to call, Similar with sms. It is difficult to be more simpler than that.
While I'd agree the iPhone is a great pda, it is utterly horrible as a phone.
For anyone with a short memory consider the repealed alcopop tax in 2009,
Even though it had never passed, they are still collecting it, and since a small shift of power has occurred, they are reintroducing it and are pretty sure it will pass this time.
At least they acknowledge it will do nothing for binge drinking, just makes people buy bottles of spirits. To qoute them "we need the money".
The bigger concern is that they can introduce such things without any legislation passing and have it effectively stick over multiple years
Unfortunately, as long as payback on a hybrid is 7-15 years, the only people adopting them will be the ones that can't do math.
I'd be willing to pay the extra to purchase something that paid the extra off in savings in that time, so long as it's a quality vehicle I don't see anything wrong with keeping a car 15 years+.
The idea of buying things and then tossing them when there is something shinier is part of the problem with our current wastefulness.
The only reason I'm not looking at one currently is because the technology is still being developed, and I can already get 72 miles per gallon on my motorcycle, using only petrol.
Nokia N95, more useful as an actual phone and does anything you'd like, web browser is excellent. Predates the iPhone, and no need to jailbreak, you can load any kind of native apps you like.
Are apple products perfect nope, not at all, however at the end of the day they work better than just about everyone else's, for the same price.
A phone without some form of tactile feedback is useless to me, so it depends highly on your needs
MSFT forced hardware to be standariesed.
No, they didn't, IBM made an open standard (except for the bios.. which was quickly reverse engineered), that every man and his dog replicated
And what third world country do you live in to get "network busy" at any time except during a disaster? I am 26 and have never experienced it myself although I know it happens.
I'm 22 and I've seen it before, ever seen 200 people trying to do voice calls simultaneously within 20x20m, the towers don't like it. It wasn't an emergency either.
Are the laws people break in their homes likely to cause me to die? No?
Murders happen in homes all of the time.. having a video camera wouldn't stop it, but neither would having a video camera in the car prevent someone from speeding/crashing etc, only providing proof after the fact.
Awesome video with a performance done live, she uses several softsynths on the mac pro, the red led button thing you see is a monome, a midi controller, using ableton she samples her own voice then proceeds to use it in a soft synth along with the other bits and pieces.. if the delay between midi button being pressed and it getting sent to the audio card is 20msec+ as you would indicate, she would have to delay the master out to take that into account, and it would look horrendously out of sync on TV.
You're usage completely different to this, but what we are doing is done all the time, by all sorts of performers, it's the normal setup now. And it does require low latency. Which was initially what started this.
Yes, I mentioned that there's soundfont crap in the hardware driver, i.e. instead of letting a coprocessor do the work with $MEGABYTES loaded to sound card and $BYTES sent to it, we use the CPU to render $MEGABYTES and transfer it over the PCI bus to the sound card. Just moving the latency around and inflating the bandwidth usage.
you still incur the latency from cpu to sound card no matter what, but with sound card soundfonts you are traversing it multiple times because the cpu still has to feed the count card instructions to do what it wants to do. It is a lot more efficient to only incur that penalty once, and with a tiny enough buffer (256 samples I think in the case of 4msec) being constantly fed. It is minimized.
You'll never get rid of it, but it is a great deal less than what you would have formerly had. Things in cpu/ram have far less latency working with eachother than they do working with something on the pci bus. Tens of thousands of cycles can pass before you can do a single thing with pci.
Yes, this is true. I don't think any software allows you to adjust individual sources (or tracks even) for latency, i.e. tell it your MIDI device has 20mS latency and your direct WAV output has 0mS latency, and let it auto-correct everything. This would be useful.
Your midi devices should be synchronized with the master clock, a 20msec lag to the sequencer is insanely high, again from button pressed to your ears, 11 or 12ms is acceptable, lower, about 6 or so is ideal.
what else do we have here, Apple's take on software synthesizer latency which also says 6msec or so is ideal, lower is better etc. Note that this is all about the sound card buffer latency, none of the other parts (soft synth, midi input) are taken into account, because they are almost nothing in comparison.
Not physically possible. In one setup you may have SWXG-1000 Yamaha MIDI synthesizer program running, which has its own latency response, typically 50mS or more (I've seen it non-functional at anything below 120mS for real-time playback on an idle 1GHz CPU). In another you may use an external rack-mounted MIDI synthesizer, which means you have PCI bus latency, out through the USB host controller latency, out through a USB-serial adapter at some end, programming a MIDI sequencer in real time, which then has to fast-calculate things and produce output. This isn't instant.
Well people are doing 'the impossible' every day for their typical setups. It isn't instant, but if you can get everything from one end to being output in under 10msec, you're set. Ask anyone using a midi keyboard hooked up to logic with soft synths, which is a very common setup these days.
You're saying the setup I have is impossible, as is that of easily 90% of the users of apple's logic software that heavily use midi with soft synths. Latency has a massive effect on how you play when it sounds 'off'
that's a lot of heavy post-processing for a problem which if you use modern technology and something with low latencies you really just won't have to deal with at all at that stage
The main difference in our opinions though comes from the rather different way you're doing things, which is a great deal more difficult and might have been necessary a decade ago.
Prime example is the idea of loading soundfonts on to a sound card, it isn't done that way these days for a myriad of reasons, pci bus latency being a main one. Flexibility another. Hardware midi with soundfonts on a sound card isn't even seen as something beneficial now.
These days everything is integrated, volumes for individual tracks etc are adjusted easily even in midi form while you're working on it and playing with it. no need to render it to a fixed saved waveform until you're completely done, it can do whatever you like in real-time.
Even with something really low-end, you see the problem: the MIDI tracks get way out of sync with the sampled tracks, and it sounds like garbage. It takes very esoteric efforts to fix this, and then you have i.e. 20mS latencies within the soundfont processing crap of the sound card, or within the hardware driver; or HUGE (120mS) latencies in software synthesizers like SWXG-1000. Everything gets way out of sync.
with the 4msec jack latency i mentioned, with everything as it should be that's all the latency you'll ever get. (ok to be pedantic you could maybe add 1msec for usb polling for the midi device you're using if you are) This is an advantage of the heavy integration of everything.
Mastering pre-done waveforms is still a handy skill of course, chances are you'll deal with analogue instruments at some stage. But might i heavily recommend you look into some of the more modern ways of making music electronically? things aren't what they were like a decade ago, where what you have said would have been necessary
accidentally forgot, reference on how the audio latency effects midi users, here they claim you can usually hear above 6msec, but most people don't seem to notice until about 16 or so, still 50msec is almost 4x that
as with all things, depends on your setup, but a good jack setup can go as low as 4msec, pulseaudio seems to be around 50msec or so.
Do the mixing in your application and output it to ALSA.
And your proposal to have multiple sound applications interact is?
"Professional" audio amateurs seem to all be n00bs, using their recording device (computer) for playback whereas real "professionals" use monitors, metronomes, visual cues, and master tracks.
Err... you seem to be implying that there is an analog audio in that these people are using the pc to record and play back... almost never the case.
These people are sequencing midi on the computer, and rendering it to sound with custom synthesizers. After about 16msec you can HEAR the latency, 50msec is just useless. The workflow you described works well, for analogue, but it just is not the kind of work these people are using their computers for.
"Use jack" is not an option. Not everything works with jack.
serious question, what didn't you manage to get going with jack? with a bit of tinkering I can get pretty much everything going, initial setup from pulse audio is a bitch though.
OSS made it impossible to play more than one stream at once on a lot of hardware.
With a standard configuration, alsa does also, you have to load the dmix module in your config to act as a software mixer on cards that don't do hardware mixing (most on board bits).
This is where the userspace demons enter it all, most of them just started out as another layer that does software mixing, but every man and his dog came up with his own invention.
As for just using alsa, that's great if you don't mind not having certain functionality, some of the sound demons do add some nice features (jack is the only one I've found worth using though). It could be argued the driver layer shouldn't have to deal with some of that advanced functionality though, another reason why these demons were made.
it is a good API and it IS the future of Linux desktop audio,
The future of linux audio it may be.. but good is questionable, no person using their linux machine for synths or midi would touch pulseaudio with a ten foot pole, jack is far superior with a lot less latency, but only applications designed for pro audio use tend to utilize it.
When this transitional period we are currently in is over, everyone will be much better off.
The latency incurred by pulse audio is horrendous, for youtube or movies that's fine, for gaming it's questionable, for music production it's nasty. These days completely removing pulseaudio and getting it all going again is quite an effort.
I can't imagine everyone being much better off, only those who want sound who don't care about the latency or from the music peoples perspective functionality.(jack can do a lot of things pulse can't do)
It really wasn't, depending on your needs of course. If oss were good enough alsa would not have been invented.
Pretty much all cards are handled by alsa in the kernel back end of things, that is pretty standardised etc, the whole problem is the sound server or userspace demon that handles mixing and other bits. PulseAudio was a band aid with horrible latency, Only professional apps tend to support jack. aRts and esd at least seem to have died out when most popular kde and gnome distro's both went to pulseaudio though.
But more or less, nothing in the kernel will fix sound, it's a userland problem.
Not really, the driver people aren't really the same as those who would be researching new and exciting ways to do what we already do. For quite a long time now driver development has been the majority of what the linux kernel development is.
Of course, every now and then they make something new like mac80211, but all that really achieves is more efficient code re-use and testing, which is always good but is still just driver development.
All the simple things an operating system kernel has to do hasn't changed over the last ten or so years, just the hardware has. Operating system theory was pretty much perfected back in the 60's
Also Linux isn't standard. What applies to RedHat doesn't apply to Gentoo and so on. No way you can support all the different distros.
From a CLI perspective, there are extremely few differences between distros and always have been, they mostly all use the GNU userland bits with the only notable but easy differences being choice of package manager and having real root vs sudo etc, trivial things.
Slashdot Mirror
Considering most large enterprise distros (RHEL, SUSE, etc) ship with KDE as the main DE
While that might have been the case some time ago, for quite a while now most of the major distro's have been heavily focused on gnome
Kubuntu plays second fiddle to ubuntu, and a lot of ubuntu users have never even heard of it before. On fedora while kde is still well supported the default install does gnome, etc.
Have you filed bug reports and tried to help fix the issues, or are you just complaining uselessly?
The problems I had were known existing ones, so why submit an identical bug report when one already exists? (yes I actually checked their bug database for it before submitting)
While I could provide stack traces and debugging information, I have no doubt they already have this. Also before you say I should start fixing it myself, while I do occasionally help maintain OSS software, this is specialized enough and enough of a core service for me to know when to leave it to people whom sound coding is their specialty.
If it's a known issue with that level of severity and not already fixed, somebody with not a terribly good knowledge of the codebase would likely find it a gigantic waste of time trying. Even if I succeeded the cost (in time) to benefit simply isn't there.
As it stands everything I like except flash supports jack, but the kinds of programs I use aren't even dependent on QT/GTK so my usage is abnormal. I just tend to see pulseaudio as superfluous, the tasks it is useful for jack is better at, the only main advantage it has is very good support for oss/alsa/esd/arts backwards compatibility, which as direct backends are basically all heavily deprecated anyway.
Thanks for the article, I had a feeling it would have to do with entropy of the placements in memory, but couldn't find that off hand.
If you want something done right, do it yourself... is a good way to do things close to home.
To be fair, aside from
"Linux has enabled a weak form of ASLR by default since kernel version 2.6.12"
Very little information about the faults of the default ASLR seems to be readily available.
Although while hunting I did learn linux has a software implementation of the NX bit if you don't have it in hardware, which is nice. Nothing on the details of why the windows implementation is superior emerged.
It is odd for the kernel guys to accept something which isn't the superior design choice, they are perfectionists like that to an extent.
same here, been using this desktop keyboard for about seven years, only rebooting for new kernels, num lock always on, just put caps lock on and they are the same brightness.
I suffer no latency problems with PA
That is likely because you don't do anything that requires low latency, even with high latency you won't be able to tell while watching youtube or movies if it's been done right.
Other tasks like live midi stuff tend to require low latency or it will sound extremely off.
PA and jack can coexist (and the developers of both have been working together for some time now to ensure this is so)
Yes, they have been trying to work together, but serious question have you ever tried this setup? It's not pretty, the pulse audio sink for jack has a myriad of problems, and most of the time it just plain doesn't work.
This may improve in future, but for now it is extremely hit or miss, with most of the time being miss.
Feel free to read up on things so you understand them before posting.
Better yet, try implementing them, I have.
if you have to have tactile feedback then how do you use a touchpad that is on every single laptop sold? The touchpad provides no tactile feedback until you click it. Are laptops useless to you too?
Quite simple, on a laptop I look at the screen, with my n95 I can quite successfully navigate and do as I wish without ever looking at the screen. An ability which I do need of my phone at times. An ability which the iPhone utterly lacks.
the N95 while half way decent, has a horrible user interface, one that is cumbersome, hard to navigate, and can't be done with simple motions.
People have dealt with phones with menu systems for far longer than even the basic smartphone existed. I have given people my phone to use, for typical phone usage it is instant, push numbers and press a green button to call, Similar with sms. It is difficult to be more simpler than that.
While I'd agree the iPhone is a great pda, it is utterly horrible as a phone.
Only those in management positions and politics, not too unlike the US
For anyone with a short memory consider the repealed alcopop tax in 2009,
Even though it had never passed, they are still collecting it, and since a small shift of power has occurred, they are reintroducing it and are pretty sure it will pass this time.
At least they acknowledge it will do nothing for binge drinking, just makes people buy bottles of spirits. To qoute them "we need the money".
The bigger concern is that they can introduce such things without any legislation passing and have it effectively stick over multiple years
Unfortunately, as long as payback on a hybrid is 7-15 years, the only people adopting them will be the ones that can't do math.
I'd be willing to pay the extra to purchase something that paid the extra off in savings in that time, so long as it's a quality vehicle I don't see anything wrong with keeping a car 15 years+.
The idea of buying things and then tossing them when there is something shinier is part of the problem with our current wastefulness.
The only reason I'm not looking at one currently is because the technology is still being developed, and I can already get 72 miles per gallon on my motorcycle, using only petrol.
Nokia N95, more useful as an actual phone and does anything you'd like, web browser is excellent. Predates the iPhone, and no need to jailbreak, you can load any kind of native apps you like.
Are apple products perfect nope, not at all, however at the end of the day they work better than just about everyone else's, for the same price.
A phone without some form of tactile feedback is useless to me, so it depends highly on your needs
MSFT forced hardware to be standariesed.
No, they didn't, IBM made an open standard (except for the bios.. which was quickly reverse engineered), that every man and his dog replicated
And what third world country do you live in to get "network busy" at any time except during a disaster? I am 26 and have never experienced it myself although I know it happens.
I'm 22 and I've seen it before, ever seen 200 people trying to do voice calls simultaneously within 20x20m, the towers don't like it. It wasn't an emergency either.
Are the laws people break in their homes likely to cause me to die? No?
Murders happen in homes all of the time.. having a video camera wouldn't stop it, but neither would having a video camera in the car prevent someone from speeding/crashing etc, only providing proof after the fact.
So yes, it is the same.
Fit speed limiters and black box recorders on all cars. Drivers just can't be trusted to obey the law.
What about putting cameras in every home then, since people cannot be trusted to obey the law?
It is a slippery slope.
Awesome video with a performance done live, she uses several softsynths on the mac pro, the red led button thing you see is a monome, a midi controller, using ableton she samples her own voice then proceeds to use it in a soft synth along with the other bits and pieces.. if the delay between midi button being pressed and it getting sent to the audio card is 20msec+ as you would indicate, she would have to delay the master out to take that into account, and it would look horrendously out of sync on TV.
You're usage completely different to this, but what we are doing is done all the time, by all sorts of performers, it's the normal setup now. And it does require low latency. Which was initially what started this.
Yes, I mentioned that there's soundfont crap in the hardware driver, i.e. instead of letting a coprocessor do the work with $MEGABYTES loaded to sound card and $BYTES sent to it, we use the CPU to render $MEGABYTES and transfer it over the PCI bus to the sound card. Just moving the latency around and inflating the bandwidth usage.
you still incur the latency from cpu to sound card no matter what, but with sound card soundfonts you are traversing it multiple times because the cpu still has to feed the count card instructions to do what it wants to do. It is a lot more efficient to only incur that penalty once, and with a tiny enough buffer (256 samples I think in the case of 4msec) being constantly fed. It is minimized.
You'll never get rid of it, but it is a great deal less than what you would have formerly had. Things in cpu/ram have far less latency working with eachother than they do working with something on the pci bus. Tens of thousands of cycles can pass before you can do a single thing with pci.
Yes, this is true. I don't think any software allows you to adjust individual sources (or tracks even) for latency, i.e. tell it your MIDI device has 20mS latency and your direct WAV output has 0mS latency, and let it auto-correct everything. This would be useful.
Your midi devices should be synchronized with the master clock, a 20msec lag to the sequencer is insanely high, again from button pressed to your ears, 11 or 12ms is acceptable, lower, about 6 or so is ideal.
what else do we have here, Apple's take on software synthesizer latency which also says 6msec or so is ideal, lower is better etc. Note that this is all about the sound card buffer latency, none of the other parts (soft synth, midi input) are taken into account, because they are almost nothing in comparison.
Not physically possible. In one setup you may have SWXG-1000 Yamaha MIDI synthesizer program running, which has its own latency response, typically 50mS or more (I've seen it non-functional at anything below 120mS for real-time playback on an idle 1GHz CPU). In another you may use an external rack-mounted MIDI synthesizer, which means you have PCI bus latency, out through the USB host controller latency, out through a USB-serial adapter at some end, programming a MIDI sequencer in real time, which then has to fast-calculate things and produce output. This isn't instant.
Well people are doing 'the impossible' every day for their typical setups. It isn't instant, but if you can get everything from one end to being output in under 10msec, you're set. Ask anyone using a midi keyboard hooked up to logic with soft synths, which is a very common setup these days.
You're saying the setup I have is impossible, as is that of easily 90% of the users of apple's logic software that heavily use midi with soft synths. Latency has a massive effect on how you play when it sounds 'off'
that's a lot of heavy post-processing for a problem which if you use modern technology and something with low latencies you really just won't have to deal with at all at that stage
The main difference in our opinions though comes from the rather different way you're doing things, which is a great deal more difficult and might have been necessary a decade ago.
Prime example is the idea of loading soundfonts on to a sound card, it isn't done that way these days for a myriad of reasons, pci bus latency being a main one. Flexibility another. Hardware midi with soundfonts on a sound card isn't even seen as something beneficial now.
These days everything is integrated, volumes for individual tracks etc are adjusted easily even in midi form while you're working on it and playing with it. no need to render it to a fixed saved waveform until you're completely done, it can do whatever you like in real-time.
Even with something really low-end, you see the problem: the MIDI tracks get way out of sync with the sampled tracks, and it sounds like garbage. It takes very esoteric efforts to fix this, and then you have i.e. 20mS latencies within the soundfont processing crap of the sound card, or within the hardware driver; or HUGE (120mS) latencies in software synthesizers like SWXG-1000. Everything gets way out of sync.
with the 4msec jack latency i mentioned, with everything as it should be that's all the latency you'll ever get. (ok to be pedantic you could maybe add 1msec for usb polling for the midi device you're using if you are) This is an advantage of the heavy integration of everything.
Mastering pre-done waveforms is still a handy skill of course, chances are you'll deal with analogue instruments at some stage. But might i heavily recommend you look into some of the more modern ways of making music electronically? things aren't what they were like a decade ago, where what you have said would have been necessary
accidentally forgot, reference on how the audio latency effects midi users, here they claim you can usually hear above 6msec, but most people don't seem to notice until about 16 or so, still 50msec is almost 4x that
What IS the PA latency, and the Jack latency?
as with all things, depends on your setup, but a good jack setup can go as low as 4msec, pulseaudio seems to be around 50msec or so.
Do the mixing in your application and output it to ALSA.
And your proposal to have multiple sound applications interact is?
"Professional" audio amateurs seem to all be n00bs, using their recording device (computer) for playback whereas real "professionals" use monitors, metronomes, visual cues, and master tracks.
Err... you seem to be implying that there is an analog audio in that these people are using the pc to record and play back... almost never the case.
These people are sequencing midi on the computer, and rendering it to sound with custom synthesizers. After about 16msec you can HEAR the latency, 50msec is just useless. The workflow you described works well, for analogue, but it just is not the kind of work these people are using their computers for.
"Use jack" is not an option. Not everything works with jack.
serious question, what didn't you manage to get going with jack? with a bit of tinkering I can get pretty much everything going, initial setup from pulse audio is a bitch though.
OSS made it impossible to play more than one stream at once on a lot of hardware.
With a standard configuration, alsa does also, you have to load the dmix module in your config to act as a software mixer on cards that don't do hardware mixing (most on board bits).
This is where the userspace demons enter it all, most of them just started out as another layer that does software mixing, but every man and his dog came up with his own invention.
As for just using alsa, that's great if you don't mind not having certain functionality, some of the sound demons do add some nice features (jack is the only one I've found worth using though). It could be argued the driver layer shouldn't have to deal with some of that advanced functionality though, another reason why these demons were made.
it is a good API and it IS the future of Linux desktop audio,
The future of linux audio it may be.. but good is questionable, no person using their linux machine for synths or midi would touch pulseaudio with a ten foot pole, jack is far superior with a lot less latency, but only applications designed for pro audio use tend to utilize it.
When this transitional period we are currently in is over, everyone will be much better off.
The latency incurred by pulse audio is horrendous, for youtube or movies that's fine, for gaming it's questionable, for music production it's nasty. These days completely removing pulseaudio and getting it all going again is quite an effort.
I can't imagine everyone being much better off, only those who want sound who don't care about the latency or from the music peoples perspective functionality.(jack can do a lot of things pulse can't do)
OSS was okay
It really wasn't, depending on your needs of course. If oss were good enough alsa would not have been invented.
Pretty much all cards are handled by alsa in the kernel back end of things, that is pretty standardised etc, the whole problem is the sound server or userspace demon that handles mixing and other bits. PulseAudio was a band aid with horrible latency, Only professional apps tend to support jack. aRts and esd at least seem to have died out when most popular kde and gnome distro's both went to pulseaudio though.
But more or less, nothing in the kernel will fix sound, it's a userland problem.
Not really, the driver people aren't really the same as those who would be researching new and exciting ways to do what we already do. For quite a long time now driver development has been the majority of what the linux kernel development is.
Of course, every now and then they make something new like mac80211, but all that really achieves is more efficient code re-use and testing, which is always good but is still just driver development.
All the simple things an operating system kernel has to do hasn't changed over the last ten or so years, just the hardware has. Operating system theory was pretty much perfected back in the 60's
Also Linux isn't standard. What applies to RedHat doesn't apply to Gentoo and so on. No way you can support all the different distros.
From a CLI perspective, there are extremely few differences between distros and always have been, they mostly all use the GNU userland bits with the only notable but easy differences being choice of package manager and having real root vs sudo etc, trivial things.