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

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

[Anton Petrusevich]

>>I don't like random applications blocking my sound card. 
>So don't use random applications.
 
I have ICE1724, a very good sound card to my taste, works like a charm. But 
with ALSA I had a really hard time to configure it properly, wanna see 
my .asoundrc? And I am not sure I have done it right (== the best possible 
way). I have read everything on http://www.alsa-project.org/documentation.php 
about .asoundrc. When I am using Skype I have to rename .asoundrc to 
something else in order to get it working. When I am doing some changes 
to .asoundrc I have to restart the app. Is there a tool which can be used to 
configure .asoundrc? I want to be able to hear sound from flashplayer on my 
reciever or in my headphones -- how? It's not quite clear to me how to get 
full duplex working with my .asoundrc.
-- 
Anton Petrusevich

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

[Rene Herman]

On 06/28/2007 02:42 PM, Anton Petrusevich wrote:

Please always use Reply-to-All on this list -- subscribers here like to also 
get personal copies.

> I have ICE1724, a very good sound card to my taste, works like a charm.
> But with ALSA I had a really hard time to configure it properly, wanna
> see my .asoundrc?

Not particularly. I don't count as a great fan of the config file syntax and 
don't use any configuration myself. I moreover don't own an ICE1724 card, so 
I'm not familiar with it's possibilities and quirks and generally, if this 
thread turns into guiding every user on the list through his/her respective 
problems with ALSA I have to respectfully decline...

> And I am not sure I have done it right (== the best possible way). I have
> read everything on http://www.alsa-project.org/documentation.php about
> .asoundrc. When I am using Skype I have to rename .asoundrc to something
> else in order to get it working.

The first thing I don't know is why you need an .asoundrc at all. I've CCed 
the alsa-user list -- some subscribers to it probably have experience with 
ice1724 and might be able to get you specific advice if you want.

Renaming .asoundrc seems wrong in any case. If you need anything special for 
  Skype, it seems you could always define it in a seperate "skype" PCM and 
use that only from skype.

> When I am doing some changes to .asoundrc I have to restart the app.

Yes, as far as I'm aware you do.

> Is there a tool which can be used to configure .asoundrc?

vi.

> I want to be able to hear sound from flashplayer on my reciever or in my 
> headphones -- how?

Not sure? Is your receiver on an analog output and are your headphones 
connected directly to a card output as well? In that case, "or" would seem 
to be just a mixer issue, and "and" would be dependent on hardware abilities 
and needs someone who knows your specific card and setup.

> It's not quite clear to me how to get full duplex working with my
> .asoundrc.

It's not working without an .asoundrc?

But -- I'll personally not continue this very specific subthread simply due 
to not having the hardware, nor great generic experience with an .asounrc 
due to not needing it myself. When I do use one, I alway start by googling 
up a few examples and take it from there. Perhaps someone from alsa-user 
will step in.

Rene.

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

[Anton Petrusevich]

On Thursday 28 June 2007 17:02:55 you wrote:
> Please always use Reply-to-All on this list -- subscribers here like to
> also get personal copies.

I am not subscribed to linux-kernel, I am reading it on the web.

> > I have ICE1724, a very good sound card to my taste, works like a charm.
> > But with ALSA I had a really hard time to configure it properly, wanna
> > see my .asoundrc?
> Not particularly. I don't count as a great fan of the config file syntax
> and don't use any configuration myself. 

Do you have an SPDIF out? If you don't then you don't need .asoundrc of 
course.

> The first thing I don't know is why you need an .asoundrc at all. 

Because I want to route it differently, sometimes to spdif, sometimes to 
headphones, sometimes to mix sounds from different apps. Well, my config may 
be a bit ancient as it was written when dmix was not default.

> I've CCed 
> the alsa-user list -- some subscribers to it probably have experience with
> ice1724 and might be able to get you specific advice if you want.

I have read some advices for ice1724 already. The main reason I wrote to  
lkml -- I hate .asounrc and reading docs about it. I hate "flexebility" that 
requires restarting apps after changing sound routes.

> > Is there a tool which can be used to configure .asoundrc?
> vi.

I perfectly know this one. I would like to use some really user-friendly tool.

>
> > I want to be able to hear sound from flashplayer on my reciever or in my
> > headphones -- how?
>
> Not sure? Is your receiver on an analog output and are your headphones

My receiver is on spdif out.

> connected directly to a card output as well? In that case, "or" would seem
> to be just a mixer issue, and "and" would be dependent on hardware
> abilities and needs someone who knows your specific card and setup.
>
> > It's not quite clear to me how to get full duplex working with my
> > .asoundrc.
>
> It's not working without an .asoundrc?

Looks like it's not working with. As skype is not so informative.

> But -- I'll personally not continue this very specific subthread simply due
> to not having the hardware, nor great generic experience with an .asounrc
> due to not needing it myself. When I do use one, I alway start by googling
> up a few examples and take it from there. Perhaps someone from alsa-user
> will step in.

I am not about ice1724 or .asounrc here. I am trying to talk about 
user-friendliness of ALSA. It's very unfriendly.

-- 
Anton Petrusevich

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

[Xavier Bestel]

On Thu, 2007-06-28 at 18:34 +0200, Anton Petrusevich wrote:
> > Please always use Reply-to-All on this list -- subscribers here like to
> > also get personal copies.
> 
> I am not subscribed to linux-kernel, I am reading it on the web.

Then please subscribe just for the time you want to participate to the
discussion.

	Xav

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

[Rene Herman]

On 06/28/2007 06:34 PM, Anton Petrusevich wrote:

> Do you have an SPDIF out? If you don't then you don't need .asoundrc of 
> course.

I do on a number of cards, although being without sensible equipment (other 
than other soundcards) with an S/PDIF _in_ I don't actually use it for more 
than testing purposes.

Why do I need or want an .asoundrc? What's wrong with just using the iec958 
PCM device? Yes, I checked, and ICE1724 has it defined.

>> The first thing I don't know is why you need an .asoundrc at all. 
> 
> Because I want to route it differently, sometimes to spdif, sometimes to 
> headphones,

These two consist of specifying different devices (iec958 and <see below>)

> sometimes to mix sounds from different apps. Well, my config may be a bit
> ancient as it was written when dmix was not default.

Right, it now is. The "default" device on your card uses both the dmix and 
the dsnoop (for the capture direction) plugins and if you want direct access 
without going through those plugins, you can select the direct "hw" devices 
simply by specifying them.

> I have read some advices for ice1724 already. The main reason I wrote to
> lkml -- I hate .asounrc and reading docs about it. I hate "flexebility"
> that requires restarting apps after changing sound routes.

How would you _like_ things to work? asoundrc is a configuration file for 
alsa-lib. Would you perhaps suggest that alsa-lib expand its API with a 
snd_all_your_base_are_changed_out_from_under_you() application callback and 
sets notifies on its configuration file(s)? The application may have done 
things like enumerate the available PCM devices when it started up. Heck, 
maybe it's _busy_ playing through some "route" that you just changed...

>>> Is there a tool which can be used to configure .asoundrc?
>> vi.
> 
> I perfectly know this one. I would like to use some really user-friendly
> tool.

Some would say "emacs" now, but I'll not be as childish as that. I'm not 
like that. At all.

> I am not about ice1724 or .asounrc here. I am trying to talk about 
> user-friendliness of ALSA. It's very unfriendly.

In another recent post in this thread, I linked to:

http://forum.skype.com/lofiversion/index.php/t85880.html

Note how it starts with:

"Now that Skype uses ALSA for its sound I/O, I can set it up to work 
properly with my multi-channel audio interface (an Echo Gina24 with an 
8-channel ADAT interface chained onto it)."

That, as far as I'm concerned, says quite a bit. It says the flexibility is 
welcomed and used. Sure, simple things should be simple and with myself 
being a non-beginner-level user (user, not an audio professional) still not 
using or needing any configuration indicates to me that things have been 
partitioned correctly.

Yes, I can lose my way in the configuration as well when I play with it but 
I expect I could actually fairly easily remedy this by learning more about 
it before I start. And I expect for example that you hadn't heard of the 
iec958 PCM device before this message so that you only _think_ stuff is complex.

Generally, I tend to have some opinions on this blind insistance people seem 
to have they have an inalienable right to operate complex technology without 
turning their bloody brain on. I've been ranting just about enough now 
though so I'll not drag general "user friendliness" into it and just say 
that if I would have, it would've probably included the line "go buy a copy 
of windows and be gone" at some point.

Rene.

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 759 bytes --]

On Thu, 28 Jun 2007, Rene Herman wrote:

> On 06/28/2007 06:34 PM, Anton Petrusevich wrote:
>
>> Do you have an SPDIF out? If you don't then you don't need .asoundrc of 
>> course.
>
> I do on a number of cards, although being without sensible equipment (other 
> than other soundcards) with an S/PDIF _in_ I don't actually use it for more 
> than testing purposes.

Sorry please keep all "I don't need" or "I don't count" words for 
themeselve.
We are taking not about you but about *ALSA*.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Rene Herman]

On 06/28/2007 09:33 PM, Tomasz Kłoczko wrote:

>> On 06/28/2007 06:34 PM, Anton Petrusevich wrote:
>>
>>> Do you have an SPDIF out? If you don't then you don't need .asoundrc 
>>> of course.
>>
>> I do on a number of cards, although being without sensible equipment 
>> (other than other soundcards) with an S/PDIF _in_ I don't actually use 
>> it for more than testing purposes.
> 
> Sorry please keep all "I don't need" or "I don't count" words for 
> themeselve. We are taking not about you but about *ALSA*.

Read the next lines. And then piss off, retard troll.

Rene.

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

[Florian Schmidt]

On Thursday 28 June 2007, Anton Petrusevich wrote:
> > > I have ICE1724, a very good sound card to my taste, works like a charm.
> > > But with ALSA I had a really hard time to configure it properly, wanna
> > > see my .asoundrc?
> >
> > Not particularly. I don't count as a great fan of the config file syntax
> > and don't use any configuration myself.
>
> Do you have an SPDIF out? If you don't then you don't need .asoundrc of
> course.

With  a properly coded ALSA app, one doesn't need a .asoundrc. You would 
enter "plug:spdif" [or something similar] into the pcm device name entry text 
field.

Or if you want to point all apps to that device you actually could add this to 
your .asoundrc:

pcm.!default {
	type plug
	slace.pcm "spdif"
}

[or something similar. Too lazy to look up the exact syntax now]. And then 
every app using the ALSA API _correctly_ should use that device [if 
configured to use the default device, which should be the _default_ ;)]

Sadly it seems pretty much everyone, especially closed source apps get this 
wrong (but to be fair: loads of open source software gets it wrong, too, 
ekiga for example).

What they do wrong is that they try to present a list of devices to the user 
from which he can choose [which isn't bad in itself] and also do _not_ offer 
any way to specify an arbitrary PCM device name.

Sadly, the ALSA api docs do not stress this point often enough, so it gets 
missed pretty often.

I once posted an [not original, i suppose people before me got that idea, too] 
idea to the alsa-dev list a while back, proposing a way to be able 
to "register" pcm devices defined in .asoundrc/asound.conf, so that apps that 
want to present a list to the user can simply ask ALSA for a list of devices 
nd hav the user defined ones included. Sadly i don't think it ever went 
anywhere..

> Because I want to route it differently, sometimes to spdif, sometimes to
> headphones, sometimes to mix sounds from different apps. Well, my config
> may be a bit ancient as it was written when dmix was not default.

Well, like i said, the application in question should allow you to enter any 
pcm name you want. If it doesn't it's broken.

> I have read some advices for ice1724 already. The main reason I wrote to
> lkml -- I hate .asounrc and reading docs about it. I hate "flexebility"
> that requires restarting apps after changing sound routes.

I own a ice1712, too, but i only use it for JACK and it works brilliantly 
there. But i know it can be a bitch to configure since it sports a 10/12 
channel device which can be too complicated for some ALSA apps making 
assumptions about the device they get ;)

> I perfectly know this one. I would like to use some really user-friendly
> tool.

I don't know of any. But any text editor will do. 

> > > I want to be able to hear sound from flashplayer on my reciever or in
> > > my headphones -- how?
> >
> > Not sure? Is your receiver on an analog output and are your headphones
>
> My receiver is on spdif out.

The flashplayer has been another one of these badly coded apps ;) Maybe that 
has changed in recent releases.

> > It's not working without an .asoundrc?
>
> Looks like it's not working with. As skype is not so informative.

But skype is a piece of crap anyways. It also doesn't get any sounds out of my 
other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. And 
yeah, the device is available [and even has hardware multiplexing]..

> I am not about ice1724 or .asounrc here. I am trying to talk about
> user-friendliness of ALSA. It's very unfriendly.

I agree. ALSA is not very userfriendly. Especially the missing proper device 
enumeration support is a problem.

But 99.9% of problems people have with ALSA are due to badly coded apps..

Regards,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org

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

[Anton Petrusevich]

On Friday 29 June 2007 12:30:54 Florian Schmidt wrote:
> Sadly it seems pretty much everyone, especially closed source apps get this
> wrong (but to be fair: loads of open source software gets it wrong, too,
> ekiga for example).

Isn't that because there's a perferct documentation for programming ALSA but 
authors of those apps can't read?

> Well, like i said, the application in question should allow you to enter
> any pcm name you want. If it doesn't it's broken.

But in real life I have to use flashplayer, for example.

> I don't know of any. But any text editor will do.

I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but 
now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a 
user.

> The flashplayer has been another one of these badly coded apps ;) Maybe
> that has changed in recent releases.
[...]
> But skype is a piece of crap anyways. It also doesn't get any sounds out of
> my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep.
> And yeah, the device is available [and even has hardware multiplexing]..

> But 99.9% of problems people have with ALSA are due to badly coded apps..

"Those apps are crap and ALSA is perfect". I hoped some ALSA-developers would 
think of improving usability of ALSA, or I would not talk here.

> I agree. ALSA is not very userfriendly. Especially the missing proper
> device enumeration support is a problem.

It's good that people are not thinking that ALSA is already perfect, it leaves 
us (me) a hope it will be improved.
-- 
Anton Petrusevich

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

[Florian Schmidt]

On Friday 29 June 2007, Anton Petrusevich wrote:
> On Friday 29 June 2007 12:30:54 Florian Schmidt wrote:
> > Sadly it seems pretty much everyone, especially closed source apps get
> > this wrong (but to be fair: loads of open source software gets it wrong,
> > too, ekiga for example).
>
> Isn't that because there's a perferct documentation for programming ALSA
> but authors of those apps can't read?

No, like i said, the docs are unclear on these issues :) That's why so many 
people get it wrong.

> But in real life I have to use flashplayer, for example.

Yes, in these cases flashplayer should use either the default pcm device 
[which the user can then tweak to his liking] or provide some means to 
configure it. for example via a dotfile in the user's homedir. This is not 
ALSA's fault.

> I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but
> now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a
> user.

I agree that it would be nice to have a tool to select the default device in 
ALSA. 

> > But skype is a piece of crap anyways. It also doesn't get any sounds out
> > of my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a
> > beep. And yeah, the device is available [and even has hardware
> > multiplexing]..
> >
> > But 99.9% of problems people have with ALSA are due to badly coded apps..
>
> "Those apps are crap and ALSA is perfect". I hoped some ALSA-developers
> would think of improving usability of ALSA, or I would not talk here.

ALSA must be improved, too.  But that doesn't change a thing about these apps 
misusing the ALSA API and people blaming ALSA lateron. Which is wrong.

> It's good that people are not thinking that ALSA is already perfect, it
> leaves us (me) a hope it will be improved.

I don't think any serious person believes that ALSA is perfect :)

Regards,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org

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

[Gabriel C]

Anton Petrusevich wrote:
>
> Is there a tool which can be used to configure .asoundrc? 
>   

There is an QT4 based one [1] and a somewhat old KDE based tool [2].

Regards,

Gabriel C


[1] http://sourceforge.net/projects/aplugedit/
[2] http://sourceforge.net/projects/kasound/

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

[William Pitcock]

On Wed, 4 Jul 2007 19:32:29 +0200, Adrian Bunk wrote:
> On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>>
>> I know this may sound kind of stupid, but how about not deprecating either,
>> and fully supporting both sound systems? Maybe we can get them to work
>> together, and the distro or user can choose whether they would like to use
>> alsa or oss for that particular card (or have the distro choose the sound
>> drivers that are best supported for that particular card). As it is now,
>> most apps already support oss and alsa.
>
> It does not sound stupid and sounds good at first sight.
>
> But there are problems we've already seen with similar situations in
> different parts of the kernel:
> They would have different hardware support, features and bugs.
>
> And then a user user whose sound card is only supported by sound system A
> needs a feature only available in sound system B.
>
> And the quality decreases since people will often not report bugs in
> sound system A if sound system B works for them.
>
> OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's
> mostly a difference for application developers. And since (as you say)
> most applications already support both, there's no compelling reason for
> providing more than one of them.
> 
> cu
> Adrian
>

If the developers of ALSA made a nuclear reactor, it would have five 
different control panels for controlling the rods in the reactor core, and 
each would do something different and not what the documentation said.

Actually, I lied about that. It wouldn't have any usable documentation. 
But, there would be a hidden feature that you could sound the overload 
alarm by pulling out the stapler in the control office. Useful feature, 
that.

As an audio developer on Linux, I must say that developing with ALSA is 
absolute fucking hell. If there was a way where both APIs could natively 
be supported, more people would be happy with the current state of affairs 
in the kernel.

The most fucked up thing that I can think of about the current state of 
affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's 
software mixing in kernel space. The applications never even know about 
it. It's not only until recently (2005-2006 or so) that ALSA came close to 
this, but there are still problems. Many cards need workarounds to make 
dmix work because of the way it works, and the way that ALSA buffers data 
around.

For the non-technically inclined, ALSA only keeps two fragments for 
input/output data each. This is horribly unusable because most soundcard 
fragments are only 1KB, so applications have to adopt ringbuffers to pass 
data to ALSA. If you're doing video, this leads to possible timing issues 
unless you sit down and well design your abstraction layer for audio I/O.

So people switch to things like JACK and PulseAudio because it's the only 
way they can get workable Audio I/O on ALSA.

What's even worse for the ALSA API is that it's designed around lowlatency 
programming, but only a few drivers properly support it. Why do you need 
lowlatency access to play a beep or a ding or whatever? The simple answer 
is you don't.

ALSA could and can be done correctly, but OSS4 is already here and 
provides an API which solves all of ALSA's current problems. So why waste 
time with that, when OSS4 is already here and more friendly to the 
developers of the software most Linux users use?

If OSS4 and ALSA apis could run on the same base driver, then a lot more 
people will be happier, as there will be choice available in which API to 
use, e.g. OSS4 or the libasound self-abuse method.

Hannu has ideas on how that could work. I suggest all of the kernel 
developers listen, and listen well, or this mess will never be fixed in a 
way that is truly usable.

   -nenolod

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

[Carlo Wood]

On Sat, Jul 07, 2007 at 02:41:05AM +0000, William Pitcock wrote:
> The most fucked up thing that I can think of about the current state of 
> affairs in ALSA is dmix. Every other UNIX sound system like ALSA does it's 
> software mixing in kernel space. The applications never even know about 
> it. It's not only until recently (2005-2006 or so) that ALSA came close to 
> this, but there are still problems. Many cards need workarounds to make 
> dmix work because of the way it works, and the way that ALSA buffers data 
> around.

I have to agree. I am not an audio programmer, just a user; but the
bottom line is simply: It is WAY to hard to get things working (if
at all possible).
At one point I tried to get sound from xmms and ut2004 at the same time
(on my new machine). I was ASTONISHED that it didn't Just-Work!
After trying many complex things-- I gave up and put my old
soundblaster Live! in the new PC - because that card has hardware
support for this. Now I was lucky to HAVE that other soundcard,
but what about all those other users out there who just buy a new
PC, with a sound chip on the motherboard and then, being simple, ordinairy
users, have to face this ALSA configuration hell to do something
as simple as having two audio applications play sound at the same time?

> For the non-technically inclined, ALSA only keeps two fragments for 
> input/output data each. This is horribly unusable because most soundcard 
> fragments are only 1KB, so applications have to adopt ringbuffers to pass 
> data to ALSA. If you're doing video, this leads to possible timing issues 
> unless you sit down and well design your abstraction layer for audio I/O.

Worse-- the two fragment limit is passed on to the OSS emulation (or at least
it was in 2005; but if this is still true for the ALSA API in 2007, then my
guess is that it's also still true for the OSS emulation). The result is
that applications written for OSS do not work anymore when using the OSS
emulation of ALSA and therefore the argument of providing backwards
compatibility doesn't exist.

...snip...
> Hannu has ideas on how that could work. I suggest all of the kernel 
> developers listen, and listen well, or this mess will never be fixed in a 
> way that is truly usable.
> 
>   -nenolod

Good post, nenolod.

-- 
Carlo Wood <carlo@alinoe.com>

PS I am NOT saying that I want ALSA to be removed from the kernel.
   I am just saying that I agree with those who think that the
   ALSA API is too complex, hard to use and has serious flaws that
   should be addressed.

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

[Robert Hancock]

Anton Petrusevich wrote:
> On Thursday 28 June 2007 17:02:55 you wrote:
>> Please always use Reply-to-All on this list -- subscribers here like to
>> also get personal copies.
> 
> I am not subscribed to linux-kernel, I am reading it on the web.
> 
>>> I have ICE1724, a very good sound card to my taste, works like a charm.
>>> But with ALSA I had a really hard time to configure it properly, wanna
>>> see my .asoundrc?
>> Not particularly. I don't count as a great fan of the config file syntax
>> and don't use any configuration myself. 
> 
> Do you have an SPDIF out? If you don't then you don't need .asoundrc of 
> course.
> 
>> The first thing I don't know is why you need an .asoundrc at all. 
> 
> Because I want to route it differently, sometimes to spdif, sometimes to 
> headphones, sometimes to mix sounds from different apps. Well, my config may 
> be a bit ancient as it was written when dmix was not default.
> 
>> I've CCed 
>> the alsa-user list -- some subscribers to it probably have experience with
>> ice1724 and might be able to get you specific advice if you want.
> 
> I have read some advices for ice1724 already. The main reason I wrote to  
> lkml -- I hate .asounrc and reading docs about it. I hate "flexebility" that 
> requires restarting apps after changing sound routes.
> 
>>> Is there a tool which can be used to configure .asoundrc?
>> vi.
> 
> I perfectly know this one. I would like to use some really user-friendly tool.
> 
>>> I want to be able to hear sound from flashplayer on my reciever or in my
>>> headphones -- how?
>> Not sure? Is your receiver on an analog output and are your headphones
> 
> My receiver is on spdif out.
> 
>> connected directly to a card output as well? In that case, "or" would seem
>> to be just a mixer issue, and "and" would be dependent on hardware
>> abilities and needs someone who knows your specific card and setup.
>>
>>> It's not quite clear to me how to get full duplex working with my
>>> .asoundrc.
>> It's not working without an .asoundrc?
> 
> Looks like it's not working with. As skype is not so informative.
> 
>> But -- I'll personally not continue this very specific subthread simply due
>> to not having the hardware, nor great generic experience with an .asounrc
>> due to not needing it myself. When I do use one, I alway start by googling
>> up a few examples and take it from there. Perhaps someone from alsa-user
>> will step in.
> 
> I am not about ice1724 or .asounrc here. I am trying to talk about 
> user-friendliness of ALSA. It's very unfriendly.

In the case of S/PDIF output on ice1724 (and probably other cards), it 
would be nice if ALSA defaulted to routing default audio to both the 
S/PDIF and analog ports, as this is what most users would normally 
expect.. The Windows drivers work like that, but on Linux you have to 
pick one or the other (at least without a bunch of mucking with the 
config file).

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

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

[Rene Herman]

Robert Hancock <hancockr <at> shaw.ca> writes:

> In the case of S/PDIF output on ice1724 (and probably other cards), it 
> would be nice if ALSA defaulted to routing default audio to both the 
> S/PDIF and analog ports, as this is what most users would normally 
> expect.. The Windows drivers work like that, but on Linux you have to 
> pick one or the other (at least without a bunch of mucking with the 
> config file).

I believe some cards can't do this in fact which might be argument due to
consistency. Otherwise I don't so much have an opinion on whether or not this
should be default though...

Rene

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

[Andreas Hartmetz]

 > > 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 :)

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

[Rene Herman]

On 06/27/2007 06:25 PM, Andreas Hartmetz wrote:

> I don't like random applications blocking my sound card.

So don't use random applications.

> 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.

Exactly, which is why mixing has been default for some time now for most 
cards. Are you only ranting about how it should've been earlier?

> ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of 
> technology) was released in october 2000.

http://www.arts-project.org/gen/newsarchive/news_1998.html

>>  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.

You give up reporting small hardware problems that bother you because the 
application developer documentation for something is not in great shape? 
What an odd thing to do. And what a shame that this thread apparently was 
unable to outlive it's originator troll and turn useful...

[ ... ]

> 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.

Rene.

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

[Andreas Hartmetz]

> > 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.

> > 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.
>
> Exactly, which is why mixing has been default for some time now for most
> cards. Are you only ranting about how it should've been earlier?
>
Exactly! And the config file is hostile if you want to change it.

> > ALSA appeared in 1999, KDE 2 with aRtsd (another catastrophic failure of
> > technology) was released in october 2000.
>
> http://www.arts-project.org/gen/newsarchive/news_1998.html
>
KDE 2 *was* released in 2000. Why would you care, I already admitted that 
sound daemons were there before ALSA.

> >>  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.
>
> 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.
It's not like a little oversight to be quickly forgotten. ALSA has been there 
for at least *five years* without documentation for most parts.

> > 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?

> Rene.

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

[Rene Herman]

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.

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

[Patrick Draper]

Rene Herman wrote:
> 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.

I've been following this discussion with some interest, to learn more 
about ALSA. I've been creating startup scripts for all of my sound-using 
applications which look like this:

LD_PRELOAD=libaoss.so exec /usr/bin/alsaplayer "$*"

I found that without libaoss.so preloaded, I wasn't getting software 
mixing at all. I'm constantly running an MP3 player, and with that 
library I can get sound alerts from other apps too.

I don't understand exactly what you mean by ALSA mixing by default. I 
have the OSS Mixer API selected during kernel compiles. Is that what you 
are referring to?

Thanks,

Patrick

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

[Rene Herman]

On 06/28/2007 02:18 AM, Patrick Draper wrote:

Please always use Reply-to-All on this list -- subscribers here like to also 
get personal copies.

> Rene Herman wrote:
>> 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.
> 
> I've been following this discussion with some interest, to learn more 
> about ALSA. I've been creating startup scripts for all of my sound-using 
> applications which look like this:
> 
> LD_PRELOAD=libaoss.so exec /usr/bin/alsaplayer "$*"
> 
> I found that without libaoss.so preloaded, I wasn't getting software 
> mixing at all.

This would seem to indicate that your alsaplayer (what's in a name) is setup 
to output to OSS and not to ALSA...

The OSS interface -- consisting of direct access to device nodes such as 
/dev/dsp0, /dev/mixer and /dev/music -- is an older interface for sound on 
Linux. The newer ALSA interface works via a library API and is best used 
natively. For backwards compatibility though, ALSA also provides emulation 
of the older OSS interface.

It does so in two different ways in fact -- the first one is a direct kernel 
space emulation where ALSA interprets accesses to those device nodes it then 
manages much like real OSS would do. This kernel space emulation is made 
available through the "OSS PCM/Mixer/Sequencer API" you see as options in 
the ALSA kernel configuration menu.

The other way is a userspace emulation through the libaoss.so library that 
you are using. That library catches accesses to the OSS device nodes in 
userspace and translates them to ALSA accesses before they even get to the 
kernel.

ALSA does software mixing (the act of mixing two seperate streams together 
to form one) in userspace and as such, the kernelspace OSS emulation does 
not support software mixing, while this userspace emulation does -- if your 
ALSA default device is setup for software mixing (it is by default these 
days) this also works for this libaoss route. If you run a OSS program 
without the library preload it's using the kernel emulation though.

So -- the fact that mixing actually works for you when using libaoss means 
software mixing is working correctly for your ALSA setup. The only thing you 
should do is _use_ ALSA (natively) and not its OSS emulation so you can drop 
the library preload.

I don't have alsaplayer installed (wasn't that thing dead?) so I can't walk 
you through its configuration easily, but I suppose you'll be able to figure 
it out. If you need to specify an ALSA device somewhere, make sure it's not 
the old "hw:0" but "default" (or "default:0" for the first card, "default:1" 
for the second, ...). The "hw:N" devices don't do mixing.

> I'm constantly running an MP3 player, and with that library I can get
> sound alerts from other apps too.

I myself mostly use the ogg123 and mpg321 command line players, both based 
on libao and thereby only a simple:

$ echo "default_driver=alsa09" >/etc/libao.conf

away from being native ALSA players.

> I don't understand exactly what you mean by ALSA mixing by default. I 
> have the OSS Mixer API selected during kernel compiles. Is that what you
> are referring to?

No. That's part of the kernel space OSS emulation. A "mixer" in that context 
is the part of a soundcard that controls volumes and may mix the output of 
several parts of the card/chip for playback and its inputs for capture. Ie, 
that which is controlled by a mixer application such as the (ncurses) ALSA 
reference mixer "alsamixer" or the mixer your desktop environment provides.

Once you have everything running as a native ALSA application you could 
disable that option. In fact, since you're using the userspace emulation, 
you could already. The new-ish Flash Player 9 (important for youtube these 
days) for Linux is also an ALSA application and since I use it, I myself 
haven't needed OSS emulation for anything anymore.

Rene.

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

[Rene Herman]

On 06/28/2007 03:58 AM, Rene Herman wrote:

> to figure it out. If you need to specify an ALSA device somewhere, make 
> sure it's not the old "hw:0" but "default" (or "default:0" for the first
> card, "default:1" for the second, ...). The "hw:N" devices don't do
> mixing.

Slight correction/expansion -- don't do _software_ mixing. Some cards can do 
hardware mixing and in that case, "hw:N" or, specifically "hw:N,0", "hw:N,1" 
and so on devices are available as hardware mixed devices.

Try a cat /proc/asound/card0/pcm0p/info and check the "subdevices_count" for 
the number of hardware mixed playback devices you have available. If it's 1, 
your card should've been configured (by ALSA itself) to use software mixing 
by default and if it's higher than 1, it should not have been and will use 
hardware mixing...

Rene.

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

[Rene Herman]

On 06/28/2007 04:28 AM, Rene Herman wrote:

> On 06/28/2007 03:58 AM, Rene Herman wrote:
> 
>> to figure it out. If you need to specify an ALSA device somewhere, make
>> sure it's not the old "hw:0" but "default" (or "default:0" for the
>> first card, "default:1" for the second, ...). The "hw:N" devices don't
>> do mixing.
> 
> Slight correction/expansion -- don't do _software_ mixing. Some cards 
> can do hardware mixing and in that case, "hw:N" or, specifically 
> "hw:N,0", "hw:N,1" and so on devices are available as hardware mixed 
> devices.

Correcting the correction (sorry, it was late) -- "hw:N" is card N, "hw:N,M" 
is PCM interface M of card N and "hw:N,M,K" is (hardware mixed) subdevice K 
on PCM interface M of card N. Normal cards have only one PCM interface 
meaning that M is 0 in the above.

That is, I meant that "hw:N,0,0", "hw:N,0,1" and so on are the hardware 
mixed devices.

Rene.

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

[Patrick Draper]

Rene Herman wrote:
> So -- the fact that mixing actually works for you when using libaoss 
> means software mixing is working correctly for your ALSA setup. The only 
> thing you should do is _use_ ALSA (natively) and not its OSS emulation 
> so you can drop the library preload.

Cool. How do I go about figuring out what every app uses? For example, 
you mentioned that the flash 9 plugin, which I also use, is an ALSA 
aware application. How do you know? I need the check out everything that 
I use which needs sound (vmware, skype, kmplayer, etc.) I don't have 
source code for at least two of those.

Thanks,
Patrick

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

[Lee Revell]

On 6/27/07, Patrick Draper <pdraper@gmail.com> wrote:
> Rene Herman wrote:
> > So -- the fact that mixing actually works for you when using libaoss
> > means software mixing is working correctly for your ALSA setup. The only
> > thing you should do is _use_ ALSA (natively) and not its OSS emulation
> > so you can drop the library preload.
>
> Cool. How do I go about figuring out what every app uses? For example,
> you mentioned that the flash 9 plugin, which I also use, is an ALSA
> aware application. How do you know? I need the check out everything that
> I use which needs sound (vmware, skype, kmplayer, etc.) I don't have
> source code for at least two of those.

Go into the sound preferences menu of the app and check which device
it uses.  If it's something like /dev/dsp or /dev/audio it's using
OSS.  If it looks like "default" or "hw:0" it's ALSA.

If your app does not have any sound preferences menu it's broken and
you should file a bug report.

You can determine whether an app with no configurable sound device is
using ALSA by running "strace broken_app" and grep the output for
"/dev/dsp" or "/dev/audio".

Lee

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

[Arjan van de Ven]

On Wed, 2007-06-27 at 22:04 -0500, Patrick Draper wrote:
> Rene Herman wrote:
> > So -- the fact that mixing actually works for you when using libaoss 
> > means software mixing is working correctly for your ALSA setup. The only 
> > thing you should do is _use_ ALSA (natively) and not its OSS emulation 
> > so you can drop the library preload.
> 
> Cool. How do I go about figuring out what every app uses? For example, 
> you mentioned that the flash 9 plugin, which I also use, is an ALSA 
> aware application. How do you know? I need the check out everything that 
> I use which needs sound (vmware, skype, kmplayer, etc.) I don't have 
> source code for at least two of those.

run ldd on the binary...

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1378 bytes --]

On Wed, 27 Jun 2007, Patrick Draper wrote:

> Rene Herman wrote:
>> So -- the fact that mixing actually works for you when using libaoss means 
>> software mixing is working correctly for your ALSA setup. The only thing 
>> you should do is _use_ ALSA (natively) and not its OSS emulation so you can 
>> drop the library preload.
>
> Cool. How do I go about figuring out what every app uses? For example, you 
> mentioned that the flash 9 plugin, which I also use, is an ALSA aware 
> application. How do you know? I need the check out everything that I use 
> which needs sound (vmware, skype, kmplayer, etc.) I don't have source code 
> for at least two of those.

If can I join .. (again)
After upgrade to skype 1.4.x all sound output in skype I have only in left 
channel. Serching for skype+left+channel on google shows many people 
have this kind problem :>
ALSA does not privide application mixer settings on application level. 
Some messages on skype forums suggests some workarouds in ~/.asoudrc 
but where is documentation for this part ?
Anywhere are described ALSA diagnostics procedures/technics ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Gabriel C]

Tomasz Kłoczko wrote:
> On Wed, 27 Jun 2007, Patrick Draper wrote:
>
>   
>> Rene Herman wrote:
>>     
>>> So -- the fact that mixing actually works for you when using libaoss means 
>>> software mixing is working correctly for your ALSA setup. The only thing 
>>> you should do is _use_ ALSA (natively) and not its OSS emulation so you can 
>>> drop the library preload.
>>>       
>> Cool. How do I go about figuring out what every app uses? For example, you 
>> mentioned that the flash 9 plugin, which I also use, is an ALSA aware 
>> application. How do you know? I need the check out everything that I use 
>> which needs sound (vmware, skype, kmplayer, etc.) I don't have source code 
>> for at least two of those.
>>     
>
> If can I join .. (again)
>   
Heh =)

> ALSA does not privide application mixer settings on application level. 
> Some messages on skype forums suggests some workarouds in ~/.asoudrc 
> but where is documentation for this part ?
>   
You may want to read this one:

http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php

> Anywhere are described ALSA diagnostics procedures/technics ?
>
> kloczek
>   

Gabriel C

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

[Rene Herman]

On 06/28/2007 01:50 PM, Tomasz Kłoczko wrote:

> If can I join .. (again)

Welcome...

> After upgrade to skype 1.4.x all sound output in skype I have only in 
> left channel. Serching for skype+left+channel on google shows many 
> people have this kind problem :>

This would seem to be a (fairly, it's no doubt just outputting mono) skype 
specific problem and given that skype is a proprietary closed source 
application, you now get to go suck on a Skype support engineer! Hurrah!

Or this might be helpful:

http://forum.skype.com/lofiversion/index.php/t85880.html

No, no idea why skype would require you to do this yourself. Maybe you 
should ask them. This is now _really_ no longer a kernel issue though.

Rene.

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

[Rene Herman]

On 06/28/2007 05:04 AM, Patrick Draper wrote:

> Rene Herman wrote:

>> So -- the fact that mixing actually works for you when using libaoss 
>> means software mixing is working correctly for your ALSA setup. The 
>> only thing you should do is _use_ ALSA (natively) and not its OSS 
>> emulation so you can drop the library preload.
> 
> Cool. How do I go about figuring out what every app uses? For example, 
> you mentioned that the flash 9 plugin, which I also use, is an ALSA 
> aware application. How do you know?

Various methods. If all's well, the application has a config menu where you 
can look at and change the settings.

Or, running ldd on the binary to see if it's linked to libasound, "grep 
/proc/<pid>/maps libasound" (also catches dlopen), "strace" or usually 
easiest and what I tended to do -- "lsmod" to see if starting the app 
triggered the automatic loading of snd-pcm-oss and snd-mixer-oss which I 
don't normally have loaded.

This is the "[things are still not great] partly _due_ to people maintaining 
OSS is somehow a valid choice on Linux" that I stated early in this thread. 
I actually believe the kernel space OSS emulation has been fairly counter 
productive -- it's allowed applications to stay with an obsolete interface 
since the users didn't even have to _know_ due to it all just working. At 
least with the userspace emulation, people know they are using an OSS 
emulation if they are starting the application with an library preload.

The kernel space emulation is a bit more bullet-proof in the sense that the 
userspace emulation would not for example help with applications that use 
direct syscalls to open device nodes and I guess that was important.

When OSS/Free was replaced with ALSA inside the Linux kernel this was a big 
change in an area most users use and any such change inevitably opens up big 
cans of change resistant wankers who understand the old interface and have 
no need for the new one and will tell you that you did it all wrong, it was 
all for nothing and you suck period. They'll keep it up for years and years 
generally. The kernel-space OSS emulation _does_ mostly just work, which is 
the kind of thing that you need in this environment to be allowed to tell 
these people to go sexually entertain themselves.

Perhaps it's now finally coming to the time where the kernel space emulation 
can be deprecated and eventually removed. Or not...

> I need the check out everything that I use which needs sound (vmware,
> skype, kmplayer, etc.) I don't have source code for at least two of
> those.

I don't know if vmware by now supports native ALSA but it didn't use to. The 
current version of skype (1.4, still called a beta it seems) does.

kmplayer seems to be a frontend for various mediaplayer solutions. Don't you 
just love that mess? Its backends include MPlayer and Xine, and both these 
can talk native ALSA fine at least. For mplayer, use a "ao=alsa" line in the 
.mplayer/config file (or just start it with -ao alsa) and for xine, look in 
its setup menu (audio tab, having set the interface level to beter than 
"beginner").

Rene.

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

[Andreas Hartmetz]

> > 
> > We dropped OSS for ALSA for technical reasons. Those being that ALSA
> > - has a better audio API

> You mean the undocumented, 100% ioctl one?  With one ioctl to write
> interleaved sound, one for non-interleaved sound, in addition to
> setting interleaved or not in the configuration?  I should check one
> day which one wins.

> Or the "library"?  Don't get me started on this one.

> I take your word about the fact that the kernel side is better.

Okay, here's a rant.

As an interested kernel outsider and KDE developer(*), it looks to me like 
most kernel people are  too focused on the history and feature lists of the 
particular technologies here. 

The real matter with ALSA is that you get a strong "ALSA hates me" feeling 
when dealing with it. There is bad documentation, bad API, and a config file 
syntax that is much harder to understand than necessary.

Then there is the kernel/library split that seems to have no convincing reason 
at all in its current form.
Why not put the whole sound system in userland? It has been done before. Sound 
is just not performance critical at all and it's almost never mission 
critical.
Plus you wouldn't have to cross the userland/kernel gap to implement new and 
exciting things that way. Audio is kinda simple on the IO level (I hope I'm 
right there :) ) and, ideally, on the userland API level. These places are 
exactly where well-defined interfaces should be. An appropriate IO interface 
and userland API should be set in stone, not something arbitrary in between. 
Hell, there could even be a source compatible sound driver standard for all 
Unix-like free OS kernels.

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 couldn't get it to work before. The howtos somehow didn't 
work and ALSA's documentation isn't all that helpful.

- 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.

- I have an Envy24HT based soundcard in my desktop PC, which also goes to show 
that I'm really interested in sound issues. I have to run alsamixer after 
every bootup to unmute the left channel because restoring volume only works 
for the right channel. The left channel starts working after changing its 
volume.

- 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.

- Some time ago ALSA reported that my soundcard supports sampling rates it 
doesn't in fact support. This was fixed by Takashi Iwai after a week and two 
mails or so. Thumbs up.

Regards,
Andreas

(*) 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.

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

[Måns Rullgård]

Andreas Hartmetz <ahartmetz@gmail.com> writes:

> 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 couldn't get it to work before. The howtos somehow didn't 
> work and ALSA's documentation isn't all that helpful.

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.

> - 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.

> - I have an Envy24HT based soundcard in my desktop PC, which also
> goes to show that I'm really interested in sound issues. I have to
> run alsamixer after every bootup to unmute the left channel because
> restoring volume only works for the right channel. The left channel
> starts working after changing its volume.

That sounds like a minor glitch that should be easily remedied if you
file a proper bug report.  Have you tried?

> - 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.

> - Some time ago ALSA reported that my soundcard supports sampling
> rates it doesn't in fact support. This was fixed by Takashi Iwai
> after a week and two mails or so. Thumbs up.

Yes, API and configuration file syntax aside, the ALSA developers are
always friendly and responsive.

> (*) 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.

-- 
Måns Rullgård
mans@mansr.com

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

[Rene Herman]

On 06/26/2007 10:39 PM, Andreas Hartmetz wrote:

> Okay, here's a rant.
> 
> As an interested kernel outsider and KDE developer(*), it looks to me
> like most kernel people are too focused on the history and feature lists
> of the particular technologies here.
> 
> The real matter with ALSA is that you get a strong "ALSA hates me"
> feeling when dealing with it. There is bad documentation, bad API, and a
> config file syntax that is much harder to understand than necessary.

I'll agree to the documentation bit; the funny thing is that it's partly 
caused by documentation actually being, or once having been, _better_ than 
it is for the average subsystem. ALSA for example has the useful "Writing an 
ALSA Driver" document from Takashi Iwai:

http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html

Documentation becomes obsolete as code progresses though and yes, especially 
on the userside of things the documentation is slow to follow. And then the 
usual problem of noone ever removing obsolete junk from the web exacerbates 
matters. Google will find you tons of useless, outdated crap but if you need 
the information in the first place, you don't know that it _is_ obsolete.

And yes, this unfortunately includes www.alsa-project.org. For the longest 
time it was advocating writing ~/.asoundrc files for example through generic 
driver boilerplate texts while that was actually at that point mostly 
counter productive in getting ALSA functional.

As to the config file -- well, sure. The best thing about is that normally 
you don't need it...

The "bad API" I find interesting since you are a KDE developer. I'm not an 
audio application developer myself so I don't have (m)any well thought out 
opinions on it, but isn't the only thing in KDE4 that talks to ALSA the 
Phonon ALSA backend? If you are talking in that context, I'm quite sure the 
alsa-user and/or alsa-devel lists (@alsa-project.org) would like to hear 
about any specific comments/problems. Getting the Phonon backend right from 
the start is something that seems important.

> Then there is the kernel/library split that seems to have no convincing
> reason at all in its current form. Why not put the whole sound system in
> userland? It has been done before. Sound is just not performance critical
> at all and it's almost never mission critical

Heh. Sound may not be, but audio is. For the longest time, audio users stuck 
with 2.4 kernels and the low-latency patches that were availabe for it due 
to latency issues. Large parts of ALSA already are in userland in the form 
of libasound and I expect moving over everything would not so much help.

[ ... ]

> 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 couldn't get it to work before. The howtos
> somehow didn't work and ALSA's documentation isn't all that helpful.

dmix was really only implemented (or at least, made default) for casual 
users. Hope it'll not come across as elitist but people who are serious 
about music or audio don't actually need or want it. It's a consumer thing. 
To have software mixing work you have to resample to a common rate and this 
an absolute unthinkable horror to a serious user. It's a good thing it's now 
default, but only because a majority of sound users is not serious (simply 
because it's mostly all computer users).

> - 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.

Given that they existed before ALSA did this seems to be a somewhat odd doubt.

> - I have an Envy24HT based soundcard in my desktop PC, which also goes to show 
> that I'm really interested in sound issues.

Nice chip. I don't have one, and am not too sure about its native supported 
rates but if you are mostly playing 44100 through it (ie, CD source audio) 
I'd consider doing without dmix. A nice sounding chip like that shouldn't be 
subjected to resampling really. Someone recently informed me on the ALSA 
list that Envy24 indeed doesn't do hardware mixing though, so I guess you 
may need it if you really do want the also have the card available for 
desktop sounds.

> I have to run alsamixer after every bootup to unmute the left channel
> because restoring volume only works for the right channel. The left
> channel starts working after changing its volume.

Sounds like a rather debugable problem. I'm (almost) sure someone will try 
to get you a useful answer if you post to the alsa-devel@alsa-project.org 
list :)

> - 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.

First problem I don't know about but is no doubt related to alsa developers 
not having proper documentation. On lots of hardware, there's many bits to 
flip, with no information from the manufacturer forthcoming. You can't hold 
that against ALSA so much.

As to the second bit -- most cards mame any audio that passes through them 
when you set a volume to above 0 dB. dB scales were recently implemented for 
many drivers. If also for yours, I expect 100% is more than 0 dB?

> - Some time ago ALSA reported that my soundcard supports sampling rates
> it doesn't in fact support. This was fixed by Takashi Iwai after a week
> and two mails or so. Thumbs up.

Yes, Takashi Iwai is very responsive.

> (*) 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.

Not so much that I'm likely to be of great help myself, not being an audio 
application developer, but if there's any problem's with the new KDE4 stuff 
in relation to ALSA, I hope you or someone else will bring them up on the 
alsa list(s)...

Rene.

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

[Lee Revell]

On 6/26/07, Andreas Hartmetz <ahartmetz@gmail.com> wrote:
> Why not put the whole sound system in userland? It has been done before. Sound
> is just not performance critical at all and it's almost never mission
> critical.

There are dozens of companies selling Linux powered professional audio
gear, multiple pro audio centric distros, and hundreds of serious free
software audio apps.  I suspect these developers and their users would
disagree.

I agree with you about userland drivers but at minimum this would
require merging the -rt kernel patches, otherwise the latency/jitter
will be too high to do anything but toy desktop sounds, then you need
a mergeable mechanism for doing DMA and interrupt handling in
userspace.  It has been attempted before but never evolved to the
point where you could drive a complex device like the emu10k1.

Lee

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 863 bytes --]

On Wed, 27 Jun 2007, Lee Revell wrote:

> On 6/26/07, Andreas Hartmetz <ahartmetz@gmail.com> wrote:
>> Why not put the whole sound system in userland? It has been done before. 
>> Sound
>> is just not performance critical at all and it's almost never mission
>> critical.
>
> There are dozens of companies selling Linux powered professional audio
> gear, multiple pro audio centric distros, and hundreds of serious free
> software audio apps.  I suspect these developers and their users would
> disagree.

OK .. hundreds.
Can you list ten ?
Can you point to oppinions of this people about ALSA ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Meelis Roos]

Our developers chose ALSA over OSS as the sound API for a VOIP-like
fullduplex application and one of the reasons was API - OSS mixer API
was not flexible enough (something to do with separating muting and
volume control IIRC).

-- 
Meelis Roos

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

[Robert Hancock]

Tomasz Kłoczko wrote:
> On Sun, 24 Jun 2007, Alan Cox wrote:
> [..]
>> Years ago Linux dumped OSS for ALSA because ALSA offered far better
>> functionality and support. Why would we go back to the stone age ?
>>
>> Its something useful to various other platforms with basically no
>> hardware support but Linux has ALSA and very good hardware support and
>> ALSA even has emulation for back compatibility with old OSS apps.
>>
>> Ten years ago it would probably have made a difference, five maybe, today
>> its a release of historical code at best, and since they shipped binary
>> modules for Linux more like 'getting around to complying with the
>> licence' than anything else.
> 
> Sory Alan but I don't want philosophical/historical discuss.
> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.

If you are the one advocating using OSS, it's up to you to explain why 
it's better using technical arguments, which you haven't done. I rather 
doubt it is possible to do so convincingly.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

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

[Ash Willis]

kloczek,
The fact that it is now open source does mean that it's a suitable replacement.

If you actually want a productive discussion, you'd be better off making an
attempt at describing exactly _why_ ALSA is 'crap' and how in your opinion OSS
overcomes ALSA's shortfalls.

IMHO, it would be far more realistic and managable to look at the OSS codebase
and use it to make improvements to ALSA. I'm looking into one or two issues
myself and I've mentioned looking at the OSS code for possible improvements on
the alsa-devel list. I think it's generally agreed that OSS can't do much at all
that ALSA doesn't already do. Sure, if you've been smoking crack, you might want
to rip out ALSA and replace it with OSS to gain some minor functionality but
you'd also lose functionality in the process.

Unless you can describe how the actual architecture of ALSA is inferior and not
just complain about some particular device not being fully supported, the best
idea is clearly to port any lacking functionality from OSS -> ALSA. In the case
that you can actually provide valid reasons for ALSA's inferiority, I shall
respectfully eat my hat :)

Either way, have bug reports been filed for areas of ALSA that you are unhappy
with?

Ash

-- 
Get a Free E-mail Account at Mail.com!
Choose From 100+ Personalized Domains
Visit http://www.mail.com today

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1016 bytes --]

On Sun, 24 Jun 2007, Ash Willis wrote:

> kloczek,
> The fact that it is now open source does mean that it's a suitable replacement.
>
> If you actually want a productive discussion, you'd be better off making an
> attempt at describing exactly _why_ ALSA is 'crap' and how in your opinion OSS
> overcomes ALSA's shortfalls.

I'm asking .. and axpecting (only) answesr on my question.

*Each* day I have problems with ALSA support and I know some fundamental 
ALSA misdevelopments and few times it was by me (and not only by me) 
presented on lk-ml (try look on lk-ml archive) .. so .. sory but I'm not 
interested on discuss about ALSA v. OSS :> (if you want disccuss about 
this please prepare for this and read anything about subject .. before).

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 594 bytes --]


Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
for Linux:

http://www.opensound.com/press/2007/oss-gpl-cddl.txt

So this source without problems code can be integragrated in Linus tree 
and after this Linux can provide much better soud supoport than 
with current ALSA.

Any plans for doing this ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Alan Cox]

On Sun, 24 Jun 2007 19:51:38 +0200 (CEST)
Tomasz Kłoczko <kloczek@rudy.mif.pg.gda.pl> wrote:

> 
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
> for Linux:
> 
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> 
> So this source without problems code can be integragrated in Linus tree 
> and after this Linux can provide much better soud supoport than 
> with current ALSA.

Years ago Linux dumped OSS for ALSA because ALSA offered far better
functionality and support. Why would we go back to the stone age ?

Its something useful to various other platforms with basically no
hardware support but Linux has ALSA and very good hardware support and
ALSA even has emulation for back compatibility with old OSS apps.

Ten years ago it would probably have made a difference, five maybe, today
its a release of historical code at best, and since they shipped binary
modules for Linux more like 'getting around to complying with the
licence' than anything else.

Alan

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1534 bytes --]

On Sun, 24 Jun 2007, Alan Cox wrote:
[..]
> Years ago Linux dumped OSS for ALSA because ALSA offered far better
> functionality and support. Why would we go back to the stone age ?
>
> Its something useful to various other platforms with basically no
> hardware support but Linux has ALSA and very good hardware support and
> ALSA even has emulation for back compatibility with old OSS apps.
>
> Ten years ago it would probably have made a difference, five maybe, today
> its a release of historical code at best, and since they shipped binary
> modules for Linux more like 'getting around to complying with the
> licence' than anything else.

Sory Alan but I don't want philosophical/historical discuss.
Try to answer on question "ALSA or OSS ?" using *only* technical arguments.

Maybe it is not clear for you but now way for introduce better OSS support 
for FOSS applications is completly oppened (there is no legal 
contrargumets fo not using OSS).
There is no ALSA on non-Linux systems (and will not be) so all other 
OSes/Unices will have better sound support than Linux (better on technical 
level and also on support level because all this systems will use 
common OSS) .. and it is only matter of time (when/how fast ?).
If you dont see this please stop ..

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 198 bytes --]


On Jun 24 2007 21:24, Tomasz Kłoczko wrote:
> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.

Ok: The OSS cs46xx driver did not support the rear 2 channels.


	Jan
-- 

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

[Rene Herman]

On 06/24/2007 09:27 PM, Jan Engelhardt wrote:

> On Jun 24 2007 21:24, Tomasz K?oczko wrote:
>> Try to answer on question "ALSA or OSS ?" using *only* technical
>> arguments.
> 
> Ok: The OSS cs46xx driver did not support the rear 2 channels.

Not sure it's going to count as only technical in wanker language but note 
that a very important driver such as Envy24 also works decidely worse in the 
open sourced OSS. In the "module envy24 not found" sense.

Which is the same sense as anything currently available from sound/isa in fact.

Rene.

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 647 bytes --]

On Sun, 24 Jun 2007, Jan Engelhardt wrote:

>
> On Jun 24 2007 21:24, Tomasz Kłoczko wrote:
>> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> Ok: The OSS cs46xx driver did not support the rear 2 channels.

Yes it is true .. OSS (Hannu tree) dos not provide rear 2 channels in
cs46xx driver because .. in this OSS tree there is no cs46xx driver :>

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Jan Engelhardt]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 455 bytes --]


On Jun 25 2007 12:06, Tomasz Kłoczko wrote:
>>
>> On Jun 24 2007 21:24, Tomasz Kłoczko wrote:
>> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>>
>> Ok: The OSS cs46xx driver did not support the rear 2 channels.
>
> Yes it is true .. OSS (Hannu tree) dos not provide rear 2 channels in
> cs46xx driver because .. in this OSS tree there is no cs46xx driver :>

I think that says it all why ALSA should be kept.


	Jan
-- 

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

[Hannu Savolainen]

Tomasz Kłoczko kirjoitti:
> On Sun, 24 Jun 2007, Jan Engelhardt wrote:
>
>>
>> On Jun 24 2007 21:24, Tomasz Kłoczko wrote:
>>> Try to answer on question "ALSA or OSS ?" using *only* technical 
>>> arguments.
>>
>> Ok: The OSS cs46xx driver did not support the rear 2 channels.
The cs46xx OSS driver in the kernel is not our work. This discussion is 
about _our_ OSS 4.0 so the above is not a valid argument.
> Yes it is true .. OSS (Hannu tree) dos not provide rear 2 channels in
> cs46xx driver because .. in this OSS tree there is no cs46xx driver :>
The driver for cs46xx/cs4280 devices in OSS 4.0 is called cs4280.c. It's 
based on the same sample sources from Crystal than the kernel cs46xx 
one. It doesn't support the rear channels any better which could be an 
argument. However OSS is now an open source community project so anybody 
has freedom to fix this problem.

Best regards,

Hannu

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

[Alan Cox]

> Sory Alan but I don't want philosophical/historical discuss.
> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.

We dropped OSS for ALSA for technical reasons. Those being that ALSA
- has a better audio API
- is more flexible
- provides OSS as emulation
- supports more hardware

I used to maintain the kernel OSS code (the fork when Hannu and friends
took their project non-free). I did the work to make the sound layer
modular when the vendors realises that the open one needed to be modular
and that since that was the main play of the non-free one that Hannu
wasn't going to be doing it. From a technical perspective ALSA is the
better design especially for flexible devices.

At the desktop level these days it doesn't really matter much, the
desktops use their own sound servers which sit on top of OSS, ALSA and
other sound systems.

Alan
 

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

[Olivier Galibert]

On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
> 
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio API

You mean the undocumented, 100% ioctl one?  With one ioctl to write
interleaved sound, one for non-interleaved sound, in addition to
setting interleaved or not in the configuration?  I should check one
day which one wins.

Or the "library"?  Don't get me started on this one.


I take your word about the fact that the kernel side is better.  The
userland side, not so much.

  OG.

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

[Carlo Wood]

On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > Sory Alan but I don't want philosophical/historical discuss.
> > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
> 
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio API
> - is more flexible
> - provides OSS as emulation
> - supports more hardware

I sent a patch to the ALSA developers 4 years ago.
It was never included in the kernel :/

Here's the comment from a script that I once wrote to
make some closed-source dinosar code run (speech recognition)
on modern linux:

# Note that ALSA (Advanced Linux Sound Architecture), the sound drivers that
# replace the older OSS as of kernel 2.5, also introduce a problem for some
# soundcards: unlike the OSS drivers, the ALSA drivers limit the recording
# buffer to the hardware limit of your sound card.  For example, the SB Live!
# only has two 'period' buffers (called fragments before), and although
# viavoice requests an 'arbitrary number of periods, size 1024 bytes', it
# only gets two periods of 1024 bytes: 2048 bytes in total!  The ViaVoice
# engine however doesn't even process sound until it sees at least 6102 bytes.
# The 'solution' for this is to increase the buffer size (from 1024 to say
# 8192), this script also takes care of that.  Unfortunately, also that is
# possibly not enough: the sound is read from the hardware in chunks of
# 'period size' and having only two buffers this is often causing an underrun.
# When ALSA sees an underrun... it stops the sound stream.

My (four year old) patch can be found here:

http://www.xs4all.nl/~carlo17/alsa/index.html

I STILL think that ALSA should restart the stream after an underrun,
but I am not someone who asks twice :p usually.

-- 
Carlo Wood <carlo@alinoe.com>

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

[Jesper Juhl]

On 25/06/07, Carlo Wood <carlo@alinoe.com> wrote:
> On Sun, Jun 24, 2007 at 09:57:24PM +0100, Alan Cox wrote:
> > > Sory Alan but I don't want philosophical/historical discuss.
> > > Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
> >
> > We dropped OSS for ALSA for technical reasons. Those being that ALSA
> > - has a better audio API
> > - is more flexible
> > - provides OSS as emulation
> > - supports more hardware
>
> I sent a patch to the ALSA developers 4 years ago.
> It was never included in the kernel :/
>
Did you try resending it?
Sometimes patches get missed, overlooked, dropped on the floor by mistake etc.

[snip]
>
> My (four year old) patch can be found here:
>
> http://www.xs4all.nl/~carlo17/alsa/index.html
>
> I STILL think that ALSA should restart the stream after an underrun,
> but I am not someone who asks twice :p usually.
>
When it comes to getting patches into mainline, asking twice (or more)
is sometimes required, and it's considered your responsability as
submitter to resend a patch if noone reacts to it the first time
around.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

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

[Carlo Wood]

On Mon, Jun 25, 2007 at 12:48:45AM +0200, Jesper Juhl wrote:
> Did you try resending it?
> Sometimes patches get missed, overlooked, dropped on the floor by mistake 
> etc.
...
> When it comes to getting patches into mainline, asking twice (or more)
> is sometimes required, and it's considered your responsability as
> submitter to resend a patch if noone reacts to it the first time
> around.

Some history:

At the time I suffered from a severe RSI (Repitive Stress Injury) and
I had to take into account that I'd not be able to type anymore at
some point.  This is why I became interested in speech recognition,
even though I had to limit my typing time to 2 hours or so per day.
The only speech recognition software available for linux was 'ViaVoice',
a discontinued package sold by IBM. I managed to get my hand on one
(even though they aren't even sold anymore *cough cough*) and quickly
found out that it was so old that it didn't even run anymore. I hacked
the binary package (closed source and stuff) until it ran again (which
involved writing this kernel patch). However, then I found out that
ViaVoice was unusable for me: it didn't recognize my voice - it just
didn't work (it worked for others, so it much be my voice or accent
or whatever). Hence, I dropped the whole project. I could use my
two hours per day of typing better.

Now - about the resending the patch... I usually do, but I also
reschedule the priority of such a task. In this case, since I NEVER
do anything with recording - and the project that made me be involved
was dead as far as me was concerned - it got scheduled so far at
the bottom that I simply never got to it anymore.

I have no idea how much the code has changed in the meantime, but
the problem is/was this:

There is significant difference between ALSA and OSS such that an
application that works under OSS does not work anymore with the
OSS emulation under ALSA.

Firstly, the total recording buffer that you get is limited - while
that is not the case with OSS. Secondly, if that buffer runs full
(xrun) the stream is stopped permanently and not restarted, while
it is restarted with OSS.

You can download testcode.c from
http://www.xs4all.nl/~carlo17/alsa/index.html
and run it:

hikaru:~>./a.out
    Allocated 2 buffers of 1024 bytes.
    Allocated 2 buffers of 2048 bytes.
    Allocated 2 buffers of 4096 bytes.
    Successfully allocated a buffer that is large enough.
    Available bytes: 3072
    Available bytes: 4768
    Available bytes: 6432
    Available bytes: 8192
    Successfully caused an xrun.
    non-blocking fragments: 2
    non-blocking bytes: 8192
    Available bytes in buffer: 9856
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Additionally read 1024 bytes.
    Stream is not restarted after xrun.

Since this is not the same behaviour as with OSS - I think it's a bug.

I don't know if the patch on that patch can still be applied,
but if not - then I'm sure you are more into that code than
me and it will be a lot easier for you to fix this the right
way in the correct kernel code :)

-- 
Carlo Wood <carlo@alinoe.com>

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

[Nobin Mathew]

> I sent a patch to the ALSA developers 4 years ago.
> It was never included in the kernel :/

ALSA maintainers are very open to patches. try sending this again

>
> Here's the comment from a script that I once wrote to
> make some closed-source dinosar code run (speech recognition)
> on modern linux:
>
> # Note that ALSA (Advanced Linux Sound Architecture), the sound drivers that
> # replace the older OSS as of kernel 2.5, also introduce a problem for some
> # soundcards: unlike the OSS drivers, the ALSA drivers limit the recording
> # buffer to the hardware limit of your sound card.  For example, the SB Live!
> # only has two 'period' buffers (called fragments before), and although
> # viavoice requests an 'arbitrary number of periods, size 1024 bytes', it
> # only gets two periods of 1024 bytes: 2048 bytes in total!  The ViaVoice
> # engine however doesn't even process sound until it sees at least 6102 bytes.
> # The 'solution' for this is to increase the buffer size (from 1024 to say
> # 8192), this script also takes care of that.  Unfortunately, also that is
> # possibly not enough: the sound is read from the hardware in chunks of
> # 'period size' and having only two buffers this is often causing an underrun.
> # When ALSA sees an underrun... it stops the sound stream.
>

native ALSA drivers has all these required features.

> My (four year old) patch can be found here:
>
> http://www.xs4all.nl/~carlo17/alsa/index.html
>
> I STILL think that ALSA should restart the stream after an underrun,
> but I am not someone who asks twice :p usually.

If it is native ALSA driver then it will restart after each underrun
and overrun. It is the applications job to do this, alsa-lib provides
all support for this. I have no idea of OSS and OSS emulation in ALSA.

If you have any queries please try sending to alsa-devel.

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

[Alan Cox]

> If it is native ALSA driver then it will restart after each underrun
> and overrun. It is the applications job to do this, alsa-lib provides
> all support for this. I have no idea of OSS and OSS emulation in ALSA.

OSS should autorestart on underrun and just moan about overruns and drop
bits. So if it's not following that behaviour he is IMHO correct for the
OSS emulation case.

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

[Takashi Iwai]

At Mon, 25 Jun 2007 10:06:18 +0100,
Alan Cox wrote:
> 
> > If it is native ALSA driver then it will restart after each underrun
> > and overrun. It is the applications job to do this, alsa-lib provides
> > all support for this. I have no idea of OSS and OSS emulation in ALSA.
> 
> OSS should autorestart on underrun and just moan about overruns and drop
> bits. So if it's not following that behaviour he is IMHO correct for the
> OSS emulation case.

I think he is right in the case of read (although I don't remember his
post as my buffer overran).  The playback is automaically reset and
restarted at underrun.

But, the patch there is wrong.  It should handle -EPIPE, which means
XRUN, while -ESTRPIPE means the suspend state.


Takashi

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3856 bytes --]

On Sun, 24 Jun 2007, Alan Cox wrote:

>> Sory Alan but I don't want philosophical/historical discuss.
>> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
>
> We dropped OSS for ALSA for technical reasons. Those being that ALSA
> - has a better audio API

How better and where better ?
Please be more verbose :>

> - is more flexible

Yes .. if you have API with thin abstracttion (like ALSA has) theoreticaly 
you can do more but also by lack of some abstraction normal/usual things 
must be implemented in harder way. This was theory .. pracice is completly 
diffrent because some applications still provides better soud support 
(without interruption) when uses OSS emulation placed on top ALSA layer 
than compiled for direct use ALSA API.

Sound it in not rocket science. In 99.9% cases you need well abstracted 
API which ALSA doe not provide and this is real cause why so poor sound 
support in Linux applications is. Thin ALSA abstraction is main cause of 
avalaibability "tons" of additional soud user space APIs.
"Nice" plot with current situation you can see on:
http://blogs.adobe.com/penguin.swf/linuxaudio.png

On above blog with this picture you can find more arguments against ALSA. 
Your "more flexible" API in this case mean "ALSA provides only 
atomic/elentar API". Result: look on for example GNOME mixer (or alsa-util 
term based mixer). After each change soud card type in your computer you 
will see changes in triggers set. More .. your "more flexible" API does 
not provides usualy expected soud adjustmets parameters like volume level, 
central balance .. but instead provides PCM level. Try go on street 
(sometimes) and ask some PC users or someone who have at home audio 
devices like TV/radio/whatever and ask them "what is it f* PCM ?".
Yes .. ALSA provides "more flexible API" if you want "fly using glider 
have only raw pieces of wood" .. not if you want just fly and nothing 
more.

On http://blogs.adobe.com/penguin.swf/ you can see also calling for better 
abstracted API.

> - provides OSS as emulation

OSS provides ALSA emulation too.
Sorry but for me there is no technical argument.

> - supports more hardware

Please .. talk obout/back to ALSA/OSS API/KAPI compare.

> I used to maintain the kernel OSS code (the fork when Hannu and friends
> took their project non-free). I did the work to make the sound layer
> modular when the vendors realises that the open one needed to be modular
> and that since that was the main play of the non-free one that Hannu
> wasn't going to be doing it. From a technical perspective ALSA is the
> better design especially for flexible devices.

Look at Hannu blog and grab more arguments against ALSA:
http://www.4front-tech.com/hannublog/

To above I can only add again my argumet (which you saw more than year ago 
and still is without response): ALSA does not provide secure way for manage
sound device on mixing level.

> At the desktop level these days it doesn't really matter much, the
> desktops use their own sound servers which sit on top of OSS, ALSA and
> other sound systems.

So .. why ALSA provides so thin API if in most cases applications 
want only open soud device and/or in some more sohisticated case soud 
device in stere, 4+1, 5+1 or so mode  .. why provide API which not 
provides this expected functionalities in easy way ?
Bad/poor design or API planning or not well educated programmers or maybe 
ALSA still is developed by "belivers" (not enginers) who don't beleve in 
"soft mixing in kernel space isn't possible/secure" (even if it is 
provided in OSS) ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Takashi Iwai]

At Mon, 25 Jun 2007 11:51:59 +0200 (CEST),
Tomasz Kłoczko wrote:
> 
> On Sun, 24 Jun 2007, Alan Cox wrote:
> 
> >> Sory Alan but I don't want philosophical/historical discuss.
> >> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.
> >
> > We dropped OSS for ALSA for technical reasons. Those being that ALSA
> > - has a better audio API
> 
> How better and where better ?
> Please be more verbose :>
> 
> > - is more flexible
> 
> Yes .. if you have API with thin abstracttion (like ALSA has) theoreticaly 
> you can do more but also by lack of some abstraction normal/usual things 
> must be implemented in harder way. This was theory .. pracice is completly 
> diffrent because some applications still provides better soud support 
> (without interruption) when uses OSS emulation placed on top ALSA layer 
> than compiled for direct use ALSA API.
> 
> Sound it in not rocket science. In 99.9% cases you need well abstracted 
> API which ALSA doe not provide and this is real cause why so poor sound 
> support in Linux applications is. Thin ALSA abstraction is main cause of 
> avalaibability "tons" of additional soud user space APIs.

I disagree about this.  Tons of various user-space APIs would be
created anyway.  It's the nature of FOSS developemnt.


Takashi

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1670 bytes --]

On Mon, 25 Jun 2007, Takashi Iwai wrote:
[..]
>> Sound it in not rocket science. In 99.9% cases you need well abstracted
>> API which ALSA doe not provide and this is real cause why so poor sound
>> support in Linux applications is. Thin ALSA abstraction is main cause of
>> avalaibability "tons" of additional soud user space APIs.
>
> I disagree about this.  Tons of various user-space APIs would be
> created anyway.  It's the nature of FOSS developemnt.

Please recall history of (for example) esound.
>From esound README:

"Esound is an audio mixing server that allows multiple
applications to output sound to the same audio device."

It was started in time when most cheap sound cards was without hw mixer.
And .. when today you use ALSA on sound card without hw mixer still all 
this (past ?) problems are actual.
Look on main reasons developing arts ..
In documentation many other user space APIs you can find the same 
or similar reasons. Look .. I'm talkimg about real facts. Your 
disagreement completly ommits *reasons* spending some time on preapare 
this soud APIs.

ALSA still does not provides good soud devices virtualization for more 
then one application. Each day I'm using bludy words when I'm try to use 
skype which oppens /dev/mixer after run galeon with flash plugin which 
opens /dev/snd/pcm* or when I start GNOME session with soud enabled 
(handled by esd whuich uses ALSA).

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Takashi Iwai]

At Mon, 25 Jun 2007 13:36:23 +0200 (CEST),
Tomasz Kłoczko wrote:
> 
> [1  <text/plain; ISO-8859-2 (8bit)>]
> On Mon, 25 Jun 2007, Takashi Iwai wrote:
> [..]
> >> Sound it in not rocket science. In 99.9% cases you need well abstracted
> >> API which ALSA doe not provide and this is real cause why so poor sound
> >> support in Linux applications is. Thin ALSA abstraction is main cause of
> >> avalaibability "tons" of additional soud user space APIs.
> >
> > I disagree about this.  Tons of various user-space APIs would be
> > created anyway.  It's the nature of FOSS developemnt.
> 
> Please recall history of (for example) esound.
> >From esound README:
> 
> "Esound is an audio mixing server that allows multiple
> applications to output sound to the same audio device."
> 
> It was started in time when most cheap sound cards was without hw mixer.
> And .. when today you use ALSA on sound card without hw mixer still all 
> this (past ?) problems are actual.

Huh?  I have no problems with soft mixing...

> Look on main reasons developing arts ..
> In documentation many other user space APIs you can find the same 
> or similar reasons. Look .. I'm talkimg about real facts. Your 
> disagreement completly ommits *reasons* spending some time on preapare 
> this soud APIs.
> 
> ALSA still does not provides good soud devices virtualization for more 
> then one application. Each day I'm using bludy words when I'm try to use 
> skype which oppens /dev/mixer after run galeon with flash plugin which 
> opens /dev/snd/pcm* or when I start GNOME session with soud enabled 
> (handled by esd whuich uses ALSA).

So, do you mean the soft-mixing is the biggest issue?  That's just a
part of a design issue, and if we want to go to that way, the
impelemtation would be trivial, regardless on ALSA or not.  Totally 
irrelevant argument regarding "remove ALSA".


Takashi

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

[Jan Engelhardt]

On Jun 25 2007 14:31, Takashi Iwai wrote:
>> It was started in time when most cheap sound cards was without hw mixer.
>> And .. when today you use ALSA on sound card without hw mixer still all 
>> this (past ?) problems are actual.
>
>Huh?  I have no problems with soft mixing...

Diverging from the discussion, how is soft mixing actually done? If it was done
in userspace, it would need shared memory, or a back relay from kernelspace to
userspace (and back again for the final output), otherwise I could not imagine
how all alsa streams came together at one point.


	Jan
-- 

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

[Olivier Galibert]

On Mon, Jun 25, 2007 at 02:40:23PM +0200, Jan Engelhardt wrote:
> 
> On Jun 25 2007 14:31, Takashi Iwai wrote:
> >> It was started in time when most cheap sound cards was without hw mixer.
> >> And .. when today you use ALSA on sound card without hw mixer still all 
> >> this (past ?) problems are actual.
> >
> >Huh?  I have no problems with soft mixing...
> 
> Diverging from the discussion, how is soft mixing actually done? If it was done
> in userspace, it would need shared memory, or a back relay from kernelspace to
> userspace (and back again for the final output), otherwise I could not imagine
> how all alsa streams came together at one point.

SysV shared memory and semaphores, done in the alsa lib.

Yes, your kernel sound access library does shared mem, semaphores,
fork+exec and friends.

Back relay and virtual devices is the way it should have been done.

  OG.

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

[Takashi Iwai]

At Mon, 25 Jun 2007 14:47:50 +0200,
Olivier Galibert wrote:
> 
> On Mon, Jun 25, 2007 at 02:40:23PM +0200, Jan Engelhardt wrote:
> > 
> > On Jun 25 2007 14:31, Takashi Iwai wrote:
> > >> It was started in time when most cheap sound cards was without hw mixer.
> > >> And .. when today you use ALSA on sound card without hw mixer still all 
> > >> this (past ?) problems are actual.
> > >
> > >Huh?  I have no problems with soft mixing...
> > 
> > Diverging from the discussion, how is soft mixing actually done? If it was done
> > in userspace, it would need shared memory, or a back relay from kernelspace to
> > userspace (and back again for the final output), otherwise I could not imagine
> > how all alsa streams came together at one point.
> 
> SysV shared memory and semaphores, done in the alsa lib.
> 
> Yes, your kernel sound access library does shared mem, semaphores,
> fork+exec and friends.

FYI, fork+exec was removed long time ago.  shmem and semaphores still
remain, though.


Takashi

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

[Olivier Galibert]

On Mon, Jun 25, 2007 at 02:31:08PM +0200, Takashi Iwai wrote:
> So, do you mean the soft-mixing is the biggest issue?  That's just a
> part of a design issue, and if we want to go to that way, the
> impelemtation would be trivial, regardless on ALSA or not.  Totally 
> irrelevant argument regarding "remove ALSA".

Soft mixing is actually the biggest issue because if you had
generalized soft-mixing in the kernel-visible audio ports[1] you would
win two things:

- programs could use the OSS API without interfering with the ALSA one
  or which each other

- programs coult use the ALSA kernel API directly without interfering
  either, which would allow alternative libalsa implementations for
  those who hate the current one

Frankly, mandatory libraries are extremely annoying, and mandatory
extremely complex overdesigned libraries are simply unbearable.

  OG.

[1] Which does *not* mean doing the mixing in the kernel.

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

[Takashi Iwai]

At Mon, 25 Jun 2007 14:44:42 +0200,
Olivier Galibert wrote:
> 
> On Mon, Jun 25, 2007 at 02:31:08PM +0200, Takashi Iwai wrote:
> > So, do you mean the soft-mixing is the biggest issue?  That's just a
> > part of a design issue, and if we want to go to that way, the
> > impelemtation would be trivial, regardless on ALSA or not.  Totally 
> > irrelevant argument regarding "remove ALSA".
> 
> Soft mixing is actually the biggest issue because if you had
> generalized soft-mixing in the kernel-visible audio ports[1] you would
> win two things:
> 
> - programs could use the OSS API without interfering with the ALSA one
>   or which each other
> 
> - programs coult use the ALSA kernel API directly without interfering
>   either, which would allow alternative libalsa implementations for
>   those who hate the current one
> 
> Frankly, mandatory libraries are extremely annoying, and mandatory
> extremely complex overdesigned libraries are simply unbearable.

Hm...  I don't agree much with the virtual relay device solution.
I once experimentally implemented an ALSA-OSS virtual kernel driver.
But, it just gives more complexity.

Yes, the library solution has merits and demerits.  The library should
have been differently designed.  But, I don't think the virtual relay
is the best solution just because you can use a bare kernel
interface...


Takashi

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

[Olivier Galibert]

On Mon, Jun 25, 2007 at 02:58:02PM +0200, Takashi Iwai wrote:
> Hm...  I don't agree much with the virtual relay device solution.
> I once experimentally implemented an ALSA-OSS virtual kernel driver.
> But, it just gives more complexity.

So instead you move the complexity in the library where it is worse.


> Yes, the library solution has merits and demerits.  The library should
> have been differently designed.  But, I don't think the virtual relay
> is the best solution just because you can use a bare kernel
> interface...

Whatever you do in the library won't solve the problem of properly
supporting the OSS interface.

  OG.

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

[Adrian Bunk]

On Mon, Jun 25, 2007 at 02:44:42PM +0200, Olivier Galibert wrote:
> On Mon, Jun 25, 2007 at 02:31:08PM +0200, Takashi Iwai wrote:
> > So, do you mean the soft-mixing is the biggest issue?  That's just a
> > part of a design issue, and if we want to go to that way, the
> > impelemtation would be trivial, regardless on ALSA or not.  Totally 
> > irrelevant argument regarding "remove ALSA".
> 
> Soft mixing is actually the biggest issue because if you had
> generalized soft-mixing in the kernel-visible audio ports[1] you would
> win two things:
> 
> - programs could use the OSS API without interfering with the ALSA one
>   or which each other

This works with aoss.

If people often run into this problem it might make sense to deprecate 
the in-kernel OSS emulation and point people to the userspace emulation 
instead?

> - programs coult use the ALSA kernel API directly without interfering
>   either, which would allow alternative libalsa implementations for
>   those who hate the current one
>...

Allowing for some hypothetical implementation noone might ever write is 
not sucha strong point...

>   OG.
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Nix]

On 25 Jun 2007, Adrian Bunk stated:
> If people often run into this problem it might make sense to deprecate 
> the in-kernel OSS emulation and point people to the userspace emulation 
> instead?

So now people need to know internal implementation details like if a
program uses ALSA or OSS interfaces before they know how to *run* it?

That doesn't sound especially nice to use (and before you say
`distributors will do it', not all programs are built by distributors).

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

[Rene Herman]

On 06/28/2007 08:30 PM, Nix wrote:

> On 25 Jun 2007, Adrian Bunk stated:
>> If people often run into this problem it might make sense to deprecate 
>> the in-kernel OSS emulation and point people to the userspace emulation 
>> instead?
> 
> So now people need to know internal implementation details like if a
> program uses ALSA or OSS interfaces before they know how to *run* it?

Point, but one that does hinge on whether or not you feel you can call using 
the ALSA or OSS interface an implementation detail.

ALSA has been the Linux soundsystem for a number of years now and as such, 
an application that runs under Linux and produces sound more and more can be 
expected to do so using the Linux API. The only reason it _can_ be seen as a 
detail is due to the Just Works nature of the OSS emulation but that is 
changing due to the software mixing. Binary apps are also moving to ALSA 
currently, ie, flash, skype, ...

Anyways, I suspect at least Takashi Iwai would simply say "no" to removing 
or deprecating the in kernel emulation anyway, although it's not likely to 
grow features anymore.

Rene.

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

[Lee Revell]

On 6/28/07, Rene Herman <rene.herman@gmail.com> wrote:
> ALSA has been the Linux soundsystem for a number of years now and as such,
> an application that runs under Linux and produces sound more and more can be
> expected to do so using the Linux API. The only reason it _can_ be seen as a
> detail is due to the Just Works nature of the OSS emulation but that is
> changing due to the software mixing. Binary apps are also moving to ALSA
> currently, ie, flash, skype, ...

If your disto ships with any OSS apps using the in-kernel emulation
you should file a bug report, as it results in bizarre and undesirable
behavior - a single app opening /dev/dsp will block audio for every
other app (OSS or ALSA) on the vast majority of hardware out there.

Lee

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

[Adrian Bunk]

On Thu, Jun 28, 2007 at 04:20:45PM -0400, Lee Revell wrote:
> On 6/28/07, Rene Herman <rene.herman@gmail.com> wrote:
>> ALSA has been the Linux soundsystem for a number of years now and as such,
>> an application that runs under Linux and produces sound more and more can 
>> be
>> expected to do so using the Linux API. The only reason it _can_ be seen as 
>> a
>> detail is due to the Just Works nature of the OSS emulation but that is
>> changing due to the software mixing. Binary apps are also moving to ALSA
>> currently, ie, flash, skype, ...
>
> If your disto ships with any OSS apps using the in-kernel emulation
> you should file a bug report, as it results in bizarre and undesirable
> behavior - a single app opening /dev/dsp will block audio for every
> other app (OSS or ALSA) on the vast majority of hardware out there.

There's software like mplayer that supports both and tries OSS first...

> Lee

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Jeff Garzik]

Rene Herman wrote:
> Anyways, I suspect at least Takashi Iwai would simply say "no" to 
> removing or deprecating the in kernel emulation anyway, although it's 
> not likely to grow features anymore.


Even if he fails to say "no" in such a case, many other people would 
stand up and do so :)  In Linux we generally do not want to remove 
binary userspace interfaces.  Breaking (i.e. changing) the in-kernel API 
is fine, but breaking the userspace ABI is quite another matter.

	Jeff

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

[Adrian Bunk]

On Thu, Jun 28, 2007 at 07:30:36PM +0100, Nix wrote:
> On 25 Jun 2007, Adrian Bunk stated:
> > If people often run into this problem it might make sense to deprecate 
> > the in-kernel OSS emulation and point people to the userspace emulation 
> > instead?
> 
> So now people need to know internal implementation details like if a
> program uses ALSA or OSS interfaces before they know how to *run* it?
> 
> That doesn't sound especially nice to use (and before you say
> `distributors will do it', not all programs are built by distributors).

The interesting point is that what you call "internal implementation 
details" is much _more_ exposed with the OSS emulation in the kernel
_enabled_.

Why?

Linux software not supporting ALSA has becoming quite esoteric.

But software like mplayer supporting both and trying OSS first and 
software supporting both and letting the user choose is today much more 
common. And that's exactly the case where users run into the results of 
the "internal implementation detail" that their application used the 
in-kernel OSS emulation instead of ALSA resulting in exactly these 
problems.

There is also a userspace OSS emulation for ALSA not suffering from 
these problems.

It's not my decision whether or not to remove the in-kernel OSS emulation, 
all I'm saying is that removing it might actually result in less users 
having problems.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Rene Herman]

On 06/28/2007 11:06 PM, Adrian Bunk wrote:

> The interesting point is that what you call "internal implementation 
> details" is much _more_ exposed with the OSS emulation in the kernel 
> _enabled_.
> 
> Why?
> 
> Linux software not supporting ALSA has becoming quite esoteric.
> 
> But software like mplayer supporting both and trying OSS first and 
> software supporting both and letting the user choose is today much more 
> common. And that's exactly the case where users run into the results of 
> the "internal implementation detail" that their application used the 
> in-kernel OSS emulation instead of ALSA resulting in exactly these 
> problems.
> 
> There is also a userspace OSS emulation for ALSA not suffering from these
> problems.
> 
> It's not my decision whether or not to remove the in-kernel OSS
> emulation, all I'm saying is that removing it might actually result in
> less users having problems.

For what it's worth -- I do agree with this...

Rene.

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

[Nix]

On 28 Jun 2007, Adrian Bunk outgrape:
> Linux software not supporting ALSA has becoming quite esoteric.

Indeed. This is why I haven't moaned much (or at all): aoss is ugly,
sure, but you only need it for those rare apps which run for a long time
or while other sounds are playing, on non-mixing-capable hardware, for
which the in-kernel emulation won't suit... and most non-sound-
specialist apps are using esd, arts or pulseaudio anyway, so that does
the mixing for you (and pulseaudio also does it for every ALSA app if
the pulseaudio plugin is installed). And the sound-specialist apps
are the ones that actually *benefit* from ALSA's ludicrous degree of
low-levelness, so they're using it, or something even more flexible
like JACK.

I use quite a lot of sound apps, and I can count the number of times
I've had to use aoss in the last year on the fingers of one hand.


But still it's conceptually ugly. Doing stuff in userspace, yes: but the
kernel should be calling *back* to userspace to do it, not depending on
things being done in the client's address space by a client library for
proper function. (See also others' rants regarding the nasty
quasi-unstable nature of the ALSA ioctl() kernel interface...)

Isn't this sort of big user-to-and-from-kernelspace data-transfer job
what we have relayfs for? (Or is it unidirectional?)

> common. And that's exactly the case where users run into the results of 
> the "internal implementation detail" that their application used the 
> in-kernel OSS emulation instead of ALSA resulting in exactly these 
> problems.
>
> There is also a userspace OSS emulation for ALSA not suffering from 
> these problems.

The problem is that the user has to *know* to run `aoss'. The in-kernel
OSS emulation is actually nicer than thr userspace one because it works
automatically without the user having to do a damned thing. If only it
(and ALSA as a whole) called out to userspace again to mix, we could
presumably ditch aoss, and the user would never need to care which API
the author chose to use. (There are still complexities involving reading
the user's .asoundrc to consider, but most users don't use that so
wouldn't need aoss for anything anymore.)

And then all these damn silly ALSA/OSS flamewars could go away.

> It's not my decision whether or not to remove the in-kernel OSS emulation, 
> all I'm saying is that removing it might actually result in less users 
> having problems.

I think it would lead to *more* problems. The in-kernel emulation
*almost* Just Works, and surely the ideal we should aim for is an
emulation that Just Works.

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously

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

[Florian Schmidt]

On Thursday 28 June 2007, Adrian Bunk wrote:

> There is also a userspace OSS emulation for ALSA not suffering from
> these problems.

Yeah, it suffers from other problems though. It uses an LD_PRELOAD hack to 
intercept library calls that open the /dev/dsp devices etc.. This doesn't 
always work.

I suppose the best way to provide OSS emu is to use something like FUSD 
[similar to the OSS2JACK package] [1] to provide the OSS device files and 
then redirect to user space, so all ALSA pcm devices can be used.. Sadly FUSD 
doesn't really get actively developed anymore it seems. And FUSE can't handle 
ioctls.

[1] http://www.circlemud.org/~jelson/software/fusd/

Regards,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org

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

[Miklos Szeredi]

> I suppose the best way to provide OSS emu is to use something like
> FUSD [similar to the OSS2JACK package] [1] to provide the OSS device
> files and then redirect to user space, so all ALSA pcm devices can
> be used.. Sadly FUSD doesn't really get actively developed anymore
> it seems. And FUSE can't handle ioctls.

Not as if it would be hard to add ioctl support to fuse.  What fuse
can't handle is the data argument of ioctl(), so the most it could do
is give the filesystem a pid (tid) and a virtual address.  The
userspace fs could then get/put the data through /proc/<pid>/mem.

Miklos

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

[Alan Cox]

On Fri, 29 Jun 2007 16:56:05 +0200
Miklos Szeredi <miklos@szeredi.hu> wrote:
> Not as if it would be hard to add ioctl support to fuse.  What fuse
> can't handle is the data argument of ioctl(), so the most it could do
> is give the filesystem a pid (tid) and a virtual address.  The
> userspace fs could then get/put the data through /proc/<pid>/mem.

Hork...

Identify the generic ioctls that are relevant to a FUSE file system and
have real meaning *and* are useful. Teach fuse to turn those to and from
messages properly and if you must add any others (ie if there is good
reason to want them then add a single FUSEFS ioctl something like

	struct fusefs_ioctl {
		u32 opcode;
		void *data_in;
		void *data_out;
		u16 size_in;
		u16 size_out;
	}

so that anything totally weird can be passed through without
horrible /proc/... hacks and without putting tons of cases into FUSE

		

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

[Miklos Szeredi]

> Miklos Szeredi <miklos@szeredi.hu> wrote:
> > Not as if it would be hard to add ioctl support to fuse.  What fuse
> > can't handle is the data argument of ioctl(), so the most it could do
> > is give the filesystem a pid (tid) and a virtual address.  The
> > userspace fs could then get/put the data through /proc/<pid>/mem.
> 
> Hork...
> 
> Identify the generic ioctls that are relevant to a FUSE file system and
> have real meaning *and* are useful.

I don't think there are any such.

The point in this thread was I think about emulating an OSS sound
device through a fuse fs.  In that case fuse would need _generic_
ioctl support, which simply can't be done without weird userspace
hacks.  I'm definitely not adding specific ioctls to fuse.

Miklos

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

[Miklos Szeredi]

> > > Not as if it would be hard to add ioctl support to fuse.  What fuse
> > > can't handle is the data argument of ioctl(), so the most it could do
> > > is give the filesystem a pid (tid) and a virtual address.  The
> > > userspace fs could then get/put the data through /proc/<pid>/mem.
> > 
> > Hork...
> > 
> > Identify the generic ioctls that are relevant to a FUSE file system and
> > have real meaning *and* are useful.
> 
> I don't think there are any such.
> 
> The point in this thread was I think about emulating an OSS sound
> device through a fuse fs.  In that case fuse would need _generic_
> ioctl support, which simply can't be done without weird userspace
> hacks.

Well, had a look at what FUSD does.  It assumes that the ioctl
argument is stuctured according to the command.  If all OSS ioctls are
like that, then fine, fuse can support it properly.

The drawback of this is that ioctls which aren't structured properly
could cause weird failures due to wrong data being accessed by the
poor unknowing kernel.

Miklos

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

[Florian Schmidt]

On Friday 29 June 2007, Miklos Szeredi wrote:
> > > > Not as if it would be hard to add ioctl support to fuse.  What fuse
> > > > can't handle is the data argument of ioctl(), so the most it could do
> > > > is give the filesystem a pid (tid) and a virtual address.  The
> > > > userspace fs could then get/put the data through /proc/<pid>/mem.
> > >
> > > Hork...
> > >
> > > Identify the generic ioctls that are relevant to a FUSE file system and
> > > have real meaning *and* are useful.
> >
> > I don't think there are any such.
> >
> > The point in this thread was I think about emulating an OSS sound
> > device through a fuse fs.  In that case fuse would need _generic_
> > ioctl support, which simply can't be done without weird userspace
> > hacks.
>
> Well, had a look at what FUSD does.  It assumes that the ioctl
> argument is stuctured according to the command.  If all OSS ioctls are
> like that, then fine, fuse can support it properly.
>
> The drawback of this is that ioctls which aren't structured properly
> could cause weird failures due to wrong data being accessed by the
> poor unknowing kernel.
>
> Miklos

Included with the docs there's a list of the OSS ioctls. I don't understand 
enough of the problem to judge whether they are suitable to be handled by 
FUSE:

http://manuals.opensound.com/developer/ioctl.html [version 4]
http://www.4front-tech.com/pguide/oss.pdf [version 3]

I don't know which API version is supposed to be supported though.

Regards,
Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org

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

[Miklos Szeredi]

> > Well, had a look at what FUSD does.  It assumes that the ioctl
> > argument is stuctured according to the command.  If all OSS ioctls are
> > like that, then fine, fuse can support it properly.
> >
> > The drawback of this is that ioctls which aren't structured properly
> > could cause weird failures due to wrong data being accessed by the
> > poor unknowing kernel.
> 
> Included with the docs there's a list of the OSS ioctls. I don't understand 
> enough of the problem to judge whether they are suitable to be handled by 
> FUSE:
> 
> http://manuals.opensound.com/developer/ioctl.html [version 4]
> http://www.4front-tech.com/pguide/oss.pdf [version 3]
> 
> I don't know which API version is supposed to be supported though.

Thanks, but these docs are about what the ioctls do, and I'm totally
uninterested in that.  What I'm interested is how the ioctl data is
_structured_.

OK, had a look at <linux/soundcard.h>, it does define a data
structuring based on the ioctl numbers, and it's just slightly
different from the structuring defined by <asm-generic/ioctl.h>.  Oh,
the beauty of the ioctls.

So answering my own question: no, it's not sanely possible to support
ioctls through fuse without userspace hacks or significant effort.

A possibly acceptable option is to add a plugin mechanism, whereby
people could write small ioctl interpreter kernel modules for their
specific needs (such as parsing OSS ioctls), which would
serialize/deserialize any type of ioctl input/output making them
suitable for transfering between the kernel and the userspace
filesystem.

Another, much more complex option is to design a generic ioctl data
interpreter language, and let the filesystem upload their ioctl
parsers into the kernel.

Miklos

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

[Pavel Machek]

Hi!
> > 
> > Soft mixing is actually the biggest issue because if you had
> > generalized soft-mixing in the kernel-visible audio ports[1] you would
> > win two things:
> > 
> > - programs could use the OSS API without interfering with the ALSA one
> >   or which each other
> 
> This works with aoss.
> 
> If people often run into this problem it might make sense to deprecate 
> the in-kernel OSS emulation and point people to the userspace emulation 
> instead?

Without in-kernel OSS emulation, it is very hard to verify if kernel
sound support works properly. OSS could been driven from shell for
testing, and I believe that's still important feature to keep.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 8607 bytes --]

On Mon, 25 Jun 2007, Takashi Iwai wrote:
[..]
>> ALSA still does not provides good soud devices virtualization for more
>> then one application. Each day I'm using bludy words when I'm try to use
>> skype which oppens /dev/mixer after run galeon with flash plugin which
>> opens /dev/snd/pcm* or when I start GNOME session with soud enabled
>> (handled by esd whuich uses ALSA).
>
> So, do you mean the soft-mixing is the biggest issue?  That's just a
> part of a design issue, and if we want to go to that way, the
> impelemtation would be trivial, regardless on ALSA or not.  Totally
> irrelevant argument regarding "remove ALSA".

I dont know is soft mixing is biggest issue but ..
Few minutes ago I'm upgrade to skype 1.4.x.

Lets try again above experiment:

$ strace -f -e trace=file galeon 2>&1 | grep dev/snd
[pid 28593] open("/dev/snd/controlC0", O_RDWR) = 46
[pid 28593] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 47

OK .. now I'm enter on www.youtube.com and start playing random video.
Look on above: soud device was oppened in non bloking mode.

After few seconds I'm close tab with video in galeon.
Just after this I'm start skype and try call to test123 and calling isn't 
possible:

$ strace -f -e trace=file skype 2>&1 | grep dev/snd
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC3", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC4", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC5", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC6", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC7", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC8", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC9", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC10", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC11", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC12", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC13", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC14", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC15", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC16", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC17", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC18", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC19", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC20", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC21", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC22", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC23", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC24", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC25", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC26", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC27", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC28", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC29", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC30", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC31", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC1", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC2", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC3", O_RDONLY <unfinished ...>
[pid 30173] open("/dev/snd/controlC4", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC5", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC6", O_RDONLY <unfinished ...>
[pid 30173] open("/dev/snd/controlC7", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC8", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC9", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC10", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC11", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC12", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC13", O_RDONLY <unfinished ...>
[pid 30173] open("/dev/snd/controlC14", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC15", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC16", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC17", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC18", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC19", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC20", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC21", O_RDONLY) =tory)
[pid 30173] open("/dev/snd/controlC23", O_RDo such file or directory)
[pid 30173] open("/dev/snd/controlC24", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/control O_RDONLY) = -1 ENOENT (No suchfile or directory)
[pid 30173] open("/dev/snd/controlC26", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC27", O_RDONLY) = -1 ENOENsuch file or directory)
[pid 30173] open("/ev/snd/controlC28", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC29", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/controlC30", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 30173] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_ASYNC) = -1 EBUSY (Device or resource busy)
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/pcmC0D0c", O_RDWR|O_NONBLOCK|O_ASYNC) = 44
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/pcmC0D0c", O_RDWR|O_NONBLOCK|O_ASYNC) = 44
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDWR|O_NONBLOCK) = 43
[pid 30173] open("/dev/snd/controlC0", O_RDONLY) = 44
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 44
[pid 30173] open("/dev/snd/controlC0", O_RDWR) = 44
[pid 30173] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_ASYNC) = -1 EBUSY (Device or resource busy)
[..]

/dev/snd/pcmC0D0p is busy ? YES because it was oppened by another 
application in non blocking mode which makes device .. unavalable to other :)
Welcome in wonderful ALSA word ..

And interesting .. why skype tries to open so meny devices (?)

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Rene Herman]

On 06/25/2007 07:00 PM, Tomasz Kłoczko wrote:

> $ strace -f -e trace=file galeon 2>&1 | grep dev/snd
> [pid 28593] open("/dev/snd/controlC0", O_RDWR) = 46
> [pid 28593] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 47

[ ... ]

> [pid 30173] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_ASYNC) = -1 
> EBUSY (Device or resource busy)
> [..]
> 
> /dev/snd/pcmC0D0p is busy ? YES because it was oppened by another 
> application in non blocking mode which makes device .. unavalable to 
> other :)

Nothing to do with O_NONBLOCK:

$ strace -f -e trace=file firefox 2>&1 | grep dev/snd
[pid  1889] ....
[pid  1889] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = 38
[pid  1889] open("/dev/snd/controlC0", O_RDONLY) = 37
[pid  1889] open("/dev/snd/timer", O_RDONLY|O_NONBLOCK) = 37

$ strace -f -e trace=file ogg123 foo.ogg 2>&1 | grep dev/snd
[pid  1916] ...
[pid  1916] open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK|O_APPEND) = 5
[pid  1916] open("/dev/snd/controlC0", O_RDONLY) = 4
[pid  1916] open("/dev/snd/timer", O_RDONLY|O_NONBLOCK) = 4

And both the youtube video (flash 9) and my ogg file play fine. Now, I don't 
actually know about that O_ASYNC thing you have in there but it looks as 
though you're simply not using dmix. Which card, and if you specify an ALSA 
device somewhere, is it the "default" device?

And fix your inbound mailer -- it's rejecting my posts.

Rene.

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

[Gabor Gombas]

On Mon, Jun 25, 2007 at 01:36:23PM +0200, Tomasz Kłoczko wrote:

> ALSA still does not provides good soud devices virtualization for more then 
> one application. Each day I'm using bludy words when I'm try to use skype 
> which oppens /dev/mixer [...]

Not true anymore:

skype   32381 gombasg  mem       CHR      116,7               4663 /dev/snd/pcmC0D0p
skype   32381 gombasg   32r      CHR      116,2               4301 /dev/snd/timer
skype   32381 gombasg   34u      CHR      116,7               4663 /dev/snd/pcmC0D0p
skype   32381 gombasg   35u      CHR      116,9               4674 /dev/snd/controlC0

I do not even have the OSS compat interface enabled in my kernel.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1172 bytes --]

On Mon, 25 Jun 2007, Gabor Gombas wrote:

> On Mon, Jun 25, 2007 at 01:36:23PM +0200, Tomasz Kłoczko wrote:
>
>> ALSA still does not provides good soud devices virtualization for more then
>> one application. Each day I'm using bludy words when I'm try to use skype
>> which oppens /dev/mixer [...]
>
> Not true anymore:
>
> skype   32381 gombasg  mem       CHR      116,7               4663 /dev/snd/pcmC0D0p
> skype   32381 gombasg   32r      CHR      116,2               4301 /dev/snd/timer
> skype   32381 gombasg   34u      CHR      116,7               4663 /dev/snd/pcmC0D0p
> skype   32381 gombasg   35u      CHR      116,9               4674 /dev/snd/controlC0
>
> I do not even have the OSS compat interface enabled in my kernel.

Sorry but skype does not for me after switching to ALSA (on skype cfg 
level). 
Probably ALSA developers can explain why :>
All above on fresh FC6 and 1.3.53 skype.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Gabor Gombas]

On Mon, Jun 25, 2007 at 03:41:44PM +0200, Tomasz Kłoczko wrote:

> Sorry but skype does not for me after switching to ALSA (on skype cfg 
> level). Probably ALSA developers can explain why :>
> All above on fresh FC6 and 1.3.53 skype.

$ dpkg -l | grep skype
ii  skype                             1.4.0.74-1

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------

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

[Renato S. Yamane]

Tomasz Kłoczko wrote:
> ALSA still does not provides good soud devices virtualization for more 
> then one application. Each day I'm using bludy words when I'm try to use 
> skype which oppens /dev/mixer after run galeon with flash plugin which 
> opens /dev/snd/pcm* or when I start GNOME session with soud enabled 
> (handled by esd whuich uses ALSA).


Install alsa-oss fix this problem?
<http://www.skype.com/help/guides/soundsetup_linux.html>

Best regards,
Renato

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2479 bytes --]

On Mon, 25 Jun 2007, Renato S. Yamane wrote:

> Tomasz Kłoczko wrote:
>> ALSA still does not provides good soud devices virtualization for more then 
>> one application. Each day I'm using bludy words when I'm try to use skype 
>> which oppens /dev/mixer after run galeon with flash plugin which opens 
>> /dev/snd/pcm* or when I start GNOME session with soud enabled (handled by 
>> esd whuich uses ALSA).
>
>
> Install alsa-oss fix this problem?
> <http://www.skype.com/help/guides/soundsetup_linux.html>

No. Read above again and you will see I'm taking about using OSS emulation 
on top ALSA. It does not work with above scenario.

# lsmod | grep snd
snd_emu10k1_synth      11073  0
snd_emux_synth         35681  1 snd_emu10k1_synth
snd_seq_virmidi        11336  1 snd_emux_synth
snd_seq_midi_emul      10049  1 snd_emux_synth
snd_emu10k1           131121  2 snd_emu10k1_synth
snd_intel8x0           36837  5
snd_seq_dummy           7877  0
snd_ac97_codec         98941  2 snd_emu10k1,snd_intel8x0
snd_seq_oss            34257  0
snd_mpu401             12521  0
snd_mpu401_uart        12633  1 snd_mpu401
snd_seq_midi_event     11337  2 snd_seq_virmidi,snd_seq_oss
snd_rawmidi            27233  3 snd_seq_virmidi,snd_emu10k1,snd_mpu401_uart
snd_seq                52377  8 snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
ac97_bus                6721  1 snd_ac97_codec
snd_seq_device         12245  7 snd_emu10k1_synth,snd_emux_synth,snd_emu10k1,snd_seq_dummy,snd_seq_oss,snd_rawmidi,snd_seq
snd_pcm_oss            44129  0
snd_mixer_oss          19785  4 snd_pcm_oss
snd_util_mem            8904  2 snd_emux_synth,snd_emu10k1
snd_pcm                76653  5 snd_emu10k1,snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_hwdep              13133  2 snd_emux_synth,snd_emu10k1
snd_timer              25565  3 snd_emu10k1,snd_seq,snd_pcm
snd                    55301  21 snd_emux_synth,snd_seq_virmidi,snd_emu10k1,snd_intel8x0,snd_ac97_codec,snd_seq_oss,snd_mpu401,snd_mpu401_uart,snd_rawmidi,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_hwdep,snd_timer
soundcore              11809  4 snd
snd_page_alloc         13897  3 snd_emu10k1,snd_intel8x0,snd_pcm

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Rene Herman]

On 06/25/2007 01:36 PM, Tomasz Kłoczko wrote:

> Please recall history of (for example) esound.
>> From esound README:
> 
> "Esound is an audio mixing server that allows multiple
> applications to output sound to the same audio device."
> 
> It was started in time when most cheap sound cards was without hw mixer.

The same situation as today, that is.

> And .. when today you use ALSA on sound card without hw mixer still all 
> this (past ?) problems are actual.

ALSA mixes by default since something like 1.0.10 (november 2005).

> Look on main reasons developing arts ..

Which started at a time there was no ALSA, has been basically dead for 6 
years now and has at the moment finally been dropped by its last user.

> In documentation many other user space APIs you can find the same or 
> similar reasons. Look .. I'm talkimg about real facts. Your disagreement
> completly ommits *reasons* spending some time on preapare this soud
> APIs.

The "linux audio jungle" picture you posted a link to:

http://blogs.adobe.com/penguin.swf/linuxaudio.png

shows more arrows pointing to OSS than it does to ALSA and with a number of 
those coming from things that existed before there even was an ALSA and yet 
somehow you maintain this userspace audio jungle is ALSA's fault?

The Linux userspace audio situation is improving; since software mixing, 
plain vanilla ALSA is a good, single solution to a majority of uses and 
something like Phonon which is going to arrive later this year seems poised 
to provide a nice high level API, including for people who believe that 
audio is about playing you-got-mail jingles.

The reason we're not there yet is in part _due_ to people maintaining that 
OSS is somehow a valid choice on Linux. Ie:

> ALSA still does not provides good soud devices virtualization for more 
> then one application. Each day I'm using bludy words when I'm try to use
> skype which oppens /dev/mixer after run galeon [ ... ]

/dev/mixer is an OSS device. Recent versions of skype should (as far as I've 
been told) be able to use native ALSA but if you're using an older version 
you get what you asked for. Should the ALSA OSS emulation try its damndest 
to support proprietary, bugridden closed source junk such as skype? Opinions 
probably vary but I'd say yes. Let's not make it, old versions of it at 
that, into the reference application though.

Video is a much more significant problem for desktop Linux than audio is and 
solutions are going to arrive combined as they are both userspace (ie, not 
kernel, not DRI, not ALSA, not OSS) multimedia problems. I have high hopes 
especially for the new technologies that went into KDE4. Haven't payed much 
attention to GNOME though so not sure what they're upto. Non-stellar 
cooperation between those two large desktop initiatives in the field of 
multimedia is another reason for things not being there yet. Go bark up 
those trees instead.

Rene.

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

[Carlo Florendo]

Tomasz Kłoczko wrote:
> On Sun, 24 Jun 2007, Alan Cox wrote:
> [..]
>> Years ago Linux dumped OSS for ALSA because ALSA offered far better
>> functionality and support. Why would we go back to the stone age ?
>>
>> Its something useful to various other platforms with basically no
>> hardware support but Linux has ALSA and very good hardware support and
>> ALSA even has emulation for back compatibility with old OSS apps.
>>
>> Ten years ago it would probably have made a difference, five maybe, today
>> its a release of historical code at best, and since they shipped binary
>> modules for Linux more like 'getting around to complying with the
>> licence' than anything else.
> 
> Sory Alan but I don't want philosophical/historical discuss.
> Try to answer on question "ALSA or OSS ?" using *only* technical arguments.

You dare to demand technical arguments while you have not provided a single 
one.  How dare you?


-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

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

[Carlo Florendo]

Tomasz Kłoczko wrote:
> 
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and 
> GLPv2 for Linux:
> 
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> 
> So this source without problems code can be integragrated in Linus tree 
> and after this Linux can provide much better soud supoport than with 
> current ALSA.

Actually, ALSA is doing fine and doing great.  There are issues of course, 
and some bugs too, but they've got their mailing list and Takashi Iwai 
fixes things quite well (and fast). Calling something crap will be useless 
until you can prove it.  One minor complaint I have with ALSA is its 
documentation.  It provides basic stuff but one has to do a lot of 
cross-references, IMHO, to understand its API.  Other than that, with a 
mature open code base, ALSA is more excellent than OSS.

Before calling things crap, you should be more technical and realistic 
(i.e. prove it with example).  Otherwise, you will just be wasting your 
time whining.  It shows too your lack of technical skill since you complain 
without knowing what you're complaining about.

Best Regards,

Carlo

-- 
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, Diliman 1101, Quezon City
Philippines
http://www.astra.ph

--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp

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

[Takashi Iwai]

At Sun, 24 Jun 2007 19:51:38 +0200 (CEST),
Tomasz Kłoczko wrote:
> 
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
> for Linux:
> 
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> 
> So this source without problems code can be integragrated in Linus tree 
> and after this Linux can provide much better soud supoport than 
> with current ALSA.
> 
> Any plans for doing this ?

Did you count the number of devices that tree supports?
You'll loose the support of all new laptops and mobos sold in the last
year :)

Honestly, I'm not fully against changing the current code base (or
crap, whatever, any childish name).  There are indeed many misdesigns.
But, replacing with the above is no option, IMO.  The OSS have also
many misdesigns, so the same argument would start again.  One should
learn something from history...

Anyway, if it's going to be more constructive, I'm willing to join in.


Takashi

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1538 bytes --]

On Mon, 25 Jun 2007, Takashi Iwai wrote:
[..]
>> Any plans for doing this ?
>
> Did you count the number of devices that tree supports?

What is harder ? Bring ALSA API to the same level of functionalities as 
OSS provides or port (FOSS) ALSA device drivers to OSS ?

> You'll loose the support of all new laptops and mobos sold in the last
> year :)

You are loosing point lack of will ALSA developers to make this useable, 
and well documented. OSS it is stabkle API specyfication with good 
reputation. ALSA still is in development stage.

> Honestly, I'm not fully against changing the current code base (or
> crap, whatever, any childish name).  There are indeed many misdesigns.
> But, replacing with the above is no option, IMO.  The OSS have also
> many misdesigns, so the same argument would start again.  One should
> learn something from history...

OSS is at all misdesigned ? or in some points ? if partialy it was bad (in 
time start work on ALSA) why was not improved ?
For me it looks like ALSA developers don't know "don't move - improve" 
sentence.

kloczek
PS. /me still waiting for simple yes or no answer on my qustion from 
responsible people.
For example: if Hannu or other OSS developer will bring some patches it 
will be integrated or not in main tree ?
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Bartlomiej Zolnierkiewicz]

Hi,

On Monday 25 June 2007, Tomasz Kłoczko wrote:
> On Mon, 25 Jun 2007, Takashi Iwai wrote:
> [..]
> >> Any plans for doing this ?
> >
> > Did you count the number of devices that tree supports?
> 
> What is harder ? Bring ALSA API to the same level of functionalities as 
> OSS provides or port (FOSS) ALSA device drivers to OSS ?

This is impossible to answer unless somebody does the both
(as usual with the software).

> > You'll loose the support of all new laptops and mobos sold in the last
> > year :)
> 
> You are loosing point lack of will ALSA developers to make this useable, 
> and well documented. OSS it is stabkle API specyfication with good 
> reputation. ALSA still is in development stage.

Talking ALSA developers into adapting OSS seems to be a dead end road.

> > Honestly, I'm not fully against changing the current code base (or
> > crap, whatever, any childish name).  There are indeed many misdesigns.
> > But, replacing with the above is no option, IMO.  The OSS have also
> > many misdesigns, so the same argument would start again.  One should
> > learn something from history...
> 
> OSS is at all misdesigned ? or in some points ? if partialy it was bad (in 
> time start work on ALSA) why was not improved ?

Probably because of "two steps forward and one step back" rule. :)

Learning from history would mean moving forward and creating next generation
sound subsystem better than both ALSA and OSS.  This of course would require
cooperation between ALSA and OSS developers which may be the biggest problem.

> For me it looks like ALSA developers don't know "don't move - improve" 
> sentence.
> kloczek
> PS. /me still waiting for simple yes or no answer on my qustion from 
> responsible people.
> For example: if Hannu or other OSS developer will bring some patches it 
> will be integrated or not in main tree ?

Depends on patches, just bring them on!

Having some competition would be a good thing for both ALSA and OSS.

Thanks,
Bart

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

[Hannu Savolainen]

Takashi Iwai kirjoitti:
> At Sun, 24 Jun 2007 19:51:38 +0200 (CEST),
> Tomasz Kłoczko wrote:
>   
>> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
>> for Linux:
>>
>> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
>>
>> So this source without problems code can be integragrated in Linus tree 
>> and after this Linux can provide much better soud supoport than 
>> with current ALSA.
>>
>> Any plans for doing this ?
>>     
>
> Did you count the number of devices that tree supports?
> You'll loose the support of all new laptops and mobos sold in the last
> year :)
>   
They are all based on HD audio which is supported by OSS. Ok, our HDA 
driver driver still needs some work which was one of the reasons why we 
are moving to the community development model.
> Honestly, I'm not fully against changing the current code base (or
> crap, whatever, any childish name).  There are indeed many misdesigns.
> But, replacing with the above is no option, IMO.  The OSS have also
> many misdesigns, so the same argument would start again.  One should
> learn something from history...
>   
Exactly. Good to know that we are both thinking in the same way.
> Anyway, if it's going to be more constructive, I'm willing to join in.
>   
I think it's going to be constructive.

We have no intention to push OSS back to the kernel or to replace ALSA. 
That alternative is not realistic any more. In addition OSS is a 
cross-platform product and staying more or less outside various kernel 
trees should provide better flexibility.

What we would like to push is that the old "deprecated" OSS/Free are 
removed from the kernel. OSS/Free is based on about years old OSS API 
version which was too limited for many applications. Having OSS/Free in 
the kernel doesn't serve any purpose.

Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are 
rather different. Both of them have some good points and bad points. For 
ordinary users it doesn't matter which API is used by the applications 
as long as they work. Just the application developers can see the real 
difference. Some of them prefer OSS while some other prefer ALSA and 
this should be their "freedom of choice".

I think the ideal solution would be that both ALSA and OSS APIs can 
co-exist by sharing the same low level drivers (which has already been 
demonstrated). The low level driver interfaces in both systems are 
practically identical. This means that ALSA's core can work with OSS' 
drivers and vice versa.

Today both OSS and ALSA teams have to spend significant amounts of time 
in emulating the "alien" APIs. Making OSS and ALSA to co-exist will 
require some work in both sides but that should be nothing when compared 
to the effort required for emulation.

Just my 2 cents.

Best regards,

Hannu

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

[Adrian Bunk]

On Tue, Jun 26, 2007 at 12:18:05AM +0300, Hannu Savolainen wrote:
>...
> What we would like to push is that the old "deprecated" OSS/Free are 
> removed from the kernel. OSS/Free is based on about years old OSS API 
> version which was too limited for many applications. Having OSS/Free in the 
> kernel doesn't serve any purpose.

I am slowly removing all parts of the in-kernel OSS with ALSA drivers 
for the same hardware.

The remaining drivers can roughly be divided into two categories:
- some ISA cards not supported by ALSA
- some drivers for unusual hardware (read: not a PC) not supported by ALSA

As long as we don't have ALSA drivers for them (which might in some 
cases never happen) I'd prefer to keep them for now.

> Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are 
> rather different. Both of them have some good points and bad points. For 
> ordinary users it doesn't matter which API is used by the applications as 
> long as they work. Just the application developers can see the real 
> difference. Some of them prefer OSS while some other prefer ALSA and this 
> should be their "freedom of choice".
>...

I'm glad to hear this.  :-)

> Best regards,
>
> Hannu

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Wakko Warner]

Adrian Bunk wrote:
> On Tue, Jun 26, 2007 at 12:18:05AM +0300, Hannu Savolainen wrote:
> >...
> > What we would like to push is that the old "deprecated" OSS/Free are 
> > removed from the kernel. OSS/Free is based on about years old OSS API 
> > version which was too limited for many applications. Having OSS/Free in the 
> > kernel doesn't serve any purpose.
> 
> I am slowly removing all parts of the in-kernel OSS with ALSA drivers 
> for the same hardware.

I have a motherboard with an intel chipset and onboard audio.  I have a
problem with alsa.  There's no pcm* files in /proc/asound/card0.

I tried quake on it which didn't work.  I remembered the problem with oss
use on alsa and tried to do the echo "..." as stated in the kernel docs only
to find out the path doesn't exist.  Here's what I see:

[wakko@gohan:/proc/asound/card0] ls -l
total 0
dr-xr-xr-x  2 root root 0 Jun 26 12:26 codec97#0/
-r--r--r--  1 root root 0 Jun 26 12:26 id
-r--r--r--  1 root root 0 Jun 26 12:26 intel8x0
-rw-r--r--  1 root root 0 Jun 26 12:26 oss_mixer
[wakko@gohan:/proc/asound/card0] lspci -vns 1f.5
0000:00:1f.5 0401: 8086:24c5 (rev 02)
        Subsystem: 414c:4730
        Flags: bus master, medium devsel, latency 0, IRQ 5
        I/O ports at e000 [size=256]
        I/O ports at e400 [size=64]
        Memory at e0581000 (32-bit, non-prefetchable) [size=512]
        Memory at e0582000 (32-bit, non-prefetchable) [size=256]
        Capabilities: <available only to root>

[wakko@gohan:/proc/asound/card0] dmesg|tail -4
[  313.942182] ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 5
(level, low) -> IRQ 5
[  313.942229] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[  314.293944] intel8x0_measure_ac97_clock: measured 52586 usecs
[  314.294097] intel8x0: clocking to 48000
[wakko@gohan:/proc/asound/card0] uname -a
Linux gohan 2.6.21 #1 PREEMPT Sat Jun 23 23:36:48 EDT 2007 i686 GNU/Linux
[wakko@gohan:/proc/asound/card0] 

This is a BCM IN845GV board.

What is interesting is the same driver (kernel 2.6.20) and the same pciid
(except for subsystem) works fine on another machine.
[wakko@vegeta:/proc/asound/card0] ls -l
total 0
dr-xr-xr-x 2 root root 0 Jun 26 12:29 codec97#0/
-r--r--r-- 1 root root 0 Jun 26 12:29 id
-r--r--r-- 1 root root 0 Jun 26 12:29 intel8x0
-rw-r--r-- 1 root root 0 Jun 26 12:29 oss_mixer
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm0c/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm0p/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm1c/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm2c/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm3c/
dr-xr-xr-x 3 root root 0 Jun 26 12:29 pcm4p/
[wakko@vegeta:/proc/asound/card0] lspci -vns 1f.5
00:1f.5 0401: 8086:24c5 (rev 02)
        Subsystem: 15d9:4080
        Flags: bus master, medium devsel, latency 0, IRQ 24
        I/O ports at 2000 [size=256]
        I/O ports at 2400 [size=64]
        Memory at b0000c00 (32-bit, non-prefetchable) [size=512]
        Memory at b0000800 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>

[wakko@vegeta:/proc/asound/card0] 

Dmsg for this driver:
[  110.504446] ACPI: PCI Interrupt 0000:00:1f.5[B] -> GSI 17 (level, low) -> IRQ 24
[  110.504636] PCI: Setting latency timer of device 0000:00:1f.5 to 64
[  110.818894] intel8x0_measure_ac97_clock: measured 52791 usecs
[  110.818949] intel8x0: clocking to 48000

This is a Supermicro X5DA8 board (This one works fine!).

I don't know what to do with the BCM board other than just use OSS drivers
which work just fine on this board.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

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

[Takashi Iwai]

At Tue, 26 Jun 2007 12:25:16 -0400,
Wakko Warner wrote:
> 
> Adrian Bunk wrote:
> > On Tue, Jun 26, 2007 at 12:18:05AM +0300, Hannu Savolainen wrote:
> > >...
> > > What we would like to push is that the old "deprecated" OSS/Free are 
> > > removed from the kernel. OSS/Free is based on about years old OSS API 
> > > version which was too limited for many applications. Having OSS/Free in the 
> > > kernel doesn't serve any purpose.
> > 
> > I am slowly removing all parts of the in-kernel OSS with ALSA drivers 
> > for the same hardware.
> 
> I have a motherboard with an intel chipset and onboard audio.  I have a
> problem with alsa.  There's no pcm* files in /proc/asound/card0.

Set CONFIG_SND_VERBOSE_PROCFS=y.


Takashi

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

[Wakko Warner]

Takashi Iwai wrote:
> At Tue, 26 Jun 2007 12:25:16 -0400,
> Wakko Warner wrote:
> > I have a motherboard with an intel chipset and onboard audio.  I have a
> > problem with alsa.  There's no pcm* files in /proc/asound/card0.
> 
> Set CONFIG_SND_VERBOSE_PROCFS=y.

GAH!  Thanks, I didn't think I needed it but it is set on the one that
works.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
 Got Gas???

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

[Takashi Iwai]

At Tue, 26 Jun 2007 00:18:05 +0300,
Hannu Savolainen wrote:
> 
> Takashi Iwai kirjoitti:
> > At Sun, 24 Jun 2007 19:51:38 +0200 (CEST),
> > Tomasz Kłoczko wrote:
> >   
> >> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
> >> for Linux:
> >>
> >> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> >>
> >> So this source without problems code can be integragrated in Linus tree 
> >> and after this Linux can provide much better soud supoport than 
> >> with current ALSA.
> >>
> >> Any plans for doing this ?
> >>     
> >
> > Did you count the number of devices that tree supports?
> > You'll loose the support of all new laptops and mobos sold in the last
> > year :)
> >   
> They are all based on HD audio which is supported by OSS. Ok, our HDA 
> driver driver still needs some work which was one of the reasons why we 
> are moving to the community development model.

The HD-audio is still messy on ALSA, too.
There are a lot room to improve there.

> > Honestly, I'm not fully against changing the current code base (or
> > crap, whatever, any childish name).  There are indeed many misdesigns.
> > But, replacing with the above is no option, IMO.  The OSS have also
> > many misdesigns, so the same argument would start again.  One should
> > learn something from history...
> >   
> Exactly. Good to know that we are both thinking in the same way.
> > Anyway, if it's going to be more constructive, I'm willing to join in.
> >   
> I think it's going to be constructive.
> 
> We have no intention to push OSS back to the kernel or to replace ALSA. 
> That alternative is not realistic any more. In addition OSS is a 
> cross-platform product and staying more or less outside various kernel 
> trees should provide better flexibility.
> 
> What we would like to push is that the old "deprecated" OSS/Free are 
> removed from the kernel. OSS/Free is based on about years old OSS API 
> version which was too limited for many applications. Having OSS/Free in 
> the kernel doesn't serve any purpose.
> 
> Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are 
> rather different. Both of them have some good points and bad points. For 
> ordinary users it doesn't matter which API is used by the applications 
> as long as they work. Just the application developers can see the real 
> difference. Some of them prefer OSS while some other prefer ALSA and 
> this should be their "freedom of choice".

Fully agreed, and I'm glad that we can go to constructive discussions
:)

> I think the ideal solution would be that both ALSA and OSS APIs can 
> co-exist by sharing the same low level drivers (which has already been 
> demonstrated). The low level driver interfaces in both systems are 
> practically identical. This means that ALSA's core can work with OSS' 
> drivers and vice versa.

Yeah, that's in my mind, too.
The ALSA driver codes are fairly modularized and have separate core
and accessor codes.  The latter, lowlevel driver code, could be
relatively easily adapted to different frameworks.  This can be a
win-win.

However, the question again is a "bigger picture" of the whole sound
system -- what to be included in the kernel side and what to be in
user-space.  For example, a typical problem is software mixing.  Also,
we can't forget the sample rate conversion since SRC may influence
much more on the sound quality than mixing.  More discussions about
such a system design should be done at this time.


thanks,

Takashi

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

[Jeff Garzik]

Hannu Savolainen wrote:
> Also we would like to stop the silly OSS vs ALSA war. OSS and ALSA are 
> rather different. Both of them have some good points and bad points. For 
> ordinary users it doesn't matter which API is used by the applications 
> as long as they work. Just the application developers can see the real 
> difference. Some of them prefer OSS while some other prefer ALSA and 
> this should be their "freedom of choice".
> 
> I think the ideal solution would be that both ALSA and OSS APIs can 
> co-exist by sharing the same low level drivers (which has already been 
> demonstrated). The low level driver interfaces in both systems are 
> practically identical. This means that ALSA's core can work with OSS' 
> drivers and vice versa.
> 
> Today both OSS and ALSA teams have to spend significant amounts of time 
> in emulating the "alien" APIs. Making OSS and ALSA to co-exist will 
> require some work in both sides but that should be nothing when compared 
> to the effort required for emulation.

Speaking as another OSS driver author and maintainer, who ACK'd the move 
to ALSA...

In Linux we typically do not do two APIs and codebases for the same 
purpose.  If we do, like sys_mmap and sys_mmap2, it's an older legacy 
interface that never changes, that we are moving people AWAY from, and a 
newer interface.

I see no reason to change from the path at which upstream has arrived: 
OSS is a legacy API that's frozen in time, and ALSA provides the new stuff.

If you have ALSA criticisms, the right thing to do is fix ALSA. 
Upstream OSS was a dead-end code duplication & maintenance nightmare.  I 
know.  I was doing some of that maintenance and driver writing.

	Jeff

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

[Lennart Sorensen]

On Sun, Jun 24, 2007 at 07:51:38PM +0200, Tomasz K?oczko wrote:
> 
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and GLPv2 
> for Linux:
> 
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
> 
> So this source without problems code can be integragrated in Linus tree 
> and after this Linux can provide much better soud supoport than 
> with current ALSA.
> 
> Any plans for doing this ?

In my experience OSS is a pile of crap compared to ALSA.  The only thing
it has ever had was support for sound chips that requried an NDA to get
the specs.

Keep alsa, but possibly add support to alsa for whichever devices are
missing support.

--
Len Sorensen

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 436 bytes --]

On Mon, 25 Jun 2007, Lennart Sorensen wrote:
[..]
> In my experience OSS is a pile of crap compared to ALSA.

Could you say something more detailed about this compare ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*

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

[Lennart Sorensen]

On Mon, Jun 25, 2007 at 05:48:21PM +0200, Tomasz K?oczko wrote:
> On Mon, 25 Jun 2007, Lennart Sorensen wrote:
> [..]
> >In my experience OSS is a pile of crap compared to ALSA.
> 
> Could you say something more detailed about this compare ?

Well the last time I bothered to look at OSS, it was still stuck at
supproting stereo only.  It believed that if a card supported SB
emulation, then adding support for that was good enough.  it also
thought supporting the GUS PnP through emulation of the original GUS
counted as support.  Essentially it was all about having a long list of
supported chips, where support simply meant it could make some sounds,
and if you were lucky it might even do stereo.  At the time ALSA was
already far beyond that in supporting all the inputs and outputs of many
cards, supporting their true native capabilities, rather than some
mediocre emulation mode.  The fact ALSA was open source sure didn't hurt
either.

OSS being willing to sign NDAs also didn't help the rest of the linux
community in any way when it came to trying to get hardware makers to
release specs so drivers could actually be written for inclusion in the
kernel.

--
Len Sorensen

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

[Darren]

Tomasz Kłoczko wrote:
>
> Few dayas ago OSS source code was oppened uder CDDL for Solaris and 
> GLPv2 for Linux:
>
> http://www.opensound.com/press/2007/oss-gpl-cddl.txt
>
> So this source without problems code can be integragrated in Linus 
> tree and after this Linux can provide much better soud supoport than 
> with current ALSA.
>
> Any plans for doing this ?
>
> kloczek

I know this may sound kind of stupid, but how about not deprecating 
either, and fully supporting both sound systems? Maybe we can get them 
to work together, and the distro or user can choose whether they would 
like to use alsa or oss for that particular card (or have the distro 
choose the sound drivers that are best supported for that particular 
card). As it is now, most apps already support oss and alsa.

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

[Adrian Bunk]

On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>
> I know this may sound kind of stupid, but how about not deprecating either, 
> and fully supporting both sound systems? Maybe we can get them to work 
> together, and the distro or user can choose whether they would like to use 
> alsa or oss for that particular card (or have the distro choose the sound 
> drivers that are best supported for that particular card). As it is now, 
> most apps already support oss and alsa.

It does not sound stupid and sounds good at first sight.

But there are problems we've already seen with similar situations in 
different parts of the kernel:

They would have different hardware support, features and bugs.

And then a user user whose sound card is only supported by sound system A
needs a feature only available in sound system B.

And the quality decreases since people will often not report bugs in 
sound system A if sound system B works for them.

OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's 
mostly a difference for application developers. And since (as you say) 
most applications already support both, there's no compelling reason for 
providing more than one of them.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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

[Tomasz Kłoczko]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2599 bytes --]

On Wed, 4 Jul 2007, Adrian Bunk wrote:

> On Wed, Jul 04, 2007 at 02:35:39AM -0400, Darren wrote:
>>
>> I know this may sound kind of stupid, but how about not deprecating either,
>> and fully supporting both sound systems? Maybe we can get them to work
>> together, and the distro or user can choose whether they would like to use
>> alsa or oss for that particular card (or have the distro choose the sound
>> drivers that are best supported for that particular card). As it is now,
>> most apps already support oss and alsa.
>
> It does not sound stupid and sounds good at first sight.
>
> But there are problems we've already seen with similar situations in
> different parts of the kernel:
>
> They would have different hardware support, features and bugs.
>
> And then a user user whose sound card is only supported by sound system A
> needs a feature only available in sound system B.
>
> And the quality decreases since people will often not report bugs in
> sound system A if sound system B works for them.
>
> OTOH, for a user it shouldn't matter whether there's OSS or ALSA, that's
> mostly a difference for application developers. And since (as you say)
> most applications already support both, there's no compelling reason for
> providing more than one of them.

>From Hannu message:
"I think the ideal solution would be that both ALSA and OSS APIs can 
co-exist by sharing the same low level drivers (which has
already been demonstrated). The low level driver interfaces in both 
systems are practically identical. This means that ALSA's
core can work with OSS' drivers and vice versa."

So Hannu have plan for share ALSA low level drivers without changes 
(porting to OSS will not be neccessary and/or will need only small 
amount of time .. IMO much less than make ALSA fully functional).
Main diffrences between ALSA and OSS are above low level drivers so IMO it 
is completly possible have ALSA and OSS in the same tree.
OSS wtil not dies (and try resurect) ALSA still (after few years) was not 
born and still isn't rock solid point odf Linux desktop (IMO it is most 
weeknes ponit of LD). IMO it will be better if Hannu will start pushing 
any OSS chages to Linus tree. Current OSS code in Linus tree is more or 
less not useable so allow maintain this code in main tree can't hurd 
anything outside this area.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*