> > The track record of ALSA for me goes like this:
> > - dmix finally started working automatically (at least on my Kubuntu
> > system) about one year ago, about five years after everybody could see
> > that this was badly needed.
>
> I don't remember when it happened, but I do remember that I suddenly
> had to manually disable dmix to stop it messing around with my sound.
> I don't need it, and I certainly don't like libraries doing random IPC
> behind my back.
>
I don't like random applications blocking my sound card.
Joe user wants to play sound, and he couldn't care less about "random IPC" or
what-fucking-ever.
Dmix using the low quality sampling rate converter by default was another bad
decision.
You are concerned about your precious audio quality? Me too. Most people,
however, are using god-awful plastic speakers for twenty euros and shitty
onboard sound chips. Sad but true.
> > - Different desktop environments have different sound daemons to
> > paper over the weaknesses of ALSA (no dmix by default / unfriendly
> > API), which creates new problems. Yes there are other reasons for
> > sound daemons, but I doubt anybody would have come up with the idea
> > if it wasn't for ALSA.
>
> Those sound daemons were around long before ALSA was even conceived.
>
ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of
technology) was released in october 2000.
Linux 2.6.0 seems to have appeared in 2003, so you are right for realistic
values of "being around".
> That sounds like a minor glitch that should be easily remedied if you
> file a proper bug report. Have you tried?
>
No, I kinda gave up on ALSA after reading its API (rather "functions
that happen to be exported") documentation and kinda hoped it would go away
ASAP.
[long rant on ALSA's developer "friendliness"]
If you want to see an example try this one:
http://www.alsa-project.org/alsa-doc/alsa-lib/hcontrol.html
or this one
http://www.alsa-project.org/alsa-doc/alsa-lib/group___h_control.html#g881a1bbb1e95b7bcadc5c2a88124c3d1
and now program against it! Having fun already?
Observe how "HCTL"s seem to be used everywhere, and the documentation is
"typedef struct _snd_hctl_elem snd_hctl_elem_t : HCTL element handle". Wow.
the struct looks like this:
struct _snd_hctl_elem {
snd_ctl_elem_id_t id; /* must be always on top */
struct list_head list; /* links for list of all helems */
int compare_weight; /* compare weight (reversed) */
/* event callback */
snd_hctl_elem_callback_t callback;
void *callback_private;
/* links */
snd_hctl_t *hctl; /* associated handle */
};
Notice how compare_weight should probably be called comparison_weight or
priority, or relative_priority, or rel_priority or (...). The comment is
worse than no comment. The author couldn't be bothered to use a dictionary? I
think he wanted to tell us whether higher priorities have higher or lower
numbers, but I still don't know which.
callback_private should be callback_opaque. The construct has always been
called opaque pointer. If it was private it wasn't in this struct.
What about "must be always on top"??? Is it trying to tell us that you should
not randomize the struct layout?
Bonus points for using abbrvns ("helems") in cmts, thy r mch mr nformtv tht
wy.
There are two other structs of the same quality in the same header file
alsa-lib/control/control_local.h.
(control_local? As opposed to... remote? With a different interface or what?
It doesn't make any sense.)
This mess probably couldn't have survived a real review by the kernel
community.
For comparison, a comment taken from KDE's Phonon, copyright Matthias Kretz:
/**
* This signal is emitted whenever the volume has changed. As the
* volume can change without a call to setVolume (calls over dbus)
* this is important
* to keep a widget showing the current volume up to date.
*/
void volumeChanged(qreal newVolume);
Spot the difference?
Kernel or user space, again:
Put everything in kernel OR userspace but not both. Either is OK, but the
arguably more "modern" approach is userspace for error resilience and easy
hacking (i.e. more features faster). Latency is an issue? - Well you can't
play sound without userspace creating it so you're not adding any new
problems.
Kernel only would have the advantage of being able to present "everything as a
file" which is a good tradition. And no IPC.
ALSA took the disadvantages of both approaches and added the disadvantage of
having to get two chunks of code to get it working. It takes a twisted mind
to have two obvious right options and pick the third, obscure, and wrong
option. So sampling rate conversion is hard ("too dangerous for the kernel"),
boo hoo. It sure isn't more difficult to get right than a filesystem. Deal
with it.
History of ALSA:
I examined the lkml archive 1999 to 2002 a bit. There was much talk about
using all the DSP, bass boost, and other sundry hardware capabilities of
cards just appearing at the time. The focus was on adding support for
everything which
a) didn't happen (DSPs almost never get used to their full potential, I think)
b) somehow became uninteresting over the years. I don't want to "enhance" my
sound with cheap DSP effects, I'll take a good stereo, thank you very much.
c) is only relevant for games because you don't want to use any effect off
your card in professional audio applications
d) is plain stupid if you don't know what exactly you are going to need
beforehand.
Sorry for the long rant - I've regularly gotten worked up about ALSA in the
last few years whenever I got in touch with it. Mostly as a user and once as
a potential client developer, but I was disgusted and turned away.
> > - On my IBM/Lenovo R50e notebook with Intel chipset sound didn't
> > work before I "muted" the "headphone jack sense" control in
> > alsamixer. That took two hours or so. When both the master volume
> > and the PCM volume control are set to 100% I get really bad clipping
> > problems.
>
> Shoddy hardware. Don't blame the drivers for that.
>
Random quote from the internet: "It all sounds perfectly reasonable until you
have to explain to your granny why her PC sounded like shit over the last
couple of months."
This can be fixed in the driver. It's called a quirk.
> Yes, API and configuration file syntax aside, the ALSA developers are
> always friendly and responsive.
>
Yes. It just seems like nobody feels in charge to revisit the big picture
issues where things really went wrong.
The last signals from Jaroslav Kysela I found on the net look like he is
convinced of having created a great architecture, especially for professional
audio applications(*). He is employed by Novell like Takashi, apparently,
which won't make Takashi feel too adventurous, right? My guess is that
Jaroslav is (officially or not) assigned to everything but drivers, and he is
just not doing anything ALSA at all.
Meanwhile, ALSA continues to be crap and annoy people.
(*) ALSA is not lacking in raw capability, to be sure.
> > (*) I am not representing KDE in an official way at all, but I can
> > say that KDE developers generally put *much* effort into making APIs
> > as logical and friendly as they possibly can.
>
> I've still not, after all these years, managed to figure out what KDE
> (or Gnome) is supposed to be good for. I'm not missing anything from
> my window manager, xterm and xemacs setup.
Maybe you could try a recent KDE or show me the command-line equivalents of
Amarok or KPDF or Gwenview :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
