>>>Hadron
>>I talked a little
>>about the problem with developing for KDE in regards to a C programmer, and
>>someone who obviously has no programming experience (despite his claims to the
>>contrary) posted an annoying fanboi response filled with accusations
>>about
>I remember this. Mark South probably. H's always at that and refuses
>to believe that something like KDevelop isn't straight from heaven.
Yes, that name sounds familiar. The sad irony is that, I wasn't talking about
KDevelop at all, nor even C programming in general. I was talking specifically
about QT programming in C, and made particular statements about that. Saying
that QT is the same as KDevelop is like saying MS Internet Explorer is the same
thing as the internet. Only someone not familiar with the details would make
that mistake, just as only someone not familiar with QT development in C would
make the mistake of assuming KDevelop is being discussed.
>>>I am hoping pulseaudio will prevail.
>> I'm hoping it will flop and go away. I have absolutely no confidence
>> in that
>I learnt something from the next paragraph.
I'm pleased. I hope that people do take a much closer look at what is being
packed into distros, and more people start doing code audits for security and
stability. It's not just the featureset that counts, but also the quality of
the code. I'd rather not have new software bundled if it comes at the expense
of efficiency and stability, and frankly offers marginally useful features.
>But a pity I cant get it to work properly with shared sound e.g mplyer,
>youtube and system sounds. I need to install esd/pulse for system
>sounds to work and then every now and again all sounds stops and get
>queued until something (god knows what) releases the queue and they all
>come piling out together,
Right. I just disabled system sounds altogether, and stopped the esd daemon.
I'm more interested in individual apps having sound than being able to hear
some sort of "click" noise when I open a folder, or a paper crumpling when I
empty the trash can.
That's not to say that the ALSA devs can't/shouldn't implement some sort of
"audio sharing", and then the Gnome developers can't/shouldn't abandon ESD and
go directly to ALSA. But given that this option isn't yet available, I
personally choose to abandon system sounds rather than risk
instability/inefficiency by using something like Pulse Audio. If Pulse Audio is
installed with a distro I use, I'll manually rip it out.
>The sound system has left me feeling totally drained. I dont know where to look
>anymore to be honest. Its a mess.
There's nothing majorly wrong with ALSA. It's stable and well-coded in regards
to error checking/handling. (Yeah, there are some design issues I have with it,
but it's no worse than much of what I see from the other sound choices).
What needs to be done is for people to totally reject things like Pulse Audio,
and instead petition the ALSA devs to do some serious peer studies/reviews on
implementing an audio/MIDI "sharing API", and then have app developers, and
especially the developers of Gnome and KDE, directly support ALSA. That will
solve the problems, in a much more efficient and stable way. Right now, the
ALSA devs are not doing this additional work on ALSA, and app devs aren't
supporting ALSA the way they should. And frankly, it's no fault of the app devs
for their support. The ALSA folks have produced very, very poor "documentation"
constructed with one of those horrid tools that pull comments out of source
code. In that case, it's not surprising that developers aren't supporting ALSA
better. ALSA is a more complicated API than something like Pulse Audio or aRTS
or JACK, etc. So given equally bad docs on all of the sound APIs, developers
are going to go for the ones that take the least amount of effort to figure out
on their own.
I've started a programming tutorial on ALSA and JACK at the following URL:
http://home.roadrunner.com/~jgglatt/tech/linuxapi.htm
The ALSA folks really, really, really need to do something much like this.
And they could definitely benefit from getting their code base peer reviewed to
fix those things that people find frustrating to use.
>With pulse most things share or play simultaneously. Not with just alsa
>for me. I dont know why. I have given up.
Right. Pulse Audio's API has built-in "stream mixing" transparent to the app.
ALSA does not. That's not to say that ALSA cannot have this added to it in a
way that is more efficient, and more stable (since the ALSA devs have at least
shown that they understand the need for proper error checking, and have
designed their whole API to return error codes, as should be done. The Pulse
Audio authors simply do not understand the importance of this, and openly
refuse to attend to it).
>To be honest I'm not sure I agree with your issues with ignoring
>malloc. I do check myself but I often wonder "why bother". If I cant
>malloc 32 bytes or something then there are worse issues and the chance
>of the logging daemon working it about nil.
The problem with ignoring malloc's error return is why we have the OOM killer,
which is a kludge that should not have existed. If people had done proper error
checking to begin with, then Linux's low memory error handling would never have
amounted to killing some process without its permission or even knowledge. The
problem with doing this is that, a process may be handling important data that
needs to be saved to permanent media, but has not yet been done, when it is
killed. That's permanent loss of important data, and that is a very, very, very
bad thing. (It's a good thing that wall street firms don't really know about
the OOM killer. If they did, they may back away from Linux for this reason
alone. No one wants to lose data that could cost them dearly. If Win32
advocates really start to understand the implications, there is going to be
major fallout for serious Linux use).
All code that does not do proper memory checking needs to be purged from Linux,
and replaced with code that not only does proper error checking, but also
returns proper error codes so that any calling code can also do proper error
checking and handling. This is the key to stability. You can't have stability
without good error checking and handling all the way down the line.
But I see why you're thinking "why bother"? Linux already has the OOM Killer
now, as a result of needing to deal with code that totally ignores error
checking and stumbles head-on into inevitable major system instability. So
people often think "it's too late to do the right thing. I can't stop the OOM
Killer. So I may as well do the wrong thing like other folks did". It's my hope
that, as more and more people do the right thing, eventually their code will
replace the "wrong stuff" (because the former will be more stable), and the OOM
killer will eventually be able to be jettisoned and replaced with much more
effective, stable, and efficient low memory handling/recovery. But the last
thing we need is to be adding new things that do the wrong thing some more...
like Pulse Audio.