Re: Is it time for remove (crap) ALSA from kernel tree ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [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]
  Powered by Linux