Message-ID: <4682EEDD.4020501@gmail.com>
Date:	Thu, 28 Jun 2007 01:12:29 +0200
From:	Rene Herman <rene.herman@...il.com>
To:	Andreas Hartmetz <ahartmetz@...il.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Is it time for remove (crap) ALSA from kernel tree ?

On 06/27/2007 09:10 PM, Andreas Hartmetz wrote:

>>> I don't like random applications blocking my sound card.
>> 
>> So don't use random applications.
>> 
> I imitated the style of the mail I replied to. Besides, choosing apps
> based on sound system is retarded if you wanted to indicate that this
> should be done more often or something.

What I indicated was that if someone wants to use multiple applications that 
work together bringing you The One Integrated Sound Experience it might make 
sense to use applications... that work together. Don't go blame ALSA for 
either the fact that aRTs isn't actually useful nor KDE's decision to stick 
with it for way too long. See -- the problem is again not ALSA (or OSS for 
that matter) but userspace not getting its act together.

KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing by 
default for some time now so we're talking history anyway. You want mixing 
on your card? You got it.

Many don't -- they might not care about desktop sounds period and/or they 
might use a clumsy chip/card for that and use a nice one for music without 
any need for mixing on it (such as I do). Admittedly, mixing Abba's Dancing 
Queen with Slayer's Angel of Death is great fun for quite a while but at 
some point you do actually grow weary of it...

> Exactly! And the config file is hostile if you want to change it.

It could be a bit nicer yes. Since software mixing is enabled by default now 
no configuration is generally needed though and it seems not a particularly 
huge priority. Now that it's an advanced feature, maybe the flexibility pays 
off in fact -- not sure, I don't use any configuration myself other than for 
some testing and playing around every once in a while.

> KDE 2 *was* released in 2000. Why would you care, I already admitted that
> sound daemons were there before ALSA.

Because blaming ALSA for bad decisions made by others seems a little off and 
you did exactly that a few messages back. Not nice!

>> You give up reporting small hardware problems that bother you because the
>> application developer documentation for something is not in great shape?
> 
> Yep, because I was frustrated with the whole thing. Having huge bad APIs
> with no documentation is telling your fellow developers to piss off and
> do something else. I did.

You weren't having a developer problem but a user problem. Your problem was 
not with the API documentation but with what would appear to be a simple 
glitch in one particular driver. Mixing that in with a "ALSA sucks because 
its documentation isn't upto par" is a little disingenious.

Sure the (library) documentation blows donkeys. So wat else's is new in the 
land of Linux? I recently did a block-ish driver. Documentation? Whahahaha!

So that leaves that "bad" that you prefixed API with but keep in mind that 
ALSA is designed as an audio system suitable for advanced/professional use 
while also still filling the needs of consumer users and that it does in 
fact do so is obvious from the fact that everyone's using it. A complex API 
is the downside of flexibility. Perhaps it would've been better if alsa-lib 
had also made a very simple API available to non-demanding users from the 
start but other software can do that as well.

For my current purposes libao does, but I hope in the future something like 
Phonon does. The ideal situation is that anyone in userspace is using a 
single API _such_ as Phonon since userspace has to synchronise things itself 
as well -- it might for example want to provide you with the option to 
automatically mute your music when you get an incoming call and this is not 
something which alsa-lib can do by itself.

If it looks like I'm shifting blame -- you bet I am. It's userspace which 
has for years failed to get its multimedia act together, with KDE and GNOME 
going out of their way to pick other infrastructure than the other one. The 
kernel is not a guilty party and improvements should be sought where the 
problems lie.

As said earlier, KDE4 might just be such an improvement. Personally I'm 
hoping I'll even manage to start running it this time because damnit, I miss 
solitaire...

>>> 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.
>> 
>> Capture.
>> 
> If you are not doing DMA from the sound card to kernel memory and then 
> directly to disk blocks, you are using user space apps period. So what's 
> different with capture?

The latency in this case is defined as the time between data arriving at the 
machine from the outside and it being available for further processing by an 
application. Think looping stuff out again in realtime after doing something 
to it to see why you want it to be low. If you'll grant that all those users 
who were dissatisfied with early 2.6 weren't just blowing smoke, I assume 
you'll grant that latency matters and that putting it all in userspace is 
not an obvious step in minimising it -- even interrupt latency matters.

Note also it's certainly not (just) PCM but also very much MIDI. A musician 
hitting a key on a keyboard needs to hear the sound he's making, processed, 
recorded, stretched, whatever the computer does to it, with _very_ minimal 
latency. Yes, this means that the userspace application(s) have to be fast 
themselves but if they aren't getting their data delivered to them in time 
to begin with they're SOL. Perhaps it's possible to get okay results with a 
top-priority, realtime scheduled full stack in userspace which bangs I/O 
ports and does all those pesky driver thingies but why do we have a kernel 
again?

As to going the other way and putting it _all_ in the kernel; why? Why would 
you care about the split from an API standpoint? The alsa-lib API is the 
API, period. At which point it crosses over into the kernel is something an 
application gets to see as an implementation detail. Rejoice -- you now 
don't have to worry about floating point for example in the context of 
resampling and/or soft-volume, or ...

Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists