headers
Andi Kleen | 3 Jan 14:21
Picon
Favicon

Re: [2.6 patch] schedule obsolete OSS drivers for removal

Adrian Bunk <bunk <at> stusta.de> writes:
> 
>  Documentation/feature-removal-schedule.txt |    7 +
>  sound/oss/Kconfig                          |   79 ++++++++++++---------
>  2 files changed, 54 insertions(+), 32 deletions(-)
> 
> --- linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt.old	2005-07-26
16:50:05.000000000 +0200
> +++ linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt	2005-07-26
16:51:24.000000000 +0200
> @@ -44,0 +45,7 @@
> +What:	drivers depending on OBSOLETE_OSS_DRIVER
> +When:	October 2005
> +Why:	OSS drivers with ALSA replacements
> +Who:	Adrian Bunk <bunk <at> stusta.de>

I object to the ICH driver being scheduler for removal. It works
fine and is a significantly less bloated than the equivalent ALSA setup.

This means ac97_codec.c also has to stay.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Alistair John Strachan | 3 Jan 14:47
Picon
Picon

Re: [2.6 patch] schedule obsolete OSS drivers for removal

On Tuesday 03 January 2006 13:21, Andi Kleen wrote:
> Adrian Bunk <bunk <at> stusta.de> writes:
> >  Documentation/feature-removal-schedule.txt |    7 +
> >  sound/oss/Kconfig                          |   79 ++++++++++++---------
> >  2 files changed, 54 insertions(+), 32 deletions(-)
> >
> > ---
> > linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt.old	
> >2005-07-26 16:50:05.000000000 +0200 +++
> > linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt	2005
> >-07-26 16:51:24.000000000 +0200 @@ -44,0 +45,7 @@
> > +What:	drivers depending on OBSOLETE_OSS_DRIVER
> > +When:	October 2005
> > +Why:	OSS drivers with ALSA replacements
> > +Who:	Adrian Bunk <bunk <at> stusta.de>
>
> I object to the ICH driver being scheduler for removal. It works
> fine and is a significantly less bloated than the equivalent ALSA setup.
>
> This means ac97_codec.c also has to stay.

I think this is probably true for quite a few of the OSS drivers, versus their 
ALSA equivalents. The fact is that OSS is obsolete, and the ALSA libraries 
and utilities provide, to all soundcards, more features than the OSS API 
could.

Maybe it's more bloated, but it's about time applications on Linux didn't have 
to support 2-3 audio APIs just so they'd work on more than 50% of systems.

It strikes me that it's a bit of a chicken and egg problem. Vendors are still
(Continue reading)

Permalink | Reply | 2 comments |
headers
Andi Kleen | 3 Jan 14:52
Picon
Favicon

Re: [2.6 patch] schedule obsolete OSS drivers for removal

On Tuesday 03 January 2006 14:47, Alistair John Strachan wrote:

> It strikes me that it's a bit of a chicken and egg problem. Vendors are still 
> releasing applications on Linux that support only OSS, partly due to 
> ignorance, but mostly because ALSA's OSS compatibility layer allows them to 
> lazily ignore the ALSA API and target all cards, old and new.

As long as it works why is that a bad thing? OSS API works just fine
for most sound needs. If you want to do high end sound you can still
use ALSA.

> Additionally, we can't get rid of OSS compatibility until pretty much all 
> hardware has an ALSA driver, and (inferred from your comment) we can't get 
> rid of OSS drivers until nothing supports OSS, because the whole of the ALSA 
> stuff is a bit larger...

We can never get rid of it.
Linux doesn't break widely used application interfaces.

> Even if Adrian's not trying to make this point (he's just removing duplicate 
> drivers, and opting for the newer ones), we accepted ALSA into the kernel. 
> It's probably about time we let OSS die properly, for sanity purposes.

Avoiding bloat is more important.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alistair John Strachan | 3 Jan 15:01
Picon
Picon

Re: [2.6 patch] schedule obsolete OSS drivers for removal

On Tuesday 03 January 2006 13:52, Andi Kleen wrote:
> On Tuesday 03 January 2006 14:47, Alistair John Strachan wrote:
> > It strikes me that it's a bit of a chicken and egg problem. Vendors are
> > still releasing applications on Linux that support only OSS, partly due
> > to ignorance, but mostly because ALSA's OSS compatibility layer allows
> > them to lazily ignore the ALSA API and target all cards, old and new.
>
> As long as it works why is that a bad thing? OSS API works just fine
> for most sound needs. If you want to do high end sound you can still
> use ALSA.

Is multiple-source mixing really a "high end" requirement? When I last 
checked, the OSS driver didn't support multiple applications claiming it at 
once, thus requiring you to use "more bloat" like esound, arts, or some other 
crap to access your soundcard more than once at any given time.

I think when you consider other modern sound architectures across many 
operating systems have supported this fundamentally basic feature for a long 
time, it's important to the majority of end users.

> > Additionally, we can't get rid of OSS compatibility until pretty much all
> > hardware has an ALSA driver, and (inferred from your comment) we can't
> > get rid of OSS drivers until nothing supports OSS, because the whole of
> > the ALSA stuff is a bit larger...
>
> We can never get rid of it.
> Linux doesn't break widely used application interfaces.

Okay, fair point.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Lang | 3 Jan 14:58
Favicon

Re: [2.6 patch] schedule obsolete OSS drivers for removal

On Tue, 3 Jan 2006, Andi Kleen wrote:

>> Even if Adrian's not trying to make this point (he's just removing duplicate
>> drivers, and opting for the newer ones), we accepted ALSA into the kernel.
>> It's probably about time we let OSS die properly, for sanity purposes.
>
> Avoiding bloat is more important.

given that the ALSA drivers are not going to be removed, isn't it bloat to 
have two drivers for the same card?

yes, an individual compiled kernel may be slightly smaller by continueing 
to support the OSS driver, but the source (and the maintinance) are 
significantly worse by haveing two drivers instead of just one.

David Lang

--

-- 
There are two ways of constructing a software design. One way is to make it so simple that there are obviously
no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
  -- C.A.R. Hoare

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Alistair John Strachan | 3 Jan 15:33
Picon
Picon

Re: [2.6 patch] schedule obsolete OSS drivers for removal

On Tuesday 03 January 2006 13:58, David Lang wrote:
> On Tue, 3 Jan 2006, Andi Kleen wrote:
> >> Even if Adrian's not trying to make this point (he's just removing
> >> duplicate drivers, and opting for the newer ones), we accepted ALSA into
> >> the kernel. It's probably about time we let OSS die properly, for sanity
> >> purposes.
> >
> > Avoiding bloat is more important.
>
> given that the ALSA drivers are not going to be removed, isn't it bloat to
> have two drivers for the same card?

Normally this isn't too big a deal in Linux; eventually one gets removed, but 
not until it is substantially inferior than the other (or broken, or not 
compiling, or unmaintained..).

> yes, an individual compiled kernel may be slightly smaller by continueing
> to support the OSS driver, but the source (and the maintinance) are
> significantly worse by haveing two drivers instead of just one.

If there are two separate maintainers it's probably not a lot worse. I think 
the argument pretty much has to remain "ALSA drivers are technically 
superior, OSS drivers have unfixable limitations", and that should be a good 
enough reason to see them removed.

Perhaps Andi's concerns about ALSA bloat could also be concerned. I don't know 
enough about the "high end" features of ALSA to comment on whether they could 
become optional (currently there are few driver-generic options in the 
Kconfig file).
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alistair John Strachan | 3 Jan 15:34
Picon
Picon

Re: [2.6 patch] schedule obsolete OSS drivers for removal

On Tuesday 03 January 2006 14:33, Alistair John Strachan wrote:
> On Tuesday 03 January 2006 13:58, David Lang wrote:
> > On Tue, 3 Jan 2006, Andi Kleen wrote:
> > >> Even if Adrian's not trying to make this point (he's just removing
> > >> duplicate drivers, and opting for the newer ones), we accepted ALSA
> > >> into the kernel. It's probably about time we let OSS die properly, for
> > >> sanity purposes.
> > >
> > > Avoiding bloat is more important.
> >
> > given that the ALSA drivers are not going to be removed, isn't it bloat
> > to have two drivers for the same card?
>
> Normally this isn't too big a deal in Linux; eventually one gets removed,
> but not until it is substantially inferior than the other (or broken, or
> not compiling, or unmaintained..).
>
> > yes, an individual compiled kernel may be slightly smaller by continueing
> > to support the OSS driver, but the source (and the maintinance) are
> > significantly worse by haveing two drivers instead of just one.
>
> If there are two separate maintainers it's probably not a lot worse. I
> think the argument pretty much has to remain "ALSA drivers are technically
> superior, OSS drivers have unfixable limitations", and that should be a
> good enough reason to see them removed.
>
> Perhaps Andi's concerns about ALSA bloat could also be concerned. 
							 ^^^ addressed

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jan Engelhardt | 3 Jan 15:38
Picon

Re: [2.6 patch] schedule obsolete OSS drivers for removal


>It strikes me that it's a bit of a chicken and egg problem. Vendors are still 
>releasing applications on Linux that support only OSS, partly due to 
>ignorance, but mostly because ALSA's OSS compatibility layer allows them to 
>lazily ignore the ALSA API and target all cards, old and new.
>
>Additionally, we can't get rid of OSS compatibility until pretty much all 
>hardware has an ALSA driver, and (inferred from your comment) we can't get 
>rid of OSS drivers until nothing supports OSS, because the whole of the ALSA 
>stuff is a bit larger...
>
By OSS compatibility, do you mean the OSS PCM emulation layer (/dev/dsp)? I
think that should be kept. That way, legacy apps keep working, especially
unmaintained binary-only things like Unreal Tournament 1.

The OSS emulation does not depend on the OSS tree (CONFIG_SOUND_PRIME), so I
cannot quite follow your second paragraph - we should not remove OSS compat.
anytime.

Jan Engelhardt
--

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Alistair John Strachan | 3 Jan 15:41
Picon
Picon

Re: [2.6 patch] schedule obsolete OSS drivers for removal

On Tuesday 03 January 2006 14:38, Jan Engelhardt wrote:
> >It strikes me that it's a bit of a chicken and egg problem. Vendors are
> > still releasing applications on Linux that support only OSS, partly due
> > to ignorance, but mostly because ALSA's OSS compatibility layer allows
> > them to lazily ignore the ALSA API and target all cards, old and new.
> >
> >Additionally, we can't get rid of OSS compatibility until pretty much all
> >hardware has an ALSA driver, and (inferred from your comment) we can't get
> >rid of OSS drivers until nothing supports OSS, because the whole of the
> > ALSA stuff is a bit larger...
>
> By OSS compatibility, do you mean the OSS PCM emulation layer (/dev/dsp)? I
> think that should be kept. That way, legacy apps keep working, especially
> unmaintained binary-only things like Unreal Tournament 1.
>
> The OSS emulation does not depend on the OSS tree (CONFIG_SOUND_PRIME), so
> I cannot quite follow your second paragraph - we should not remove OSS
> compat. anytime.

Andi made this point and I agree. I'm just making the point that people should 
see it as exactly that -- a legacy compatibility layer. It should not be seen 
as a "way out" for vendors looking to write generic DSP software.

The problem with using OSS compatibility, at least on this machine with ALSA 
1.0.9, is that if you use it you automatically lose the software mixing 
capabilities of ALSA, so it really is less than ideal.

--

-- 
Cheers,
Alistair.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jan Engelhardt | 3 Jan 15:50
Picon

Re: [2.6 patch] schedule obsolete OSS drivers for removal


>The problem with using OSS compatibility, at least on this machine with ALSA 
>1.0.9, is that if you use it you automatically lose the software mixing 
>capabilities of ALSA, so it really is less than ideal.
>

Well, I am able to open /dev/dsp multiple times here without problems.
(Is /dev/dsp soft- or hardmixing?)

Jan Engelhardt
--

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |

Gmane