Development of Linux for the HP PA-RISC platform

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)

headers

Jan Engelhardt | 3 Jan 15:38

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

headers

Alistair John Strachan | 3 Jan 15:41

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)

headers

Jan Engelhardt | 3 Jan 15:50

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

headers

Alistair John Strachan | 3 Jan 16:22

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

On Tuesday 03 January 2006 14:50, Jan Engelhardt wrote:
> >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?)

As far as I'm aware, it depends on your hardware. For example, software mixing 
kicks in with zero configuration on most hardware that won't mix in hardware, 
e.g. my laptop's i810 audio.

[alistair] 15:18 [~] cat /proc/asound/cards
0 [I82801DBICH4   ]: ICH4 - Intel 82801DB-ICH4
                     Intel 82801DB-ICH4 with AD1981B at 0xa0100000, irq 11
1 [Modem          ]: ICH-MODEM - Intel 82801DB-ICH4 Modem
                     Intel 82801DB-ICH4 Modem at 0x3400, irq 11

I can successfully hear two mixed sources when I execute the following:

ogg123 -q --device=alsa09 01\ -\ Good\ Times\ Bad\ Times.ogg

And on another terminal

ogg123 -q --device=alsa09 01\ -\ Good\ Times\ Bad\ Times.og

This is ALSA soft mixing the two sources for me. Very nifty. However, if I 
throw an OSS into the mix (whilst these other two are playing).

[alistair] 15:20 [~/Music/Led Zeppelin - I] ogg123 -q --device=oss 01\ -\

(Continue reading)

headers

Jan Engelhardt | 3 Jan 18:09

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

>> Well, I am able to open /dev/dsp multiple times here without problems.
>> (Is /dev/dsp soft- or hardmixing?)
>
>As far as I'm aware, it depends on your hardware. For example, software mixing 
>kicks in with zero configuration on most hardware that won't mix in hardware, 
>e.g. my laptop's i810 audio.
>
>ogg123 -q --device=oss 01\ -\ Good\ Times\ Bad\ Times.ogg
>
>Works, but then:
>
>ogg123 -q --device=oss 01\ -\ Good\ Times\ Bad\ Times.ogg
>Error: Cannot open device oss

Oh well this does work for me.

>This is all a little OT for this thread, but it's certainly the case with 
>alsa-lib-1.0.10 on 2.6.15-rc7. My card isn't capable of hardware mixing, 
>yours might be (SBLive!/Audigy or something).

CS46XX. According to alsamixer info, it has 31 playback and 1 record channel.
Looks like I'm in favor of hardware mixing.

But hey, you have not lost anything using the OSS emulation. With OSS, I could
not even have hardware mixing on cs46xx!

Jan Engelhardt
--

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in

(Continue reading)

headers

Tomasz Torcz | 3 Jan 17:05

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

On Tue, Jan 03, 2006 at 03:22:06PM +0000, Alistair John Strachan wrote:
> On Tuesday 03 January 2006 14:50, Jan Engelhardt wrote:
> > >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?)
> 
> As far as I'm aware, it depends on your hardware. For example, software mixing 
> kicks in with zero configuration on most hardware that won't mix in hardware, 
> e.g. my laptop's i810 audio.
> 
> [alistair] 15:18 [~] cat /proc/asound/cards
> 0 [I82801DBICH4   ]: ICH4 - Intel 82801DB-ICH4
>                      Intel 82801DB-ICH4 with AD1981B at 0xa0100000, irq 11
> 1 [Modem          ]: ICH-MODEM - Intel 82801DB-ICH4 Modem
>                      Intel 82801DB-ICH4 Modem at 0x3400, irq 11
> 
> I can successfully hear two mixed sources when I execute the following:
> 
> ogg123 -q --device=alsa09 01\ -\ Good\ Times\ Bad\ Times.ogg
> 
> And on another terminal
> 
> ogg123 -q --device=alsa09 01\ -\ Good\ Times\ Bad\ Times.og
> 
> This is ALSA soft mixing the two sources for me. Very nifty. However, if I 
> throw an OSS into the mix (whilst these other two are playing).
>

(Continue reading)

headers

Alistair John Strachan | 3 Jan 17:29

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

On Tuesday 03 January 2006 16:05, Tomasz Torcz wrote:
[snip]
> >
> > [alistair] 15:20 [~/Music/Led Zeppelin - I] ogg123 -q --device=oss 01\ -\
> > Good\ Times\ Bad\ Times.ogg
> > Error: Cannot open device oss.
>
>  Proper way (using userspace OSS emulation):
> aoss ogg123 -q --device=oss [...]

I'm aware of this.

This has nothing to do with the kernel option CONFIG_SND_OSSEMUL which Jan 
referred to, and to which I was responding. "aoss" is also not compatible 
with every conceivable program.

This is exactly why the OSS emulation option in ALSA is really a last resort 
and should not be an excuse for people to ignore implementing ALSA support 
directly. More so, it is very good justification for ditching "everything 
OSS" as soon as possible, at least in new software.

--

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in

(Continue reading)

headers

Olivier Galibert | 3 Jan 18:03

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

On Tue, Jan 03, 2006 at 04:29:21PM +0000, Alistair John Strachan wrote:
> This has nothing to do with the kernel option CONFIG_SND_OSSEMUL which Jan 
> referred to, and to which I was responding. "aoss" is also not compatible 
> with every conceivable program.

Especially not with plugins.  Flashplayer anybody?

> This is exactly why the OSS emulation option in ALSA is really a last resort 
> and should not be an excuse for people to ignore implementing ALSA support 
> directly. More so, it is very good justification for ditching "everything 
> OSS" as soon as possible, at least in new software.

Actually the crappy state of OSS emulation is a good reason to ditch
ALSA in its current implementation.  As Linus reminded not so long
ago, backwards compatibility is extremely important.

Also, not everybody wants to depend on a shared library.  I find this
"the alsa lib must be kept in lockstep with the kernel version" quite
annoying.  I'd rather not have the windows dll hell on linux, TYVM.
Or in other words, the public API of a kernel interface should _NEVER_
be a library only.  At least OSS, with all its issues, had that right.

  OG.

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

headers

Takashi Iwai | 3 Jan 21:22

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

At Tue, 3 Jan 2006 18:03:16 +0100,
Olivier Galibert wrote:
> 
> > This is exactly why the OSS emulation option in ALSA is really a last resort 
> > and should not be an excuse for people to ignore implementing ALSA support 
> > directly. More so, it is very good justification for ditching "everything 
> > OSS" as soon as possible, at least in new software.
> 
> Actually the crappy state of OSS emulation is a good reason to ditch
> ALSA in its current implementation.  As Linus reminded not so long
> ago, backwards compatibility is extremely important.

Well, we keep the compatibility exactly -- OSS drivers don't support
software mixing in the kernel, too :)

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

headers

Tomasz Torcz | 3 Jan 21:37

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

On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> At Tue, 3 Jan 2006 18:03:16 +0100,
> Olivier Galibert wrote:
> > 
> > > This is exactly why the OSS emulation option in ALSA is really a last resort 
> > > and should not be an excuse for people to ignore implementing ALSA support 
> > > directly. More so, it is very good justification for ditching "everything 
> > > OSS" as soon as possible, at least in new software.
> > 
> > Actually the crappy state of OSS emulation is a good reason to ditch
> > ALSA in its current implementation.  As Linus reminded not so long
> > ago, backwards compatibility is extremely important.
> 
> Well, we keep the compatibility exactly -- OSS drivers don't support
> software mixing in the kernel, too :)

 OSS will support software mixing. In kernel. On NetBSD.
http://kerneltrap.org/node/4388

--

-- 
Tomasz Torcz            There exists no separation between gods and men:
zdzichu <at> irc.-nie.spam-.pl   one blends softly casual into the other.

headers

Takashi Iwai | 3 Jan 21:44

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

At Tue, 3 Jan 2006 21:37:32 +0100,
Tomasz Torcz wrote:
> 
> On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> > At Tue, 3 Jan 2006 18:03:16 +0100,
> > Olivier Galibert wrote:
> > > 
> > > > This is exactly why the OSS emulation option in ALSA is really a last resort 
> > > > and should not be an excuse for people to ignore implementing ALSA support 
> > > > directly. More so, it is very good justification for ditching "everything 
> > > > OSS" as soon as possible, at least in new software.
> > > 
> > > Actually the crappy state of OSS emulation is a good reason to ditch
> > > ALSA in its current implementation.  As Linus reminded not so long
> > > ago, backwards compatibility is extremely important.
> > 
> > Well, we keep the compatibility exactly -- OSS drivers don't support
> > software mixing in the kernel, too :)
> 
>  OSS will support software mixing. In kernel. On NetBSD.
> http://kerneltrap.org/node/4388

Why do we need to keep the compatibility with NetBSD?

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

headers

Jesper Juhl | 3 Jan 21:56

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

On 1/3/06, Takashi Iwai <tiwai <at> suse.de> wrote:
> At Tue, 3 Jan 2006 21:37:32 +0100,
> Tomasz Torcz wrote:
> >
> > On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> > > At Tue, 3 Jan 2006 18:03:16 +0100,
> > > Olivier Galibert wrote:
> > > >
> > > > > This is exactly why the OSS emulation option in ALSA is really a last resort
> > > > > and should not be an excuse for people to ignore implementing ALSA support
> > > > > directly. More so, it is very good justification for ditching "everything
> > > > > OSS" as soon as possible, at least in new software.
> > > >
> > > > Actually the crappy state of OSS emulation is a good reason to ditch
> > > > ALSA in its current implementation.  As Linus reminded not so long
> > > > ago, backwards compatibility is extremely important.
> > >
> > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > software mixing in the kernel, too :)
> >
> >  OSS will support software mixing. In kernel. On NetBSD.
> > http://kerneltrap.org/node/4388
>
> Why do we need to keep the compatibility with NetBSD?
>
Software mixing is a really nice feature for people with soundscards
that can't do hardware mixing, so if the OSS compatibility could
transparently do software mixing for apps using OSS api that would be
a very nice extension for a lot of people - I'd say that if NetBSD do
that they've got the right idea.

(Continue reading)

headers

Adrian Bunk | 3 Jan 22:56

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

On Tue, Jan 03, 2006 at 09:56:20PM +0100, Jesper Juhl wrote:
> On 1/3/06, Takashi Iwai <tiwai <at> suse.de> wrote:
> > At Tue, 3 Jan 2006 21:37:32 +0100,
> > Tomasz Torcz wrote:
> > >
> > > On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> > > > At Tue, 3 Jan 2006 18:03:16 +0100,
> > > > Olivier Galibert wrote:
> > > > >
> > > > > > This is exactly why the OSS emulation option in ALSA is really a last resort
> > > > > > and should not be an excuse for people to ignore implementing ALSA support
> > > > > > directly. More so, it is very good justification for ditching "everything
> > > > > > OSS" as soon as possible, at least in new software.
> > > > >
> > > > > Actually the crappy state of OSS emulation is a good reason to ditch
> > > > > ALSA in its current implementation.  As Linus reminded not so long
> > > > > ago, backwards compatibility is extremely important.
> > > >
> > > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > > software mixing in the kernel, too :)
> > >
> > >  OSS will support software mixing. In kernel. On NetBSD.
> > > http://kerneltrap.org/node/4388
> >
> > Why do we need to keep the compatibility with NetBSD?
> >
> Software mixing is a really nice feature for people with soundscards
> that can't do hardware mixing, so if the OSS compatibility could
> transparently do software mixing for apps using OSS api that would be
> a very nice extension for a lot of people - I'd say that if NetBSD do

(Continue reading)

headers

Tomasz Torcz | 3 Jan 23:13

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

On Tue, Jan 03, 2006 at 10:56:54PM +0100, Adrian Bunk wrote:
> > > > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > > > software mixing in the kernel, too :)
> > > >
> > > >  OSS will support software mixing. In kernel. On NetBSD.
> > > > http://kerneltrap.org/node/4388
> > >
> > > Why do we need to keep the compatibility with NetBSD?
> > >
> > Software mixing is a really nice feature for people with soundscards
> > that can't do hardware mixing, so if the OSS compatibility could
> > transparently do software mixing for apps using OSS api that would be
> > a very nice extension for a lot of people - I'd say that if NetBSD do
> > that they've got the right idea.
> 
> The OSS compatibility in ALSA is only a legacy API for applications not 
> yet converted to use the ALSA API.

  OSS is universal cross-unix API. ALSA is Linux-only.

--

-- 
Tomasz Torcz            There exists no separation between gods and men:
zdzichu <at> irc.-nie.spam-.pl   one blends softly casual into the other.

headers

Adrian Bunk | 4 Jan 00:10

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

On Tue, Jan 03, 2006 at 11:13:14PM +0100, Tomasz Torcz wrote:
> On Tue, Jan 03, 2006 at 10:56:54PM +0100, Adrian Bunk wrote:
> > > > > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > > > > software mixing in the kernel, too :)
> > > > >
> > > > >  OSS will support software mixing. In kernel. On NetBSD.
> > > > > http://kerneltrap.org/node/4388
> > > >
> > > > Why do we need to keep the compatibility with NetBSD?
> > > >
> > > Software mixing is a really nice feature for people with soundscards
> > > that can't do hardware mixing, so if the OSS compatibility could
> > > transparently do software mixing for apps using OSS api that would be
> > > a very nice extension for a lot of people - I'd say that if NetBSD do
> > > that they've got the right idea.
> > 
> > The OSS compatibility in ALSA is only a legacy API for applications not 
> > yet converted to use the ALSA API.
> 
>   OSS is universal cross-unix API. ALSA is Linux-only.

How "universal cross-unix" is the OSS API really?

Which operating systems besides Linux have a native sound system 
supporting the OSS API [1]?

I know about FreeBSD and partial support in NetBSD.

Are there any other [2]?

(Continue reading)

headers

Tomasz Kłoczko | 4 Jan 00:51

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

On Wed, 4 Jan 2006, Adrian Bunk wrote:
[..]
>>   OSS is universal cross-unix API. ALSA is Linux-only.
>
> How "universal cross-unix" is the OSS API really?
>
> Which operating systems besides Linux have a native sound system
> supporting the OSS API [1]?
>
> I know about FreeBSD and partial support in NetBSD.
>
> Are there any other [2]?

Solaris, AIX ..
Full list is avalaible in "Operating System" listbox on 
http://www.4front-tech.com/download.cgi

kloczek
--

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

headers

Stefan Smietanowski | 4 Jan 01:28

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

Tomasz Kłoczko wrote:
> On Wed, 4 Jan 2006, Adrian Bunk wrote:
> [..]
> 
>>>   OSS is universal cross-unix API. ALSA is Linux-only.
>>
>>
>> How "universal cross-unix" is the OSS API really?
>>
>> Which operating systems besides Linux have a native sound system
>> supporting the OSS API [1]?
>>
>> I know about FreeBSD and partial support in NetBSD.
>>
>> Are there any other [2]?
> 
> 
> Solaris, AIX ..
> Full list is avalaible in "Operating System" listbox on
> http://www.4front-tech.com/download.cgi

Are all those Operatings Systems that include OSS per default, no
additional download required? Because that's what he's asking for,
not what you can get OSS for.

Since that link is a _download page_ it makes me think that it's
an _additional download_ to get OSS support on those (or some of
those) operating systems.

// Stefan

(Continue reading)

headers

Tomasz Kłoczko | 4 Jan 02:38

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

On Wed, 4 Jan 2006, Stefan Smietanowski wrote:
[..]
>> Solaris, AIX ..
>> Full list is avalaible in "Operating System" listbox on
>> http://www.4front-tech.com/download.cgi
>
> Are all those Operatings Systems that include OSS per default, no
> additional download required? Because that's what he's asking for,
> not what you can get OSS for.
>
> Since that link is a _download page_ it makes me think that it's
> an _additional download_ to get OSS support on those (or some of
> those) operating systems.

So start another "it makes me think" and imagine that in Solaris case 
using drivers not provided directly on distribution level is NORMAL habit. 
Why ? Bacause Solaris have well defined kernel API (from many years in 
some common areas it is constants which makes 
Documentation/stable_api_nonsense.txt from Linux tree piece of crap). This 
allow use device drivers prepared first for example for older kernels 
(8,9) on latest (10). I.e.: Solaris 10 inroduces stop supporting some 
older network cards (IIRC for old SMC cards). I know people which still 
uses this cards on Sol10 by using binary drivers prepared for older 
Solarises without visable problems. Also many device drivers have double 
versions (one from distribution resouurces and second provided by device 
vendor).

Summarize: stop looking on sound subsystem problems as Linux specyfic and 
assume that THE SAME problems exists on other unices in so simillar form
so is possible thinking on OSS support on kernel level details in the

(Continue reading)

headers

Stefan Smietanowski | 4 Jan 10:48

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

Tomasz Kłoczko wrote:
> On Wed, 4 Jan 2006, Stefan Smietanowski wrote:
> [..]
> 
>>> Solaris, AIX ..
>>> Full list is avalaible in "Operating System" listbox on
>>> http://www.4front-tech.com/download.cgi
>>
>>
>> Are all those Operatings Systems that include OSS per default, no
>> additional download required? Because that's what he's asking for,
>> not what you can get OSS for.
>>
>> Since that link is a _download page_ it makes me think that it's
>> an _additional download_ to get OSS support on those (or some of
>> those) operating systems.
> 
> 
> So start another "it makes me think" and imagine that in Solaris case
> using drivers not provided directly on distribution level is NORMAL
> habit. Why ? Bacause Solaris have well defined kernel API (from many
> years in some common areas it is constants which makes
> Documentation/stable_api_nonsense.txt from Linux tree piece of crap).
> This allow use device drivers prepared first for example for older
> kernels (8,9) on latest (10). I.e.: Solaris 10 inroduces stop supporting
> some older network cards (IIRC for old SMC cards). I know people which
> still uses this cards on Sol10 by using binary drivers prepared for
> older Solarises without visable problems. Also many device drivers have
> double versions (one from distribution resouurces and second provided by
> device vendor).

(Continue reading)

headers

Peter Bortas | 5 Jan 04:03

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

On 1/4/06, Stefan Smietanowski <stesmi <at> stesmi.com> wrote:

> So if I buy $COMMERCIAL_PROGRAM for say Solaris, AIX or anything else
> it REQUIRES me to download (before: buy) $COMMERCIAL_SOUNDSYSTEM?
>
> "In order to use this program you need to have OSS installed."
>
> That sounds insane to say the least.
>
> // Stefan

No. Everything on Solaris uses the Solaris native sound API except for
possibly quick-hack ports of applications from Linux. Doing anything
else would as you say be insane and break things like device
redirection on Sunrays.

--
Peter Bortas

headers

Jan Engelhardt | 5 Jan 08:13

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


>No. Everything on Solaris uses the Solaris native sound API except for
>possibly quick-hack ports of applications from Linux. Doing anything
>else would as you say be insane and break things like device
>redirection on Sunrays.
>
Device redirection is just "writing to a different /dev node" - on
Solaris and Linux. IIRC, the API is the same.

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

headers

Peter Bortas | 5 Jan 10:57

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

On 1/5/06, Jan Engelhardt <jengelh <at> linux01.gwdg.de> wrote:
>
> >No. Everything on Solaris uses the Solaris native sound API except for
> >possibly quick-hack ports of applications from Linux. Doing anything
> >else would as you say be insane and break things like device
> >redirection on Sunrays.
> >
> Device redirection is just "writing to a different /dev node" - on
> Solaris and Linux. IIRC, the API is the same.

Correct. Rederection to $AUDIODEVICE that is a normal /dev/audio.
-
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

headers

Lee Revell | 5 Jan 08:19

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

On Thu, 2006-01-05 at 08:13 +0100, Jan Engelhardt wrote:
> >No. Everything on Solaris uses the Solaris native sound API except for
> >possibly quick-hack ports of applications from Linux. Doing anything
> >else would as you say be insane and break things like device
> >redirection on Sunrays.
> >
> Device redirection is just "writing to a different /dev node" - on
> Solaris and Linux. IIRC, the API is the same.

This whole "OSS is cross platform" thing seems mostly like a cop out by
lazy developers who can't be bothered to grok ALSA.  None of the usual
offenders (Skype, Quake 3, Doom 3) run on any other Unix platform so why
not just use ALSA?

It does not help that the most problematic apps seem to be proprietary
(most likely they are abusing the OSS API in a way that no one
anticipated).

Lee

-
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

headers

Stefan Smietanowski | 5 Jan 09:41

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

Hi.

>>>No. Everything on Solaris uses the Solaris native sound API except for
>>>possibly quick-hack ports of applications from Linux. Doing anything
>>>else would as you say be insane and break things like device
>>>redirection on Sunrays.
>>>
>>
>>Device redirection is just "writing to a different /dev node" - on
>>Solaris and Linux. IIRC, the API is the same.
> 
> This whole "OSS is cross platform" thing seems mostly like a cop out by
> lazy developers who can't be bothered to grok ALSA.  None of the usual
> offenders (Skype, Quake 3, Doom 3) run on any other Unix platform so why
> not just use ALSA?
> 
> It does not help that the most problematic apps seem to be proprietary
> (most likely they are abusing the OSS API in a way that no one
> anticipated).

What's actually funny (well actually it's not) is that Doom3 for
instance works great using the OSS emul of ALSA but not using
native ALSA for some reason. I haven't reported it cause it's
a commercial program without source.

( The sound stutters all the time, and not just when moving, etc, but
all the time )

// Stefan

(Continue reading)

headers

Adrian Bunk | 4 Jan 01:03

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

On Wed, Jan 04, 2006 at 12:51:52AM +0100, Tomasz K?oczko wrote:
> On Wed, 4 Jan 2006, Adrian Bunk wrote:
> [..]
> >>  OSS is universal cross-unix API. ALSA is Linux-only.
> >
> >How "universal cross-unix" is the OSS API really?
> >
> >Which operating systems besides Linux have a native sound system
> >supporting the OSS API [1]?
> >
> >I know about FreeBSD and partial support in NetBSD.
> >
> >Are there any other [2]?
> 
> Solaris, AIX ..
> Full list is avalaible in "Operating System" listbox on 
> http://www.4front-tech.com/download.cgi

As I said in footnote 1 of my email, this has little value for 
application developers since only few users on these systems use this 
commercial sound system.

> kloczek

cu
Adrian

--

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out

(Continue reading)

headers

Tomasz Kłoczko | 4 Jan 01:46

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

On Wed, 4 Jan 2006, Adrian Bunk wrote:
[..]
>> Solaris, AIX ..
>> Full list is avalaible in "Operating System" listbox on
>> http://www.4front-tech.com/download.cgi
>
> As I said in footnote 1 of my email, this has little value for
> application developers since only few users on these systems use this
> commercial sound system.

You are wrong using pejorative labeling "commercial sound system" for 
this. Comercial is implementation. OSS is defined by user space API.
This is all what was neccessary on implemting this in for Linux.

OSS case on Linux is very simillar to Motiff case on X11.
As same as Motiff OSS have publically avalaible and open specyfication
avalaible on http://www.opensound.com/pguide/oss.pdf which do not touch 
kernel level implemntations details. Using this specyfication you can
collect all neccessary details for implemt handle /dev/* interface on
kernel side.

kloczek
--

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

headers

Adrian Bunk | 4 Jan 02:01

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

On Wed, Jan 04, 2006 at 01:46:08AM +0100, Tomasz K?oczko wrote:
> On Wed, 4 Jan 2006, Adrian Bunk wrote:
> [..]
> >>Solaris, AIX ..
> >>Full list is avalaible in "Operating System" listbox on
> >>http://www.4front-tech.com/download.cgi
> >
> >As I said in footnote 1 of my email, this has little value for
> >application developers since only few users on these systems use this
> >commercial sound system.
> 
> You are wrong using pejorative labeling "commercial sound system" for 
> this. Comercial is implementation. OSS is defined by user space API.
> This is all what was neccessary on implemting this in for Linux.

The question is simple:

How many percent of the Solaris or AIX users are actually using any 
sound system implementing the OSS API?

> OSS case on Linux is very simillar to Motiff case on X11.
> As same as Motiff OSS have publically avalaible and open specyfication
> avalaible on http://www.opensound.com/pguide/oss.pdf which do not touch 
> kernel level implemntations details. Using this specyfication you can
> collect all neccessary details for implemt handle /dev/* interface on
> kernel side.

There are many cross-platform audio libraries available that work on 
more systems than the systems implementing the OSS API (because they 
have backends for many different sound APIs including OSS), and many of

(Continue reading)

headers

Tomasz Kłoczko | 4 Jan 03:51

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

On Wed, 4 Jan 2006, Adrian Bunk wrote:

> On Wed, Jan 04, 2006 at 01:46:08AM +0100, Tomasz K?oczko wrote:
>> On Wed, 4 Jan 2006, Adrian Bunk wrote:
>> [..]
>>>> Solaris, AIX ..
>>>> Full list is avalaible in "Operating System" listbox on
>>>> http://www.4front-tech.com/download.cgi
>>>
>>> As I said in footnote 1 of my email, this has little value for
>>> application developers since only few users on these systems use this
>>> commercial sound system.
>>
>> You are wrong using pejorative labeling "commercial sound system" for
>> this. Comercial is implementation. OSS is defined by user space API.
>> This is all what was neccessary on implemting this in for Linux.
>
> The question is simple:
>
> How many percent of the Solaris or AIX users are actually using any
> sound system implementing the OSS API?

First try answer on: if OSS specyfications is complet, easy to use in 
applications and generaly compact why reinventing all from this level to 
above on Linux ? why ?
If you answer first on this question you will see: answer 
on your questions do not have sense.

Be compliant with OSS specyfication allow save many time on applications 
development level by consume (in good sense) time spend on this

(Continue reading)

headers

tapas | 4 Jan 11:37

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

On Wed, 4 Jan 2006 03:51:09 +0100 (CET)
Tomasz K³oczko <kloczek <at> rudy.mif.pg.gda.pl> wrote:

> After four years ALSA development quality of sound support in Linux is IMO 
> on the ~same (still bad) level as four years ago. Still to complicated 
> but now more bloated and additionaly not ready for handle fancy gadgets 
> like BT headsets.

Hi,

i want to chime in here in the defense of ALSA. ALSA is vastly superiour
for musicians using linux as opposed to a mere music consumer. Right,
for a music consumer (mp3s, cd's, etc), OSS was probably easier to setup
and use, but there's other advantages of ALSA vs. OSS:

- userspace software mixing (or better software mixing at all. OSS
doesn't have this (the libre version in the kernel, not the closed
source proprietary one)

- userspace resampling (i.e. you have crappy AC97 card that sounds like
shit when resampling automatically? Use the ALSA resampler. It might
sound like shit, too, but at least it can be fixed ;)

- the biggest benefit for me: MIDI routing in between any number of
applications.

- more capable (more complicated yeah but wtf :)) mixer implementation
(the thing to control the volumes, etc)

- way more flexible in handling more than one soundcard/device, etc..

(Continue reading)

headers

Lee Revell | 5 Jan 08:16

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

On Wed, 2006-01-04 at 11:37 +0100, tapas wrote:
> ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
> software mixing. As aoss cannot provide OSS emulation to all OSS apps

Why not?

> ,
> the kernel level OSS emu must be fixed. 

Wrong, if an app doesn't work with aoss it's a bug and we need to hear
about it.  I mentioned this previously in the thread and apparently no
one cares about it enough to file a useful bug report (we got one report
that the *kernel level* emulation didn't work which is a different
issue).

By far the most common bug report is "Skype does not work with aoss".
We would LOVE to see a reproducible test case using an *open source* app
(kiax might be a good place to start).

Lee

-
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

headers

Florian Schmidt | 5 Jan 12:43

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

On Thu, 05 Jan 2006 02:16:35 -0500
Lee Revell <rlrevell <at> joe-job.com> wrote:

> On Wed, 2006-01-04 at 11:37 +0100, tapas wrote:
> > ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
> > software mixing. As aoss cannot provide OSS emulation to all OSS apps
> 
> Why not?

I did write it out before. aoss is a LD_PRELOAD hack. Apps/libs that
resolve the system call symbols at build time cannot be made to use
these calls from a different lib (which is what LD_PRELOAD tries to do).
A famous example is libc for which a workaround was added (as libc
offers its own mechanism to intercept fopen() et al.). Others can lurk
in the background, too. It would even be trivial to write an app that
aoss will not work with - ever (unless the code be modified - which is
not an option for closed source apps).

It simply cannot ever work with _all_ apps (as opposed to kernel level
OSS emu  which can be made to work with _all_ apps (at least in
principle)).

Errm, i'm actually wrong about that. Kernel level OSS emu sw mixing
cannot work together with userspace ALSA sw mixing. I completely missed
that point.

I still think, the easiest way would be to use FUSE as it gives the best
of both worlds:

- device file access as opposed to LD_PRELOAD hack (which has principle

(Continue reading)

headers

Lee Revell | 5 Jan 19:36

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

On Thu, 2006-01-05 at 12:43 +0100, Florian Schmidt wrote:
> On Thu, 05 Jan 2006 02:16:35 -0500
> Lee Revell <rlrevell <at> joe-job.com> wrote:
> 
> > On Wed, 2006-01-04 at 11:37 +0100, tapas wrote:
> > > ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
> > > software mixing. As aoss cannot provide OSS emulation to all OSS apps
> > 
> > Why not?
> 
> I did write it out before. aoss is a LD_PRELOAD hack. Apps/libs that
> resolve the system call symbols at build time cannot be made to use
> these calls from a different lib (which is what LD_PRELOAD tries to do).
> A famous example is libc for which a workaround was added (as libc
> offers its own mechanism to intercept fopen() et al.). Others can lurk
> in the background, too. It would even be trivial to write an app that
> aoss will not work with - ever (unless the code be modified - which is
> not an option for closed source apps).
> 
> It simply cannot ever work with _all_ apps (as opposed to kernel level
> OSS emu  which can be made to work with _all_ apps (at least in
> principle)).
> 

OK so you can contrive an example.  Have we ever seen a real world app
where aoss can't work?

> Errm, i'm actually wrong about that. Kernel level OSS emu sw mixing
> cannot work together with userspace ALSA sw mixing. I completely missed
> that point.

(Continue reading)

headers

Florian Schmidt | 5 Jan 20:15

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

On Thu, 05 Jan 2006 13:36:20 -0500
Lee Revell <rlrevell <at> joe-job.com> wrote:

> OK so you can contrive an example.  Have we ever seen a real world app
> where aoss can't work?

Well, until i provided my hacky and probably buggy patch to aoss to use
libc's fopen()-et. al.-hooks, no app using the OSS api by way of libc's
fopen() et. al. was able to use aoss.  I don't use aoss anymore, as i
have hw mixing, so i haven't really done anymore testing. I admit of not
being sure, whether this principle error has any realistic impact (i.e.
apps/libs exist that resolve their system call symbols at build time - i
must also admit that i don't have really complete understanding of this
issue. maybe a more knowledgable person can speak up about possible use
scenarios besides libc). 

> > Errm, i'm actually wrong about that. Kernel level OSS emu sw mixing
> > cannot work together with userspace ALSA sw mixing. I completely missed
> > that point.
> > 
> > I still think, the easiest way would be to use FUSE as it gives the best
> > of both worlds:
> 
> Yep, this does sound like a promising approach.  AFAIK it's never been
> seriously explored as FUSE is so new.

Plus, i was wrong :) FUSE is for filesystems. fusd would be the choice
for this (not included in kernel yet). One might see how far one gets
with reusing code from both aoss and oss2jack

(Continue reading)

headers

Tomasz Torcz | 5 Jan 19:47

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

On Thu, Jan 05, 2006 at 01:36:20PM -0500, Lee Revell wrote:
> On Thu, 2006-01-05 at 12:43 +0100, Florian Schmidt wrote:
> > On Thu, 05 Jan 2006 02:16:35 -0500
> > Lee Revell <rlrevell <at> joe-job.com> wrote:
> > 
> > > On Wed, 2006-01-04 at 11:37 +0100, tapas wrote:
> > > > ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
> > > > software mixing. As aoss cannot provide OSS emulation to all OSS apps
> > > 
> > > Why not?
> > 
> > I did write it out before. aoss is a LD_PRELOAD hack. Apps/libs that
> > resolve the system call symbols at build time cannot be made to use
> > these calls from a different lib (which is what LD_PRELOAD tries to do).
> > A famous example is libc for which a workaround was added (as libc
> > offers its own mechanism to intercept fopen() et al.). Others can lurk
> > in the background, too. It would even be trivial to write an app that
> > aoss will not work with - ever (unless the code be modified - which is
> > not an option for closed source apps).
> > 
> > It simply cannot ever work with _all_ apps (as opposed to kernel level
> > OSS emu  which can be made to work with _all_ apps (at least in
> > principle)).
> > 
> 
> OK so you can contrive an example.  Have we ever seen a real world app
> where aoss can't work?

  Skype. Earlier Quake 3 Arena (now Q3A is open source with SDL sound,
so it had native ALSA).

(Continue reading)

headers

Lee Revell | 5 Jan 20:10

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

On Thu, 2006-01-05 at 19:47 +0100, Tomasz Torcz wrote:
> On Thu, Jan 05, 2006 at 01:36:20PM -0500, Lee Revell wrote:
> > On Thu, 2006-01-05 at 12:43 +0100, Florian Schmidt wrote:
> > > On Thu, 05 Jan 2006 02:16:35 -0500
> > > Lee Revell <rlrevell <at> joe-job.com> wrote:
> > > 
> > > > On Wed, 2006-01-04 at 11:37 +0100, tapas wrote:
> > > > > ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
> > > > > software mixing. As aoss cannot provide OSS emulation to all OSS apps
> > > > 
> > > > Why not?
> > > 
> > > I did write it out before. aoss is a LD_PRELOAD hack. Apps/libs that
> > > resolve the system call symbols at build time cannot be made to use
> > > these calls from a different lib (which is what LD_PRELOAD tries to do).
> > > A famous example is libc for which a workaround was added (as libc
> > > offers its own mechanism to intercept fopen() et al.). Others can lurk
> > > in the background, too. It would even be trivial to write an app that
> > > aoss will not work with - ever (unless the code be modified - which is
> > > not an option for closed source apps).
> > > 
> > > It simply cannot ever work with _all_ apps (as opposed to kernel level
> > > OSS emu  which can be made to work with _all_ apps (at least in
> > > principle)).
> > > 
> > 
> > OK so you can contrive an example.  Have we ever seen a real world app
> > where aoss can't work?
> 
>   Skype. Earlier Quake 3 Arena (now Q3A is open source with SDL sound,

(Continue reading)

headers

Lee Revell | 5 Jan 18:48

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

On Thu, 2006-01-05 at 12:43 +0100, Florian Schmidt wrote:
> BTW: Don't expect people to always write bug reports. We all know,
> people are lazy. More often than not, they simply give up and say
> "linux sucks" to their friends. Or if they can differentiate a little
> more, they'll say "ALSA sucks" ;) [<- smiley, indicates humor].
> Especially those who use closed source apps ;) 

Of course I don't expect every end user with a problem to file a bug
report (although Mantis makes it much easier than Bugzilla) but I sure
as hell expect people who complain about ALSA on LKML to.

Unless we get some useful bug reports out of it this thread is much ado
about nothing.  Come on people, put up or shut up.

https://bugtrack.alsa-project.org/alsa-bug/main_page.php

Lee

-
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

headers

Ville Herva | 8 Jan 22:07

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

On Thu, Jan 05, 2006 at 12:48:49PM -0500, you [Lee Revell] wrote:
> On Thu, 2006-01-05 at 12:43 +0100, Florian Schmidt wrote:
> > BTW: Don't expect people to always write bug reports. We all know,
> > people are lazy. More often than not, they simply give up and say
> > "linux sucks" to their friends. Or if they can differentiate a little
> > more, they'll say "ALSA sucks" ;) [<- smiley, indicates humor].
> > Especially those who use closed source apps ;) 
> 
> Of course I don't expect every end user with a problem to file a bug
> report (although Mantis makes it much easier than Bugzilla) but I sure
> as hell expect people who complain about ALSA on LKML to.
> 
> Unless we get some useful bug reports out of it this thread is much ado
> about nothing.  Come on people, put up or shut up.
> 
> https://bugtrack.alsa-project.org/alsa-bug/main_page.php

I would love to make a useful bug report of dmix not working with M-Audio
Revolution 5.1 (it stutters so badly that it's unusable), but after hours of
twiddling with asoundrc I still can't figure out if I have it set up
correctly. Also, I can't get any sound out of headphone output. To me this
is a sign that perhaps the ALSA config scheme is a bit too complex, although
more probably, it's just me being too stupid to use it.

In perfect world, both headphone out and dmix should "just work". They do
"just work" with the OSS binary blob (as does mixing with applications that
use OSS API.)

With Intel i815 integrated sound, ALSA dmix does work.

(Continue reading)

headers

Lee Revell | 8 Jan 22:44

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

On Sun, 2006-01-08 at 23:07 +0200, Ville Herva wrote:
> On Thu, Jan 05, 2006 at 12:48:49PM -0500, you [Lee Revell] wrote:
> > On Thu, 2006-01-05 at 12:43 +0100, Florian Schmidt wrote:
> > > BTW: Don't expect people to always write bug reports. We all know,
> > > people are lazy. More often than not, they simply give up and say
> > > "linux sucks" to their friends. Or if they can differentiate a little
> > > more, they'll say "ALSA sucks" ;) [<- smiley, indicates humor].
> > > Especially those who use closed source apps ;) 
> > 
> > Of course I don't expect every end user with a problem to file a bug
> > report (although Mantis makes it much easier than Bugzilla) but I sure
> > as hell expect people who complain about ALSA on LKML to.
> > 
> > Unless we get some useful bug reports out of it this thread is much ado
> > about nothing.  Come on people, put up or shut up.
> > 
> > https://bugtrack.alsa-project.org/alsa-bug/main_page.php
> 
> I would love to make a useful bug report of dmix not working with M-Audio
> Revolution 5.1 (it stutters so badly that it's unusable), but after hours of
> twiddling with asoundrc I still can't figure out if I have it set up
> correctly. Also, I can't get any sound out of headphone output. To me this
> is a sign that perhaps the ALSA config scheme is a bit too complex, although
> more probably, it's just me being too stupid to use it.

No it's a sign that the Revolution 5.1 is not well supported yet.  It
was not supported at all until a few weeks ago.

Lee

(Continue reading)

headers

Ville Herva | 9 Jan 09:16

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

On Sun, Jan 08, 2006 at 04:44:28PM -0500, you [Lee Revell] wrote:
> 
> No it's a sign that the Revolution 5.1 is not well supported yet.  It
> was not supported at all until a few weeks ago.

Ok, I see. (It was just that the revo51 changelog entry revo51 was not
exactly verbose wrt. what's supported.)

You won't need the bug report just yet, then? 

I'll keep retesting the new releases.

-- v -- 

v <at> iki.fi

-
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

headers

Lee Revell | 9 Jan 14:52

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

On Mon, 2006-01-09 at 10:16 +0200, Ville Herva wrote:
> On Sun, Jan 08, 2006 at 04:44:28PM -0500, you [Lee Revell] wrote:
> > 
> > No it's a sign that the Revolution 5.1 is not well supported yet.  It
> > was not supported at all until a few weeks ago.
> 
> Ok, I see. (It was just that the revo51 changelog entry revo51 was not
> exactly verbose wrt. what's supported.)
> 
> You won't need the bug report just yet, then? 
> 
> I'll keep retesting the new releases.

Sure, we'd like the bug report.  I just wanted to point out that many
people who tell everyone that "ALSA sucks" like you and JWZ, have really
just made the mistake of buying bleeding edge barely-supported hardware.

If vendors gave us more docs so that reverse engineering drivers was not
the norm, the situation would improve greatly.

Lee

-
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

headers

Ville Herva | 9 Jan 15:22

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

On Mon, Jan 09, 2006 at 08:52:11AM -0500, you [Lee Revell] wrote:
> 
> Sure, we'd like the bug report.  

I will try to come up with one.

> I just wanted to point out that many people who tell everyone that "ALSA
> sucks" like you and JWZ, have really just made the mistake of buying
> bleeding edge barely-supported hardware.

Yes.

I'll happily admit I definetely made just that mistake.

Before I bought the new card, I did some quick asking around, and heard that
M-Audio was supposedly good. I just wanted better sound quality than the
integrated I815 sound (shouldn't be much to ask), and preferably HW mixing.
I checked that revo7.1 was supported, but when I went to the reseller, they
were out of stock for that one. So I made a quick and unconsidered decision
to buy revo5.1 instead.

So it was definetely bad research on my part. 

But I still maintain that the asoundrc required for swmixing is not as
trivial as "just works". It wasn't even with i815 audio.

> If vendors gave us more docs so that reverse engineering drivers was not
> the norm, the situation would improve greatly.

I understand.

(Continue reading)

headers

Lee Revell | 9 Jan 16:18

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

On Mon, 2006-01-09 at 16:22 +0200, Ville Herva wrote:
> On Mon, Jan 09, 2006 at 08:52:11AM -0500, you [Lee Revell] wrote:
> > 
> > Sure, we'd like the bug report.  
> 
> I will try to come up with one.
> 
> > I just wanted to point out that many people who tell everyone that "ALSA
> > sucks" like you and JWZ, have really just made the mistake of buying
> > bleeding edge barely-supported hardware.
> 
> Yes.
> 
> I'll happily admit I definetely made just that mistake.
> 
> Before I bought the new card, I did some quick asking around, and heard that
> M-Audio was supposedly good. I just wanted better sound quality than the
> integrated I815 sound (shouldn't be much to ask), and preferably HW mixing.
> I checked that revo7.1 was supported, but when I went to the reseller, they
> were out of stock for that one. So I made a quick and unconsidered decision
> to buy revo5.1 instead.
> 
> So it was definetely bad research on my part. 
> 
> But I still maintain that the asoundrc required for swmixing is not as
> trivial as "just works". It wasn't even with i815 audio.

Since ALSA 1.0.9 (alsa-lib and alsa-driver > 1.0.9 required) no special
configuration is required to get software mixing to work for i815 (and
other chipsets which lack hardware mixing), with a few exception like

(Continue reading)

headers

Ville Herva | 9 Jan 17:21

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

On Mon, Jan 09, 2006 at 10:18:13AM -0500, you [Lee Revell] wrote:
> 
> Since ALSA 1.0.9 (alsa-lib and alsa-driver > 1.0.9 required) no special
> configuration is required to get software mixing to work for i815 (and
> other chipsets which lack hardware mixing), with a few exception like
> ICE1712 and ICE1724 where a more complex configuration was required due
> to hardware restrictions.
> 
> You should never have to touch an .asoundrc file to get software mixing
> to work, if you do it's a bug.

When I tried with i815, my ALSA version might have been <= 1.0.9. 

Revo51 is ICE1724 based. I gather I still need the asoundrc config to get
some kind of mixing, right? At least it doesn't work without (and with it,
it badly stutters right now.)

-- v -- 

v <at> iki.fi

-
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

headers

Lee Revell | 9 Jan 17:22

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

On Mon, 2006-01-09 at 18:21 +0200, Ville Herva wrote:
> Revo51 is ICE1724 based. I gather I still need the asoundrc config to get
> some kind of mixing, right? At least it doesn't work without (and with it,
> it badly stutters right now.)

Try the latest ALSA CVS code.

Lee

-
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

headers

Takashi Iwai | 4 Jan 18:54

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

At Wed, 4 Jan 2006 11:37:26 +0100,
tapas wrote:
> 
> -- ALSA's default open mode is "blocking". But the ALSA API uses the
> term blocking in two meanings and throws them together into the open
> mode of a pcm device. Normally on device files, blocking access means a
> read()/write() returns, when there's data which has actually been
> read/written to the device. nonblocking access means, read()/write()
> return immediately. In ALSA blocking mode means above _plus_ that the
> open call will only immediately return (in case of contention) when the
> previous user of the audio device has given it up. 
> 
> The combination of the last two is deadly :) It leaves users with
> nonfunctional sound plus seemingly hanging apps when their soundcard is
> not hardware mixing capable. So IMHO, to fix these two issues really is
> the most pressing matter of all, but like i said, sadly ALSA devs seem
> to disagree (i haven't followed ALSA development that closely lately
> though).

Note that as of OSS emulation, this is no longer true.  The OSS
devices are opened as "non-blocking" per default.  ALSA native devices
are opened as "blocking" just to keep the compatible behavior,
though.

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

headers

Florian Schmidt | 4 Jan 19:17

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

On Wed, 04 Jan 2006 18:54:48 +0100
Takashi Iwai <tiwai <at> suse.de> wrote:

> Note that as of OSS emulation, this is no longer true.  The OSS
> devices are opened as "non-blocking" per default.  ALSA native devices
> are opened as "blocking" just to keep the compatible behavior,
> though.

Hi Takashi,

do you know of _any_ app relying on this behaviour? If not, make
blocking open and blocking read/write different things (as they really
are different things). Maybe create a /proc control, so users can revert
to the olde behaviour if there really is any need.

I simply cannot imagine that any ALSA app relies on this weird
behaviour. I only ever hear how it confuses people [Hang out a bit on
#alsa on irc.freenode.org: "my alsa driver is broken as this and that
app hangs!!!" - "no it's expected behaviour" - "WTF!!!?" ;) <- smiley].
It is also still quite a common case i suppose as when an OSS app has a
device open, the ALSA apps trying to open it in blocking mode will again
hang. Or so i'd think. My soundcard is hw mixing capable (thank god ;)),
so i don't really know, and it's been a while since i hang out regularly
on that channel. If i talk out of my ass, let me know.

Regards,
Flo
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to majordomo <at> vger.kernel.org

(Continue reading)

headers

Lee Revell | 5 Jan 08:11

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

On Wed, 2006-01-04 at 19:17 +0100, Florian Schmidt wrote:
> On Wed, 04 Jan 2006 18:54:48 +0100
> Takashi Iwai <tiwai <at> suse.de> wrote:
> 
> > Note that as of OSS emulation, this is no longer true.  The OSS
> > devices are opened as "non-blocking" per default.  ALSA native devices
> > are opened as "blocking" just to keep the compatible behavior,
> > though.
> 
> Hi Takashi,
> 
> do you know of _any_ app relying on this behaviour? If not, make
> blocking open and blocking read/write different things (as they really
> are different things). Maybe create a /proc control, so users can revert
> to the olde behaviour if there really is any need.
> 
> I simply cannot imagine that any ALSA app relies on this weird
> behaviour. I only ever hear how it confuses people [Hang out a bit on
> #alsa on irc.freenode.org: "my alsa driver is broken as this and that
> app hangs!!!" - "no it's expected behaviour" - "WTF!!!?" ;) <- smiley].
> It is also still quite a common case i suppose as when an OSS app has a
> device open, the ALSA apps trying to open it in blocking mode will again
> hang. Or so i'd think. My soundcard is hw mixing capable (thank god ;)),
> so i don't really know, and it's been a while since i hang out regularly
> on that channel. If i talk out of my ass, let me know.

All of this was solved with the switch in ALSA 1.0.9 to use dmix by
default.  If it does not Just Work it's a bug and we need to hear about
it.

(Continue reading)

headers

Edgar Toernig | 5 Jan 20:09

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

Lee Revell wrote:
>
> All of this was solved with the switch in ALSA 1.0.9 to use dmix by
> default.  If it does not Just Work it's a bug and we need to hear about
> it.

So then:  xawtv4 (dvb-app) works with hw:0 but not with 1.0.9's dmix default.
It works with /dev/dsp1 (usb-speakers) but not with /dev/dsp0 (atiixp ac'97).
vdr's softdevice (another dvb-app) works with dmix-default but not with hw:0.
And that's my experience with most audio apps - you have to try all configur-
ations until you find one that works.  Sure, maybe badly written apps but
there must be something wrong if so many developers have problems with
Alsa.  I've even resigned to grok the config files 

Ciao, ET.

And btw, with 2.6.15 the usb-speakers only produce noise most of the time.
-
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

headers

Lee Revell | 5 Jan 20:29

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

On Thu, 2006-01-05 at 20:09 +0100, Edgar Toernig wrote:
> Lee Revell wrote:
> >
> > All of this was solved with the switch in ALSA 1.0.9 to use dmix by
> > default.  If it does not Just Work it's a bug and we need to hear about
> > it.
> 
> So then:  xawtv4 (dvb-app) works with hw:0 but not with 1.0.9's dmix default.
> It works with /dev/dsp1 (usb-speakers) but not with /dev/dsp0 (atiixp ac'97).
> vdr's softdevice (another dvb-app) works with dmix-default but not with hw:0.
> And that's my experience with most audio apps - you have to try all configur-
> ations until you find one that works.  Sure, maybe badly written apps but
> there must be something wrong if so many developers have problems with
> Alsa.  I've even resigned to grok the config files 
> 
> Ciao, ET.
> 

Come on, this is LKML, you should know that "it doesn't work" is not a
useful bug report.

> And btw, with 2.6.15 the usb-speakers only produce noise most of the time.
> 

Known regression, this is being worked on.  It was known and posted to
LKML before the 2.6.15 release, unfortunately 2.6.15 was released with
this bug anyway.

Lee

(Continue reading)

headers

Edgar Toernig | 5 Jan 21:24

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

Lee Revell wrote:
>
> Edgar Toernig wrote:
> > Lee Revell wrote:
> > >
> > >  If it does not Just Work it's a bug and we need to hear about it.
> > 
> > So then:  xawtv4 (dvb-app) works with hw:0 but not with 1.0.9's dmix default.
> > It works with /dev/dsp1 (usb-speakers) but not with /dev/dsp0 (atiixp ac'97).
> > vdr's softdevice (another dvb-app) works with dmix-default but not with hw:0.
> 
> Come on, this is LKML, you should know that "it doesn't work" is not a
> useful bug report.

xawtv4 with dmix is just silent and aborts when its queue of outstanding pcm
data is filled up.

Trying to use /dev/dsp0 starts fine for a fraction of a second but then
either stays silent or stutters until its audio-queue overflows again.

With vdr its similar: when using hw:0 it only stutters (and fills the log
with xrun errors).  I had a short look once - it uses a very small buffer
(iirc about 4kb) and gets constant underruns which it tries to handle
via prepare-something but it's unable to recover.  With dmix it works fine,
probably because of the bigger mixing buffer.

> Sure, maybe badly written apps but there must be something wrong if so
> many developers have problems with Alsa.  I've even resigned to grok
> the config files

(Continue reading)

headers

Lee Revell | 5 Jan 21:29

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

On Thu, 2006-01-05 at 21:24 +0100, Edgar Toernig wrote:
> Lee Revell wrote:
> >
> > Edgar Toernig wrote:
> > > Lee Revell wrote:
> > > >
> > > >  If it does not Just Work it's a bug and we need to hear about it.
> > > 
> > > So then:  xawtv4 (dvb-app) works with hw:0 but not with 1.0.9's dmix default.
> > > It works with /dev/dsp1 (usb-speakers) but not with /dev/dsp0 (atiixp ac'97).
> > > vdr's softdevice (another dvb-app) works with dmix-default but not with hw:0.
> > 
> > Come on, this is LKML, you should know that "it doesn't work" is not a
> > useful bug report.
> 
> xawtv4 with dmix is just silent and aborts when its queue of outstanding pcm
> data is filled up.
> 
> Trying to use /dev/dsp0 starts fine for a fraction of a second but then
> either stays silent or stutters until its audio-queue overflows again.
> 
> With vdr its similar: when using hw:0 it only stutters (and fills the log
> with xrun errors).  I had a short look once - it uses a very small buffer
> (iirc about 4kb) and gets constant underruns which it tries to handle
> via prepare-something but it's unable to recover.  With dmix it works fine,
> probably because of the bigger mixing buffer.

Broken app.  It needs to set a sane buffer size and not rely on the
driver default.

(Continue reading)

headers

Lee Revell | 5 Jan 21:19

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

On Thu, 2006-01-05 at 14:29 -0500, Lee Revell wrote:
> > And btw, with 2.6.15 the usb-speakers only produce noise most of the
> time.
> > 
> 
> Known regression, this is being worked on.  It was known and posted to
> LKML before the 2.6.15 release, unfortunately 2.6.15 was released with
> this bug anyway.
> 

If you'd like to help debug this:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1585

There's a workaround patch available.  We still don't know the exact
nature of the bug.

Lee

-
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

headers

Edgar Toernig | 5 Jan 22:05

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

Lee Revell wrote:
>
> > > And btw, with 2.6.15 the usb-speakers only produce noise most of
> > > the time.
> > 
> > Known regression, this is being worked on.  It was known and posted to
> > LKML before the 2.6.15 release, unfortunately 2.6.15 was released with
> > this bug anyway.
> 
> If you'd like to help debug this:
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1585
> 
> There's a workaround patch available.  We still don't know the exact
> nature of the bug.

Well, the problem I had was not exactly the same (I get loud noise, as
if the samples are byte-swapped) but

   alsa-usbaudio-2.6.15-revert-008.patch

seems to fix that.  Thanks.

But now (alsa-1.0.9 userspace):

  alsaplayer -i text -d hw:0 ...    --> ok
  alsaplayer -i text -d hw:1 ...    --> ok
  alsaplayer -i text -d dmix:0 ...  --> ok
  alsaplayer -i text -d dmix:1 ...  --> no error, no sound, just total
                                        silence.  But the clock's running.

(Continue reading)

headers

Lee Revell | 5 Jan 22:10

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

On Thu, 2006-01-05 at 22:05 +0100, Edgar Toernig wrote:
> Lee Revell wrote:
> >
> > > > And btw, with 2.6.15 the usb-speakers only produce noise most of
> > > > the time.
> > > 
> > > Known regression, this is being worked on.  It was known and posted to
> > > LKML before the 2.6.15 release, unfortunately 2.6.15 was released with
> > > this bug anyway.
> > 
> > If you'd like to help debug this:
> > 
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1585
> > 
> > There's a workaround patch available.  We still don't know the exact
> > nature of the bug.
> 
> Well, the problem I had was not exactly the same (I get loud noise, as
> if the samples are byte-swapped) but
> 
>    alsa-usbaudio-2.6.15-revert-008.patch
> 
> seems to fix that.  Thanks.
> 
> But now (alsa-1.0.9 userspace):
> 
>   alsaplayer -i text -d hw:0 ...    --> ok
>   alsaplayer -i text -d hw:1 ...    --> ok
>   alsaplayer -i text -d dmix:0 ...  --> ok
>   alsaplayer -i text -d dmix:1 ...  --> no error, no sound, just total

(Continue reading)

headers

Marcin Dalecki | 4 Jan 20:28

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


On 2006-01-04, at 19:17, Florian Schmidt wrote:
> Maybe create a /proc control, so users can revert
> to the olde behaviour if there really is any need.

YES YES! After all who doesn't use his system logged in as root?

-
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

headers

Jim Crilly | 5 Jan 22:20

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

On 01/04/06 08:28:59PM +0100, Marcin Dalecki wrote:
> 
> On 2006-01-04, at 19:17, Florian Schmidt wrote:
> >Maybe create a /proc control, so users can revert
> >to the olde behaviour if there really is any need.
> 
> YES YES! After all who doesn't use his system logged in as root?

You can change the rights and ownership of files in /proc, so distributions
that use something like pam_console could change them when someone logs in.
That and most people know that poking around in /proc generally requires
root priviledges so making them use su or sudo wouldn't be a surprise.

Jim.

headers

Florian Schmidt | 4 Jan 20:52

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

On Wed, 4 Jan 2006 20:28:59 +0100
Marcin Dalecki <dalecki.marcin <at> neostrada.pl> wrote:

> 
> On 2006-01-04, at 19:17, Florian Schmidt wrote:
> > Maybe create a /proc control, so users can revert
> > to the olde behaviour if there really is any need.
> 
> YES YES! After all who doesn't use his system logged in as root?

Well, maybe it is a bad idea. Got a better one up your sleeve? Or just
sarcasm? 

Maybe make it a .asoundrc option (which libasound reads everytime a
device is opened anyways). Maybe even per device.

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

headers

Takashi Iwai | 5 Jan 12:15

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

At Wed, 4 Jan 2006 20:52:32 +0100,
Florian Schmidt wrote:
> 
> On Wed, 4 Jan 2006 20:28:59 +0100
> Marcin Dalecki <dalecki.marcin <at> neostrada.pl> wrote:
> 
> > 
> > On 2006-01-04, at 19:17, Florian Schmidt wrote:
> > > Maybe create a /proc control, so users can revert
> > > to the olde behaviour if there really is any need.
> > 
> > YES YES! After all who doesn't use his system logged in as root?
> 
> Well, maybe it is a bad idea. Got a better one up your sleeve? Or just
> sarcasm? 
> 
> Maybe make it a .asoundrc option (which libasound reads everytime a
> device is opened anyways). Maybe even per device.

That sounds better.  The hw plug of alsa-lib can have a new option to
force non-blocking mode open.  So, no change in the kernel side at
all.

Thanks,

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

headers

Jan Engelhardt | 5 Jan 08:11

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

>> > Maybe create a /proc control, so users can revert
>> > to the olde behaviour if there really is any need.
>> 
>> YES YES! After all who doesn't use his system logged in as root?
>

There is something like /etc/init.d/boot.local in which you can set your
preference. Who changes his blocking mode behavior every day, huh?

>Well, maybe it is a bad idea. Got a better one up your sleeve? Or just
>sarcasm? 
>
>Maybe make it a .asoundrc option (which libasound reads everytime a
>device is opened anyways). Maybe even per device.
>
And what about the OSS emulation /dev/dsp? OSS apps do not read .asoundrc.

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

headers

Alistair John Strachan | 4 Jan 18:28

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

This is a superb, informed summary of the pros and cons of ALSA.

I urge the ALSA developers to consider each point carefully so we can try to 
make ALSA even better.

On Wednesday 04 January 2006 10:37, tapas wrote:
> On Wed, 4 Jan 2006 03:51:09 +0100 (CET)
>
> Tomasz K³oczko <kloczek <at> rudy.mif.pg.gda.pl> wrote:
> > After four years ALSA development quality of sound support in Linux is
> > IMO on the ~same (still bad) level as four years ago. Still to
> > complicated but now more bloated and additionaly not ready for handle
> > fancy gadgets like BT headsets.
>
> Hi,
>
> i want to chime in here in the defense of ALSA. ALSA is vastly superiour
> for musicians using linux as opposed to a mere music consumer. Right,
> for a music consumer (mp3s, cd's, etc), OSS was probably easier to setup
> and use, but there's other advantages of ALSA vs. OSS:
>
> - userspace software mixing (or better software mixing at all. OSS
> doesn't have this (the libre version in the kernel, not the closed
> source proprietary one)
>
> - userspace resampling (i.e. you have crappy AC97 card that sounds like
> shit when resampling automatically? Use the ALSA resampler. It might
> sound like shit, too, but at least it can be fixed ;)
>
> - the biggest benefit for me: MIDI routing in between any number of

(Continue reading)

headers

Jan Engelhardt | 5 Jan 08:14

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

>This is a superb, informed summary of the pros and cons of ALSA.
>
Reminds me of Takashi's talk named "ALSA sucks". :)

>I urge the ALSA developers to consider each point carefully so we can try to 
>make ALSA even better.
>

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

headers

Alan Cox | 4 Jan 09:50

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

On Mer, 2006-01-04 at 03:51 +0100, Tomasz Kłoczko wrote:
> Be compliant with OSS specyfication allow save many time on applications 
> development level by consume (in good sense) time spend on this 
> applications by *BSD, Solaris and other systems developers (even on not 
> open source applications).

Both Solaris and FreeBSD contain Linux emulation code so in that sense
they admitted 'defeat' long ago.

> valuable functionalities in usable/simpler form for joe-like users .. 
> remember: sound support in Linux isn't for data centers/big-ass-machines :)

And distributions nowdays ship with ALSA by default, which is giving
users far better audio timing behaviour, mixing they want, digital and
analogue 5.1 outputs. OSS really isn't ideal for serious "end user"
applications like video playback

Alan

-
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

headers

Greg Louis | 4 Jan 14:21

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

On 20060104 (Wed) at 0850:34 +0000, Alan Cox wrote:
> On Mer, 2006-01-04 at 03:51 +0100, Tomasz K??oczko wrote:
> > Be compliant with OSS specyfication allow save many time on applications 
> > development level by consume (in good sense) time spend on this 
> > applications by *BSD, Solaris and other systems developers (even on not 
> > open source applications).
> 
> Both Solaris and FreeBSD contain Linux emulation code so in that sense
> they admitted 'defeat' long ago.
> 
> > valuable functionalities in usable/simpler form for joe-like users .. 
> > remember: sound support in Linux isn't for data centers/big-ass-machines :)
> 
> And distributions nowdays ship with ALSA by default, which is giving
> users far better audio timing behaviour, mixing they want, digital and
> analogue 5.1 outputs. OSS really isn't ideal for serious "end user"
> applications like video playback
> 
Ok, so I'm not serious :) just wanna do fairly standard audio things.

- ALSA doesn't (AFAIK, haven't checked for a few months) support my old
  Audiotrix sound card -- bye, machine 1
- ALSA can't be persuaded (not by me, anyway) to drive my VIA
  ac97_codec onboard sound hardware -- everything works fine except
  unmuting ;) -- bye, machine 2
- ALSA does suport my i810_audio ac97_codec laptop, but so does OSS,
  equally well (for my unsophisticated needs) and with a far less
  elephantine footprint in memory. -- strike 3, ALSA out.

So even if sound support in Linux _is_ for "big-ass" studio work, it

(Continue reading)

headers

Adrian Bunk | 4 Jan 15:41

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

On Wed, Jan 04, 2006 at 08:21:39AM -0500, Greg Louis wrote:
> On 20060104 (Wed) at 0850:34 +0000, Alan Cox wrote:
> > On Mer, 2006-01-04 at 03:51 +0100, Tomasz K??oczko wrote:
> > > Be compliant with OSS specyfication allow save many time on applications 
> > > development level by consume (in good sense) time spend on this 
> > > applications by *BSD, Solaris and other systems developers (even on not 
> > > open source applications).
> > 
> > Both Solaris and FreeBSD contain Linux emulation code so in that sense
> > they admitted 'defeat' long ago.
> > 
> > > valuable functionalities in usable/simpler form for joe-like users .. 
> > > remember: sound support in Linux isn't for data centers/big-ass-machines :)
> > 
> > And distributions nowdays ship with ALSA by default, which is giving
> > users far better audio timing behaviour, mixing they want, digital and
> > analogue 5.1 outputs. OSS really isn't ideal for serious "end user"
> > applications like video playback
> > 
> Ok, so I'm not serious :) just wanna do fairly standard audio things.
> 
> - ALSA doesn't (AFAIK, haven't checked for a few months) support my old
>   Audiotrix sound card -- bye, machine 1

Noone wants to remove the drivers for hardware not supported by ALSA 
from OSS.

After 4 years of ALSA in the kernel we are starting to remove the OSS 
drivers from the kernel where ALSA drives the same hardware.

(Continue reading)

headers

Jesper Juhl | 3 Jan 23:11

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

On 1/3/06, Adrian Bunk <bunk <at> stusta.de> wrote:
> On Tue, Jan 03, 2006 at 09:56:20PM +0100, Jesper Juhl wrote:
> > On 1/3/06, Takashi Iwai <tiwai <at> suse.de> wrote:
> > > At Tue, 3 Jan 2006 21:37:32 +0100,
> > > Tomasz Torcz wrote:
> > > >
> > > > On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> > > > > At Tue, 3 Jan 2006 18:03:16 +0100,
> > > > > Olivier Galibert wrote:
> > > > > >
> > > > > > > This is exactly why the OSS emulation option in ALSA is really a last resort
> > > > > > > and should not be an excuse for people to ignore implementing ALSA support
> > > > > > > directly. More so, it is very good justification for ditching "everything
> > > > > > > OSS" as soon as possible, at least in new software.
> > > > > >
> > > > > > Actually the crappy state of OSS emulation is a good reason to ditch
> > > > > > ALSA in its current implementation.  As Linus reminded not so long
> > > > > > ago, backwards compatibility is extremely important.
> > > > >
> > > > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > > > software mixing in the kernel, too :)
> > > >
> > > >  OSS will support software mixing. In kernel. On NetBSD.
> > > > http://kerneltrap.org/node/4388
> > >
> > > Why do we need to keep the compatibility with NetBSD?
> > >
> > Software mixing is a really nice feature for people with soundscards
> > that can't do hardware mixing, so if the OSS compatibility could
> > transparently do software mixing for apps using OSS api that would be

(Continue reading)

headers

Takashi Iwai | 4 Jan 12:46

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

At Tue, 3 Jan 2006 23:11:47 +0100,
Jesper Juhl wrote:
> 
> On 1/3/06, Adrian Bunk <bunk <at> stusta.de> wrote:
> > On Tue, Jan 03, 2006 at 09:56:20PM +0100, Jesper Juhl wrote:
> > > On 1/3/06, Takashi Iwai <tiwai <at> suse.de> wrote:
> > > > At Tue, 3 Jan 2006 21:37:32 +0100,
> > > > Tomasz Torcz wrote:
> > > > >
> > > > > On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> > > > > > At Tue, 3 Jan 2006 18:03:16 +0100,
> > > > > > Olivier Galibert wrote:
> > > > > > >
> > > > > > > > This is exactly why the OSS emulation option in ALSA is really a last resort
> > > > > > > > and should not be an excuse for people to ignore implementing ALSA support
> > > > > > > > directly. More so, it is very good justification for ditching "everything
> > > > > > > > OSS" as soon as possible, at least in new software.
> > > > > > >
> > > > > > > Actually the crappy state of OSS emulation is a good reason to ditch
> > > > > > > ALSA in its current implementation.  As Linus reminded not so long
> > > > > > > ago, backwards compatibility is extremely important.
> > > > > >
> > > > > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > > > > software mixing in the kernel, too :)
> > > > >
> > > > >  OSS will support software mixing. In kernel. On NetBSD.
> > > > > http://kerneltrap.org/node/4388
> > > >
> > > > Why do we need to keep the compatibility with NetBSD?
> > > >

(Continue reading)

headers

Jan Engelhardt | 4 Jan 15:46

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

>> Still would be nice if users of ALSA who have the OSS backwards compat
>> enabled would thus also get transparent software mixing for all apps
>> using the OSS API.
>> not crucial, that's not what I'm saying, just nice if it would be possible.
>
>Technicall it's trivial to implement the soft-mixing in the kernel.
>The question is whether it's the right implementation.
>We have a user-space softmix for ALSA, and aoss wrapper for OSS using
>it.  (I know aoss still has some problems that should be fixed,
>though.)
>
Software mixing in the kernel is like FPU ops in the kernel...

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

headers

Kyle Moffett | 4 Jan 21:12

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

On Jan 04, 2006, at 09:46, Jan Engelhardt wrote:
>>> Still would be nice if users of ALSA who have the OSS backwards  
>>> compat
>>> enabled would thus also get transparent software mixing for all apps
>>> using the OSS API.
>>> not crucial, that's not what I'm saying, just nice if it would be  
>>> possible.
>>
>> Technicall it's trivial to implement the soft-mixing in the kernel.
>> The question is whether it's the right implementation.
>> We have a user-space softmix for ALSA, and aoss wrapper for OSS using
>> it.  (I know aoss still has some problems that should be fixed,
>> though.)
>
> Software mixing in the kernel is like FPU ops in the kernel...

Software mixing in the kernel probably _IS_ FPU ops in the kernel.   
We already do video mixing (think X) in userspace, I see no reason  
why audio should be different.

Cheers,
Kyle Moffett

--
Somone asked me why I work on this free (http://www.fsf.org/ 
philosophy/) software stuff and not get a real job. Charles Schulz  
had the best answer:

"Why do musicians compose symphonies and poets write poems? They do  
it because life wouldn't have any meaning for them if they didn't.

(Continue reading)

headers

Olivier Galibert | 4 Jan 23:25

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

On Wed, Jan 04, 2006 at 03:12:33PM -0500, Kyle Moffett wrote:
> Software mixing in the kernel probably _IS_ FPU ops in the kernel.   
> We already do video mixing (think X) in userspace, I see no reason  
> why audio should be different.

Bad comparison.  X as it is is so good that if you want something
remotely looking like performance you end up with a proprietary kernel
module the size of Cleveland.

Software mixing in practice could be in the kernel, it's for instance
way less complex than say the network stack.  I mean, even with an
helper thread, it fits in 20-30 lines of kernel code or so.  But what
happens is that you quickly want much more than that.  To give you
some examples:

- resampling (with a wide array of algorithms with a different cpu
  usage/result quality mix), especially since a number of chips are
  48KHz only.

- AC3/DTS encoding for multichannel output on spdif.

- spatialisation (virtual or real, depending on the hardware
  available).

- dynamic range compression.

So as soon as you build some decent infrastructure to allow for that
in userspace, having software mixing specifically in the kernel does
not make much sense.

(Continue reading)

headers

Marcin Dalecki | 4 Jan 17:43

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


On 2006-01-04, at 15:46, Jan Engelhardt wrote:

>>> Still would be nice if users of ALSA who have the OSS backwards  
>>> compat
>>> enabled would thus also get transparent software mixing for all apps
>>> using the OSS API.
>>> not crucial, that's not what I'm saying, just nice if it would be  
>>> possible.
>>
>> Technicall it's trivial to implement the soft-mixing in the kernel.
>> The question is whether it's the right implementation.
>> We have a user-space softmix for ALSA, and aoss wrapper for OSS using
>> it.  (I know aoss still has some problems that should be fixed,
>> though.)
>>
> Software mixing in the kernel is like FPU ops in the kernel...

Could you please elaborate a tad bit more on the analogy? It doesn't  
appear to be stunningly obvious.
Are you aware of the reasons why floating point operations are  
avoided inside the kernel?
They are *not* principal - it's just engineering pragmatism.

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

headers

Jan Engelhardt | 5 Jan 11:57

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

>> Software mixing in the kernel is like FPU ops in the kernel...
>
> Could you please elaborate a tad bit more on the analogy? It doesn't appear to
> be stunningly obvious.
>
It has never been done before in Linux, so there must be a reason to it.
There was also a reason why khttpd was (going in and) going out.

> Are you aware of the reasons why floating point operations are avoided inside
> the kernel?
>
Because it is "unportable". You cannot expect to have every hardware Linux 
runs on today to have an FPU engine (hey, like that ol' i386 I got, needs 
CONFIG_MATH_EMU...), especially in the Embedded Devices sector.

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

headers

Marcin Dalecki | 5 Jan 13:44

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

On 2006-01-05, at 11:57, Jan Engelhardt wrote:

>>> Software mixing in the kernel is like FPU ops in the kernel...
>>
>> Could you please elaborate a tad bit more on the analogy? It  
>> doesn't appear to
>> be stunningly obvious.
>>
> It has never been done before in Linux, so there must be a reason  
> to it.
> There was also a reason why khttpd was (going in and) going out.
>
>> Are you aware of the reasons why floating point operations are  
>> avoided inside
>> the kernel?
>>
> Because it is "unportable". You cannot expect to have every  
> hardware Linux
> runs on today to have an FPU engine (hey, like that ol' i386 I got,  
> needs
> CONFIG_MATH_EMU...), especially in the Embedded Devices sector.

First - the answer you provide is far from complete and it doesn't  
even touch the more important reasons why the kernel avoids doing  
FPU. (No, I don't feel obliged to explain the issue to you. Just a  
note: The reasons are just merely *technical* and not principal.)

Second - you still didn't explain why this allows you to conclude  
that sound mixing should in no way be done inside the kernel.

(Continue reading)

headers

Lee Revell | 5 Jan 19:33

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

On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
> Second - you still didn't explain why this allows you to conclude  
> that sound mixing should in no way be done inside the kernel. 

It works perfectly right now in userspace.  Therefore it should not be
in the kernel.

Lee

-
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

headers

Hannu Savolainen | 6 Jan 00:19

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

On Thu, 5 Jan 2006, Lee Revell wrote:

> On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
> > Second - you still didn't explain why this allows you to conclude  
> > that sound mixing should in no way be done inside the kernel. 
> 
> It works perfectly right now in userspace.  Therefore it should not be
> in the kernel.
So all the complaints about dmix problems in the ALSA mailing lists are 
just exceptions that prove the above statement to be true.

Best regards,

Hannu
-----
Hannu Savolainen (hannu <at> opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM

headers

Lee Revell | 6 Jan 00:33

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

On Fri, 2006-01-06 at 01:19 +0200, Hannu Savolainen wrote:
> On Thu, 5 Jan 2006, Lee Revell wrote:
> 
> > On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
> > > Second - you still didn't explain why this allows you to conclude  
> > > that sound mixing should in no way be done inside the kernel. 
> > 
> > It works perfectly right now in userspace.  Therefore it should not be
> > in the kernel.
> So all the complaints about dmix problems in the ALSA mailing lists are 
> just exceptions that prove the above statement to be true.

No, it just means ALSA like the kernel is a work in progress.  Anyway
almost all the known issues have been fixed.  It works perfectly for the
vast majority of users.

Are all the Oopses posted to LKML evidence that the kernel is
fundamentally broken?

Lee

headers

caszonyi | 6 Jan 14:20

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

On Thu, 5 Jan 2006, Lee Revell wrote:

> On Fri, 2006-01-06 at 01:19 +0200, Hannu Savolainen wrote:
>> On Thu, 5 Jan 2006, Lee Revell wrote:
>>
>>> On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
>>>> Second - you still didn't explain why this allows you to conclude
>>>> that sound mixing should in no way be done inside the kernel.
>>>
>>> It works perfectly right now in userspace.  Therefore it should not be
>>> in the kernel.
>> So all the complaints about dmix problems in the ALSA mailing lists are
>> just exceptions that prove the above statement to be true.
>
> No, it just means ALSA like the kernel is a work in progress.  Anyway
> almost all the known issues have been fixed.  It works perfectly for the
> vast majority of users.
>

Ok. It seems i'm a minority.
I switched xmms to alsa
If i play a stream in xmms using alsa output and try to play in the same 
time a movie in mplayer the last message printed by mplayer is
alsa-init: 1 soundcard found, using: default
and then it hangs until i press stop button in xmms. When i press the stop 
button in xmms the movie begins to play. If i press now the play button in 
xmms it says:
** WARNING **: alsa_setup(): Failed to open pcm device (default): Device 
or resource busy

(Continue reading)

headers

Lee Revell | 6 Jan 19:27

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

On Fri, 2006-01-06 at 15:20 +0200, caszonyi <at> rdslink.ro wrote:
> On Thu, 5 Jan 2006, Lee Revell wrote:
> 
> > On Fri, 2006-01-06 at 01:19 +0200, Hannu Savolainen wrote:
> >> On Thu, 5 Jan 2006, Lee Revell wrote:
> >>
> >>> On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
> >>>> Second - you still didn't explain why this allows you to conclude
> >>>> that sound mixing should in no way be done inside the kernel.
> >>>
> >>> It works perfectly right now in userspace.  Therefore it should not be
> >>> in the kernel.
> >> So all the complaints about dmix problems in the ALSA mailing lists are
> >> just exceptions that prove the above statement to be true.
> >
> > No, it just means ALSA like the kernel is a work in progress.  Anyway
> > almost all the known issues have been fixed.  It works perfectly for the
> > vast majority of users.
> >
> 
> Ok. It seems i'm a minority.
> I switched xmms to alsa
> If i play a stream in xmms using alsa output and try to play in the same 
> time a movie in mplayer the last message printed by mplayer is
> alsa-init: 1 soundcard found, using: default
> and then it hangs until i press stop button in xmms. When i press the stop 
> button in xmms the movie begins to play. If i press now the play button in 
> xmms it says:
> ** WARNING **: alsa_setup(): Failed to open pcm device (default): Device 
> or resource busy

(Continue reading)

headers

Lee Revell | 6 Jan 19:24

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

On Fri, 2006-01-06 at 15:20 +0200, caszonyi <at> rdslink.ro wrote:
> On Thu, 5 Jan 2006, Lee Revell wrote:
> 
> > On Fri, 2006-01-06 at 01:19 +0200, Hannu Savolainen wrote:
> >> On Thu, 5 Jan 2006, Lee Revell wrote:
> >>
> >>> On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
> >>>> Second - you still didn't explain why this allows you to conclude
> >>>> that sound mixing should in no way be done inside the kernel.
> >>>
> >>> It works perfectly right now in userspace.  Therefore it should not be
> >>> in the kernel.
> >> So all the complaints about dmix problems in the ALSA mailing lists are
> >> just exceptions that prove the above statement to be true.
> >
> > No, it just means ALSA like the kernel is a work in progress.  Anyway
> > almost all the known issues have been fixed.  It works perfectly for the
> > vast majority of users.
> >
> 
> Ok. It seems i'm a minority.
> I switched xmms to alsa

XMMS has a bug where it uses "hw:0,0" by default which will prevent dmix
from working.  It should be using the "default" PCM.

Lee

headers

James Courtier-Dutton | 6 Jan 14:43

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

caszonyi <at> rdslink.ro wrote:

> On Thu, 5 Jan 2006, Lee Revell wrote:
>
>> On Fri, 2006-01-06 at 01:19 +0200, Hannu Savolainen wrote:
>>
>>> On Thu, 5 Jan 2006, Lee Revell wrote:
>>>
>>>> On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
>>>>
>>>>> Second - you still didn't explain why this allows you to conclude
>>>>> that sound mixing should in no way be done inside the kernel.
>>>>
>>>>
>>>> It works perfectly right now in userspace.  Therefore it should not be
>>>> in the kernel.
>>>
>>> So all the complaints about dmix problems in the ALSA mailing lists are
>>> just exceptions that prove the above statement to be true.
>>
>>
>> No, it just means ALSA like the kernel is a work in progress.  Anyway
>> almost all the known issues have been fixed.  It works perfectly for the
>> vast majority of users.
>>
>
> Ok. It seems i'm a minority.
> I switched xmms to alsa
> If i play a stream in xmms using alsa output and try to play in the 
> same time a movie in mplayer the last message printed by mplayer is

(Continue reading)

headers

Marcin Dalecki | 5 Jan 21:03

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


On 2006-01-05, at 19:33, Lee Revell wrote:

> On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
>> Second - you still didn't explain why this allows you to conclude
>> that sound mixing should in no way be done inside the kernel.
>
> It works perfectly right now in userspace.

Yeah - for you maybe...

-
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

headers

Diego Calleja | 6 Jan 03:40

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

El Thu, 5 Jan 2006 21:03:27 +0100,
Marcin Dalecki <martin <at> dalecki.de> escribió:

> 
> On 2006-01-05, at 19:33, Lee Revell wrote:
> 
> > On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
> >> Second - you still didn't explain why this allows you to conclude
> >> that sound mixing should in no way be done inside the kernel.
> >
> > It works perfectly right now in userspace.
> 
> Yeah - for you maybe...

Amazing - even windows is getting sound mixing out of the kernel
in windows vista because they've learnt (the hard way) that it's
the Right Thing and linux people is trying to get it in?

-
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

headers

Olivier Galibert | 6 Jan 15:57

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

On Fri, Jan 06, 2006 at 03:40:26AM +0100, Diego Calleja wrote:
> Amazing - even windows is getting sound mixing out of the kernel
> in windows vista because they've learnt (the hard way) that it's
> the Right Thing and linux people is trying to get it in?

You misread.  Most people just want to have things work like they
should have for years.  Technical people, at least Marcin and I, want
a documented kernel interface with optional libraries over it (think
libX11 vs. the X Protocol, or glibc/klibc/uclibc/libc5 vs. the system
calls), and then behind that have the kernel route the data to
userspace demon(s) or the hardware depending on root-level setup and
configuration.

ALSA does not have a documented kernel interface nor an optional
library but a mandatory library.  A highly complex, ipc-using library
with no security audit that I could find with google.  A library for
which people do not seem to care about compatibility with previous or
future kernel versions, which means it _has_ to be shared.  And shared
libraries are just unacceptable in some contexts, like distributing
binaries outside of a specific linux distribution[1].

At least OSS, with all its flaws, is a documented kernel interface.
You can static link a oss-using program, whether it uses it directly
or through interfaces like sdl-audio, and it will just work.

  OG.

[1] And that does not necessarily means commercial and/or proprietary.
"Just recompile" does not always work either, think missing libraries,
headers, and version drift (snd_pcm_hw_params_set_rate_near anybody?).

(Continue reading)

headers

Jaroslav Kysela | 6 Jan 21:26

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

On Fri, 6 Jan 2006, Olivier Galibert wrote:

> On Fri, Jan 06, 2006 at 03:40:26AM +0100, Diego Calleja wrote:
> > Amazing - even windows is getting sound mixing out of the kernel
> > in windows vista because they've learnt (the hard way) that it's
> > the Right Thing and linux people is trying to get it in?
> 
> You misread.  Most people just want to have things work like they
> should have for years.  Technical people, at least Marcin and I, want
> a documented kernel interface with optional libraries over it (think
> libX11 vs. the X Protocol, or glibc/klibc/uclibc/libc5 vs. the system
> calls), and then behind that have the kernel route the data to
> userspace demon(s) or the hardware depending on root-level setup and
> configuration.

I got the point, but the audio is very specific that it requires realtime 
scheduling. Even graphics is not so tied with realtime, because a 
scheduling gap does not end with error or very ugly misbehaviour (pops) 
like in audio.

You're proposing to add more content switches versus current ALSA 
implementation:

user space <-> kernel

While your daemon requires:

user space <-> kernel <-> user space (daemon)

So your solution is even more realtime and proper scheduling dependant.

(Continue reading)

headers

Olivier Galibert | 7 Jan 01:56

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

On Fri, Jan 06, 2006 at 09:26:42PM +0100, Jaroslav Kysela wrote:
> You're proposing to add more content switches versus current ALSA 
> implementation:
> 
> user space <-> kernel
> 
> While your daemon requires:
> 
> user space <-> kernel <-> user space (daemon)

Dmix _is_ a context switch, you know?

> So your solution is even more realtime and proper scheduling dependant.
> Unfortunately, Linux kernels still do not have perfect realtime behaviour 
> (mostly due to broken drivers etc.).

You only get context switches if you go through plugins, which is
pretty much the same way alsa currently is, isn't it?

> Also, the API is completely irrelevant from this scheme. If daemon does 
> everything, the ALSA kernel API can go public and documented (altough I 
> still does not agree with it - see bellow).

The ALSA kernel API better go documented soon or I'll have to document
it myself.  Security and openness-wise, it is just not acceptable to
have a user-accessive kernel API kept under wraps.

> > ALSA does not have a documented kernel interface nor an optional
> > library but a mandatory library.  A highly complex, ipc-using library
>

(Continue reading)

headers

Olivier Galibert | 7 Jan 01:56

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

On Fri, Jan 06, 2006 at 09:26:42PM +0100, Jaroslav Kysela wrote:
> You're proposing to add more content switches versus current ALSA 
> implementation:
> 
> user space <-> kernel
> 
> While your daemon requires:
> 
> user space <-> kernel <-> user space (daemon)

Dmix _is_ a context switch, you know?

> So your solution is even more realtime and proper scheduling dependant.
> Unfortunately, Linux kernels still do not have perfect realtime behaviour 
> (mostly due to broken drivers etc.).

You only get context switches if you go through plugins, which is
pretty much the same way alsa currently is, isn't it?

> Also, the API is completely irrelevant from this scheme. If daemon does 
> everything, the ALSA kernel API can go public and documented (altough I 
> still does not agree with it - see bellow).

The ALSA kernel API better go documented soon or I'll have to document
it myself.  Security and openness-wise, it is just not acceptable to
have a user-accessive kernel API kept under wraps.

> > ALSA does not have a documented kernel interface nor an optional
> > library but a mandatory library.  A highly complex, ipc-using library
>

(Continue reading)

headers

Marcin Dalecki | 7 Jan 01:40

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

On 2006-01-06, at 21:26, Jaroslav Kysela wrote:
>
> I got the point, but the audio is very specific that it requires  
> realtime
> scheduling. Even graphics is not so tied with realtime, because a
> scheduling gap does not end with error or very ugly misbehaviour  
> (pops)
> like in audio.

Nonsense. You just got too used to utterly bad behavior imposed by  
the inherently defective
X11 graphics system. Like stuttering mouse movements. Like race  
conditions between popup menus
and background menus and so on and so forth... Hick-ups when suddenly  
the system starts to do some paging...
More staggering examples simply don't occur that obviously in praxis  
because the interface
designers refrain from using some effects like subtly animated icon  
change and menu animations
redrawing. But it's by no way an argument which could be used to  
justify the deficiency of
some audio system. And BTW. A proper user interface system requires  
synchronization between
audio and video.

So there you are - all over the pill - soft real time requirements.  
Actually not that soft at all.
It always surprises me how efficient and demanding the perceptive  
system of a hunter and

(Continue reading)

headers

Lee Revell | 5 Jan 21:05

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

On Thu, 2006-01-05 at 21:03 +0100, Marcin Dalecki wrote:
> On 2006-01-05, at 19:33, Lee Revell wrote:
> 
> > On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
> >> Second - you still didn't explain why this allows you to conclude
> >> that sound mixing should in no way be done inside the kernel.
> >
> > It works perfectly right now in userspace.
> 
> Yeah - for you maybe...
> 

Please rephrase your comment in the form of a useful bug report.

Lee

-
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

headers

Marcin Dalecki | 5 Jan 21:18

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

On 2006-01-05, at 21:05, Lee Revell wrote:

> On Thu, 2006-01-05 at 21:03 +0100, Marcin Dalecki wrote:
>> On 2006-01-05, at 19:33, Lee Revell wrote:
>>
>>> On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
>>>> Second - you still didn't explain why this allows you to conclude
>>>> that sound mixing should in no way be done inside the kernel.
>>>
>>> It works perfectly right now in userspace.
>>
>> Yeah - for you maybe...
>>
>
> Please rephrase your comment in the form of a useful bug report.

Yes I will. But only after you stop spreading BS about how fine and
generally dandy the situation about sound support in Linux is thanks  
to ALSA.
One reports bugs only if one expects that the situation will improve.
Glaring problems on average commodity hardware one expect the  
developers to take
care of without any notice.

However since the beginning the situation with ALSA has always been a  
lot of
advertisement how well it will work but the results where always less  
then stellar
if one looked at them from the functional side.

(Continue reading)

headers

Lee Revell | 5 Jan 21:32

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

On Thu, 2006-01-05 at 21:18 +0100, Marcin Dalecki wrote:
> Glaring problems on average commodity hardware

A good first step would be to mention which driver, ALSA version and
soundcard you are using.

Lee

-
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

headers

Marcin Dalecki | 5 Jan 21:54

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


On 2006-01-05, at 21:32, Lee Revell wrote:

> On Thu, 2006-01-05 at 21:18 +0100, Marcin Dalecki wrote:
>> Glaring problems on average commodity hardware
>
> A good first step would be to mention which driver, ALSA version and
> soundcard you are using.

I will do you this favor: NONE. Using something implies that it is  
working.

-
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

headers

Jesper Juhl | 6 Jan 00:35

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

On 1/5/06, Marcin Dalecki <martin <at> dalecki.de> wrote:
>
> On 2006-01-05, at 21:32, Lee Revell wrote:
>
> > On Thu, 2006-01-05 at 21:18 +0100, Marcin Dalecki wrote:
> >> Glaring problems on average commodity hardware
> >
> > A good first step would be to mention which driver, ALSA version and
> > soundcard you are using.
>
> I will do you this favor: NONE. Using something implies that it is
> working.
>
Do you really expect your problems to be solved with that attitude?

If you want problems in Linux/ALSA/Open Source software in general,
you need to *SEND USEFUL BUGREPORTS AND WORK WITH THE DEVELOPERS TO
GET IT FIXED*

Replies like the one you just send gets you absolutely nowhere, or
even worse it may land whatever problem you are experiencing at the
bottom of the developers TODO list unless other people (that can be
worked with) also have the same problem.

You just demonstrated a very efficient way to *NOT* get your problem fixed.

--
Jesper Juhl <jesper.juhl <at> 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

(Continue reading)

headers

Marcin Dalecki | 6 Jan 01:04

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

On 2006-01-06, at 00:35, Jesper Juhl wrote:

>>
>> I will do you this favor: NONE. Using something implies that it is
>> working.
>>
> Do you really expect your problems to be solved with that attitude?

No I do not. How do you dare to assume I do?
I never ever did ask for any support on behalf of the ALSA bunch...
We are just discussing the merits of one sound system design
over another one (without design).

So please just keep your superstitions for yourself.

-
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

headers

Hannu Savolainen | 6 Jan 02:36

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

On Fri, 6 Jan 2006, Marcin Dalecki wrote:

> 
> 
> No I do not. How do you dare to assume I do?
> I never ever did ask for any support on behalf of the ALSA bunch...
> We are just discussing the merits of one sound system design
> over another one (without design).
Which is really a good subject to discuss about (LKML may not be the right 
place for this). ALSA has been in the official kernel for two years now so 
might this be a good time to look back?

There are two very opposite approaches to do a sound subsystem. The ALSA 
way is to expose every single detail of the hardware to the applications 
and to allow (or force) application developers to deal with them. The OSS 
approach is to provide maximum device abstraction in the API level (by 
isolating the apps from the hardware as much as practically possible).

Both ways have their good and bad sides. During past years the ALSA 
advocates have been dictating that the ALSA approach is the only available 
way to go (all resistance is futile). But after all what is the authority 
who makes the final decision? Is it the ALSA team (who would like to think 
in this way)? Or do the Linux/Unix users and audio application developers 
have any word to say?

Btw, about the current OSS drivers in the kernel. They are really obsolete 
because they are based on some 10 years old API version. For this reason 
it's necessary to remove them in the nearish future (maybe at the same 
time when we release the OpenOSS version). Comparing ALSA against the 
kernel OSS drivers is pointless because current OSS has very little

(Continue reading)

headers

Takashi Iwai | 7 Jan 15:09

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

At Fri, 6 Jan 2006 03:36:47 +0200 (EET),
Hannu Savolainen wrote:
> 
> On Fri, 6 Jan 2006, Marcin Dalecki wrote:
> 
> > 
> > 
> > No I do not. How do you dare to assume I do?
> > I never ever did ask for any support on behalf of the ALSA bunch...
> > We are just discussing the merits of one sound system design
> > over another one (without design).
> Which is really a good subject to discuss about (LKML may not be the right 
> place for this). ALSA has been in the official kernel for two years now so 
> might this be a good time to look back?
> 
> There are two very opposite approaches to do a sound subsystem. The ALSA 
> way is to expose every single detail of the hardware to the applications 
> and to allow (or force) application developers to deal with them. The OSS 
> approach is to provide maximum device abstraction in the API level (by 
> isolating the apps from the hardware as much as practically possible).

Agreed, it's a good point.

Note that for long time, I've commented that I myself do _not_
recommend to use ALSA API directly with apps.  Rather I've recommended
to use other portable libraries with ALSA/other backends.  Writing an
app with alsa-lib is just like to write a graphical program with X11
lowlevel library without any toolkits...

> Both ways have their good and bad sides. During past years the ALSA

(Continue reading)

headers

Hannu Savolainen | 8 Jan 01:21

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

On Sat, 7 Jan 2006, Takashi Iwai wrote:

> > There are two very opposite approaches to do a sound subsystem. The ALSA 
> > way is to expose every single detail of the hardware to the applications 
> > and to allow (or force) application developers to deal with them. The OSS 
> > approach is to provide maximum device abstraction in the API level (by 
> > isolating the apps from the hardware as much as practically possible).
> 
> Agreed, it's a good point.
> 
> Note that for long time, I've commented that I myself do _not_
> recommend to use ALSA API directly with apps.  Rather I've recommended
> to use other portable libraries with ALSA/other backends.  Writing an
> app with alsa-lib is just like to write a graphical program with X11
> lowlevel library without any toolkits...
Takashi, I knew you are smart enough to realize this. What is needed at 
the kernel level is a driver API that is strong enough to provide all the 
functionality needed to implement good user land libraries (including 
alsa-lib). At the same time the kernel API itself should be  suitable to 
be used in mainline applications. At this moment Jack is already used by 
most high end Linux sound apps which is good approach.

> > Both ways have their good and bad sides. During past years the ALSA 
> > advocates have been dictating that the ALSA approach is the only available 
> > way to go (all resistance is futile).
> 
> Heh, it's natural that developers think their own things work better
> :)
This is natural and acceptable. What is not acceptable is that 1000's of 
existing applications are forced to be converted to use some new API

(Continue reading)

headers

Marcin Dalecki | 7 Jan 15:57

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

On 2006-01-07, at 15:09, Takashi Iwai wrote:
>
> In the implementation of OSS API, there is a clear bottleneck: you
> have to implement everthing in the kernel level because of its
> definition.  Remember that the original thread started from the
> reduction of the kernel codes.  Putting more stuff which could be done
> better in user-space is a major drawback, IMO.

One point - there isn't that much to be done inside the kernel for  
the realm
of a generic sound driver. Not if you compare it with other sub  
systems like the SCSI host
controller layer or WiFi protocols for example. BTW. By your argument  
the encryption doesn't
belong in to the kernel as well. In fact one should go even further  
and compare sound
facilities with the *whole* block device layer for example. Mixing  
and *even* resampling
data streams are quite formidable tasks from an algorithmic point of  
view if done properly and not just applying the square transformation  
window as in simple averaging methods one encounters so frequently!.
However let me assure you that it would by no way result in that many  
code lines as in
typical decisive protocol code implementations.

A whole complex cross correlation containing a butterfly FFT core for  
example doesn't take
much more then just about 500 lines of C code. And it's FAST.  
Basically hitting DRAM speed.

(Continue reading)

headers

Gabor Gombas | 6 Jan 11:34

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

On Fri, Jan 06, 2006 at 03:36:47AM +0200, Hannu Savolainen wrote:

> There are two very opposite approaches to do a sound subsystem. The ALSA 
> way is to expose every single detail of the hardware to the applications 
> and to allow (or force) application developers to deal with them. The OSS 
> approach is to provide maximum device abstraction in the API level (by 
> isolating the apps from the hardware as much as practically possible).

Well, then it is quite clear to me: you can build an OSS-like interface
on top of ALSA, but you cannot build an ALSA-like interface on top of
OSS. This implies that an ALSA-like interface should be in the kernel,
and an OSS-like interface should be implemented on top of it in
userspace for those who do not need all the features. This way both
camps are satisfied.

Gabor

--

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------
-
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

headers

Hannu Savolainen | 6 Jan 13:48

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

On Fri, 6 Jan 2006, Gabor Gombas wrote:

> On Fri, Jan 06, 2006 at 03:36:47AM +0200, Hannu Savolainen wrote:
> 
> > There are two very opposite approaches to do a sound subsystem. The ALSA 
> > way is to expose every single detail of the hardware to the applications 
> > and to allow (or force) application developers to deal with them. The OSS 
> > approach is to provide maximum device abstraction in the API level (by 
> > isolating the apps from the hardware as much as practically possible).
> 
> Well, then it is quite clear to me: you can build an OSS-like interface
> on top of ALSA, but you cannot build an ALSA-like interface on top of
> OSS.
This is not entirely correct. An alsa-lib compatible library can be 
implemented on top of OSS. It has already been done up to some degree for 
the audio and mixer parts (sequencer/MIDI support is under work just now).

I agree this is bit inpractical solution since ALSA has some 1500 library 
functions (and more to be added in the future). It is very difficult to 
test such library because just a limited subset of them has been used by 
any of the ALSA apps we were able to get working. In fact it looks like 
two ALSA apps (for similar purpose) may have been implemented using very 
different sets of ALSA functions (with relatively small overlap).

> This implies that an ALSA-like interface should be in the kernel,
> and an OSS-like interface should be implemented on top of it in
> userspace for those who do not need all the features. This way both
> camps are satisfied.
Or full ALSA library could be implemented on top of the OSS drivers. Or 
OSS can be modified to support ALSA's kernel level driver interface (which

(Continue reading)

headers

James Courtier-Dutton | 6 Jan 10:54

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

Hannu Savolainen wrote:
> 
> Btw, about the current OSS drivers in the kernel. They are really obsolete 
> because they are based on some 10 years old API version. For this reason 
> it's necessary to remove them in the nearish future (maybe at the same 
> time when we release the OpenOSS version). Comparing ALSA against the 
> kernel OSS drivers is pointless because current OSS has very little 
> common with that code.

Hannu,

This is the LKML. So, we are considering KERNEL code. Not some external 
binary blob. We are therefore suggesting to remove the kernel OSS 
drivers as that is all we have to compare with ALSA.
We can't compare a binary blob with open source as the binary blob will 
never be part of mainline.
Even you admit that the OSS drivers in the kernel mainline are "really 
obsolete", so you must agree with this thread that we should remove them.

Only if your binary blobs are released as GPL so that they can be 
included in mainline can it really be any use to discuss them.

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

headers

Hannu Savolainen | 6 Jan 14:37

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

On Fri, 6 Jan 2006, James Courtier-Dutton wrote:
> Even you admit that the OSS drivers in the kernel mainline are "really
> obsolete", so you must agree with this thread that we should remove them.
I completely agree. As I said I would like to see the old OSS code to be 
removed from the kernel soon.

> Only if your binary blobs are released as GPL so that they can be included in
> mainline can it really be any use to discuss them.
We are planning to release OSS under some open source license (not GPL).
However it will be released and built outside the Linux kernel source tree 
(mostly because the same code has to work with several other operating 
system).

Best regards,

Hannu
-----
Hannu Savolainen (hannu <at> opensound.com)
http://www.opensound.com (Open Sound System (OSS))
http://www.compusonic.fi (Finnish OSS pages)
OH2GLH QTH: Karkkila, Finland LOC: KP20CM
-
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

headers

Jesper Juhl | 6 Jan 01:08

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

On 1/6/06, Marcin Dalecki <martin <at> dalecki.de> wrote:
>
> On 2006-01-06, at 00:35, Jesper Juhl wrote:
>
> >>
> >> I will do you this favor: NONE. Using something implies that it is
> >> working.
> >>
> > Do you really expect your problems to be solved with that attitude?
>
> No I do not. How do you dare to assume I do?
> I never ever did ask for any support on behalf of the ALSA bunch...
> We are just discussing the merits of one sound system design
> over another one (without design).
>
> So please just keep your superstitions for yourself.
>

welcome to my killfile

--
Jesper Juhl <jesper.juhl <at> 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
-
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)

headers

Lee Revell | 5 Jan 22:01

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

On Thu, 2006-01-05 at 21:54 +0100, Marcin Dalecki wrote:
> On 2006-01-05, at 21:32, Lee Revell wrote:
> 
> > On Thu, 2006-01-05 at 21:18 +0100, Marcin Dalecki wrote:
> >> Glaring problems on average commodity hardware
> >
> > A good first step would be to mention which driver, ALSA version and
> > soundcard you are using.
> 
> I will do you this favor: NONE. Using something implies that it is  
> working.
> 

Are you going to fucking help or should I just killfile you now?

Lee

-
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

headers

Marcin Dalecki | 5 Jan 22:43

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

On 2006-01-05, at 22:01, Lee Revell wrote:

> On Thu, 2006-01-05 at 21:54 +0100, Marcin Dalecki wrote:
>> On 2006-01-05, at 21:32, Lee Revell wrote:
>>
>>> On Thu, 2006-01-05 at 21:18 +0100, Marcin Dalecki wrote:
>>>> Glaring problems on average commodity hardware
>>>
>>> A good first step would be to mention which driver, ALSA version and
>>> soundcard you are using.
>>
>> I will do you this favor: NONE. Using something implies that it is
>> working.
>
> Are you going to fucking help or should I just killfile you now?

It's not about helping ALSA here it's about not throwing out the window
a system which has the advantage of actually working.
-
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

headers

Lee Revell | 5 Jan 22:47

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

On Thu, 2006-01-05 at 22:43 +0100, Marcin Dalecki wrote:
> On 2006-01-05, at 22:01, Lee Revell wrote:
> 
> > On Thu, 2006-01-05 at 21:54 +0100, Marcin Dalecki wrote:
> >> On 2006-01-05, at 21:32, Lee Revell wrote:
> >>
> >>> On Thu, 2006-01-05 at 21:18 +0100, Marcin Dalecki wrote:
> >>>> Glaring problems on average commodity hardware
> >>>
> >>> A good first step would be to mention which driver, ALSA version and
> >>> soundcard you are using.
> >>
> >> I will do you this favor: NONE. Using something implies that it is
> >> working.
> >
> > Are you going to fucking help or should I just killfile you now?
> 
> It's not about helping ALSA here it's about not throwing out the window
> a system which has the advantage of actually working.
> 

OK, sorry you feel that way.  Get back to me when you're willing to help
fix the problem.

Lee

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

headers

Lee Revell | 5 Jan 21:28

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

On Thu, 2006-01-05 at 21:18 +0100, Marcin Dalecki wrote:
> On 2006-01-05, at 21:05, Lee Revell wrote:
> 
> > On Thu, 2006-01-05 at 21:03 +0100, Marcin Dalecki wrote:
> >> On 2006-01-05, at 19:33, Lee Revell wrote:
> >>
> >>> On Thu, 2006-01-05 at 13:44 +0100, Marcin Dalecki wrote:
> >>>> Second - you still didn't explain why this allows you to conclude
> >>>> that sound mixing should in no way be done inside the kernel.
> >>>
> >>> It works perfectly right now in userspace.
> >>
> >> Yeah - for you maybe...
> >>
> >
> > Please rephrase your comment in the form of a useful bug report.
> 
> Yes I will. But only after you stop spreading BS about how fine and
> generally dandy the situation about sound support in Linux is thanks  
> to ALSA.

I'm not spreading BS, I'm trying to identify the real problems and get
them fixed.  Unfortunately people like to bitch and moan a lot more than
they like to report bugs.

> One reports bugs only if one expects that the situation will improve.

Um, look at the alsa-devel archives or the ALSA CVS commit mailing list.
We close dozens of bugs each week.  I personally closed more than 50
last week (most had been fixed months ago).  90% of ALSA development

(Continue reading)

headers

Marcin Dalecki | 5 Jan 21:32

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

On 2006-01-05, at 21:28, Lee Revell wrote:

> We close dozens of bugs each week.  I personally closed more than 50
> last week (most had been fixed months ago).  90% of ALSA development
> happens through the bug tracker.

...

> Check out the linux-audio-dev and linux-audio-user archives.  ALSA has
> been working perfectly for all of those users for years.

You are aware of how self contradicting this sounds?!
-
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

headers

Lee Revell | 5 Jan 21:39

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

On Thu, 2006-01-05 at 21:32 +0100, Marcin Dalecki wrote:
> On 2006-01-05, at 21:28, Lee Revell wrote:
> 
> > We close dozens of bugs each week.  I personally closed more than 50
> > last week (most had been fixed months ago).  90% of ALSA development
> > happens through the bug tracker.
> 
> ...
> 
> > Check out the linux-audio-dev and linux-audio-user archives.  ALSA has
> > been working perfectly for all of those users for years.
> 
> You are aware of how self contradicting this sounds?!
> 

Not at all.  By "working perfectly" I obviously didn't mean that ALSA
hasn't had a bug in years - I meant that when we DO get an actionable
bug report we fix it.

Lee

-
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

headers

Lee Revell | 3 Jan 19:28

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

On Tue, 2006-01-03 at 18:03 +0100, Olivier Galibert wrote:
> On Tue, Jan 03, 2006 at 04:29:21PM +0000, Alistair John Strachan wrote:
> > This has nothing to do with the kernel option CONFIG_SND_OSSEMUL which Jan 
> > referred to, and to which I was responding. "aoss" is also not compatible 
> > with every conceivable program.
> 
> Especially not with plugins.  Flashplayer anybody?

Yes it's a known issue that the aoss emulation is not perfect, it's not
a reason to ditch ALSA, it's a reason to fix it.

Please provide a reproducible test case where an app *that we have the
source code for* works with native OSS or the in kernel /dev/dsp OSS
emulation and fails with the aoss/alsa-lib/userspace OSS emulation and
it will be fixed ASAP.

Lee

-
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

headers

Thomas Sailer | 3 Jan 20:30

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

On Tue, 2006-01-03 at 13:28 -0500, Lee Revell wrote:

> Please provide a reproducible test case where an app *that we have the
> source code for* works with native OSS or the in kernel /dev/dsp OSS
> emulation and fails with the aoss/alsa-lib/userspace OSS emulation and
> it will be fixed ASAP.

I didn't know AOSS, but http://www.baycom.org/~tom/ham/soundmodem/ fails
with ALSA's kernel OSS emulation. Given that ALSA's kernel OSS emulation
is buggy since a couple of years and nobody feels like fixing it and you
seem to be telling that aoss is better anyway, are we going to remove
snd_pcm_oss as well?

Tom

headers

Jaroslav Kysela | 3 Jan 20:37

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

On Tue, 3 Jan 2006, Thomas Sailer wrote:

> On Tue, 2006-01-03 at 13:28 -0500, Lee Revell wrote:
> 
> > Please provide a reproducible test case where an app *that we have the
> > source code for* works with native OSS or the in kernel /dev/dsp OSS
> > emulation and fails with the aoss/alsa-lib/userspace OSS emulation and
> > it will be fixed ASAP.
> 
> I didn't know AOSS, but http://www.baycom.org/~tom/ham/soundmodem/ fails
> with ALSA's kernel OSS emulation.

Anyone reported that? Also what's the exact bug symptom?

						Jaroslav

-----
Jaroslav Kysela <perex <at> suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs

headers

Thomas Sailer | 3 Jan 20:56

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

On Tue, 2006-01-03 at 20:37 +0100, Jaroslav Kysela wrote:

> Anyone reported that? Also what's the exact bug symptom?

Many people reported this on various mailing lists, but I'm not aware of
any bugzilla/whatever ticket.

Problem seems to be that ALSA/OSS does not report the true HW sampling
rate, but tries to do the sample rate conversion by itself, but
apparently not doing it good enough for modem type applications.

Anyway I find it not a good idea of alsa to try to do sample rate
conversion in kernel for OSS, as the native OSS drivers never did this,
and it is useless for software (like soundmodem) that tries to find out
the hardware rates in order to adapt to them. Kernel resampling badly
interferes with this.

Tom

PS: I was too lazy to investigate this in depth, it was easier to just
add a native ALSA driver to soundmodem.

headers

James Courtier-Dutton | 3 Jan 23:39

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

Thomas Sailer wrote:
> On Tue, 2006-01-03 at 20:37 +0100, Jaroslav Kysela wrote:
> 
> 
>>Anyone reported that? Also what's the exact bug symptom?
> 
> 
> Many people reported this on various mailing lists, but I'm not aware of
> any bugzilla/whatever ticket.
> 
> Problem seems to be that ALSA/OSS does not report the true HW sampling
> rate, but tries to do the sample rate conversion by itself, but
> apparently not doing it good enough for modem type applications.
> 
> Anyway I find it not a good idea of alsa to try to do sample rate
> conversion in kernel for OSS, as the native OSS drivers never did this,
> and it is useless for software (like soundmodem) that tries to find out
> the hardware rates in order to adapt to them. Kernel resampling badly
> interferes with this.
> 
> Tom
> 
> PS: I was too lazy to investigate this in depth, it was easier to just
> add a native ALSA driver to soundmodem.
> 

You can switch off ALSA's sample rate converter with a line like the 
following:
err = snd_pcm_hw_params_set_rate_resample(this->audio_fd, params, 0);

(Continue reading)

headers

Jaroslav Kysela | 3 Jan 21:06

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

On Tue, 3 Jan 2006, Thomas Sailer wrote:

> On Tue, 2006-01-03 at 20:37 +0100, Jaroslav Kysela wrote:
> 
> > Anyone reported that? Also what's the exact bug symptom?
> 
> Many people reported this on various mailing lists, but I'm not aware of
> any bugzilla/whatever ticket.
> 
> Problem seems to be that ALSA/OSS does not report the true HW sampling
> rate, but tries to do the sample rate conversion by itself, but
> apparently not doing it good enough for modem type applications.

The "plugin" (or rather conversion, routing and resampling) system in the 
OSS emulation can be turned off using the proc interface:

echo "soundmodem 0 0 direct" > /proc/asound/card0/pcm0p/oss
echo "soundmodem 0 0 direct" > /proc/asound/card0/pcm0c/oss

Full documentation is available at:

linux/Documentation/sound/alsa/OSS-Emulation.txt

It's easy to remove the "additional" functionality, but I bet that we
find some users requesting it. Also, in time when the OSS emulation was 
designed, not all OSS applications had own resapling code.

						Jaroslav

-----

(Continue reading)

headers

Thomas Sailer | 4 Jan 01:23

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

On Tue, 2006-01-03 at 21:06 +0100, Jaroslav Kysela wrote:

> The "plugin" (or rather conversion, routing and resampling) system in the 
> OSS emulation can be turned off using the proc interface:

Hm. IMO by including resampling and format conversion you're trying to
"unbreak" broken OSS apps in the kernel. And by having this on by
default you're rewarding writers of broken OSS apps while punishing
those that write correct apps...

But this is a sidetrack. Even though it's not optimal from the CPU usage
point of view to have two sampling rate converters in sequence, and
apart from the SNR loss by the overly simplistic linear interpolator,
soundmodem should still work with ALSA's OSS emulation. But it doesn't.
Well, it almost does: only every tenth or so bit is incorrect (which is
inacceptable for a modem, though). This leads me to suspect there's
something else wrong with the sample rate converter.

In sound/core/oss/rate.c, resample_expand, line 111:
if (src_frames1-- > 0) {

What is this test for? Similar code is also in resample_shrink.

Either it's never false, or I know why modem apps don't work with it: it
would be "inventing samples out of the blue", thereby adding lots of
jitter to the time axis...

Tom

(Continue reading)

headers

Alistair John Strachan | 3 Jan 18:16

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

On Tuesday 03 January 2006 17:03, Olivier Galibert wrote:
> On Tue, Jan 03, 2006 at 04:29:21PM +0000, Alistair John Strachan wrote:
> > This has nothing to do with the kernel option CONFIG_SND_OSSEMUL which
> > Jan referred to, and to which I was responding. "aoss" is also not
> > compatible with every conceivable program.
>
> Especially not with plugins.  Flashplayer anybody?

Konqueror manages to "wrap" plugins quite happily.. complain to whoever makes 
your browser.

> > This is exactly why the OSS emulation option in ALSA is really a last
> > resort and should not be an excuse for people to ignore implementing ALSA
> > support directly. More so, it is very good justification for ditching
> > "everything OSS" as soon as possible, at least in new software.
>
> Actually the crappy state of OSS emulation is a good reason to ditch
> ALSA in its current implementation.  As Linus reminded not so long
> ago, backwards compatibility is extremely important.

This argument is basically watered down with devfs, udev, sysfs, etc. which 
all have exactly the same issues. Should a crippled OSS API be the way 
forward for Linux? I think not.

> Also, not everybody wants to depend on a shared library.  I find this
> "the alsa lib must be kept in lockstep with the kernel version" quite
> annoying.  I'd rather not have the windows dll hell on linux, TYVM.
> Or in other words, the public API of a kernel interface should _NEVER_
> be a library only.  At least OSS, with all its issues, had that right.

(Continue reading)

headers

Olivier Galibert | 3 Jan 20:24

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

On Tue, Jan 03, 2006 at 05:16:13PM +0000, Alistair John Strachan wrote:
> This argument is basically watered down with devfs, udev, sysfs, etc. which 
> all have exactly the same issues. Should a crippled OSS API be the way 
> forward for Linux? I think not.

And they're getting some real backlash because of that now.  Hell,
Linus' message was about udev in the first place.

As for the OSS API being crippled, I'd take the 3 ioctl calls you need
to setup a simple stereo 16bits output with OSS than the 13 ALSA
library calls anyday.  Especially with the impressive lack of
documentation you get about what the hell is a period, or what you can
do except aborting when you get an error.

> > Also, not everybody wants to depend on a shared library.  I find this
> > "the alsa lib must be kept in lockstep with the kernel version" quite
> > annoying.  I'd rather not have the windows dll hell on linux, TYVM.
> > Or in other words, the public API of a kernel interface should _NEVER_
> > be a library only.  At least OSS, with all its issues, had that right.
> 
> Okay, I agree it's not ideal. But if you want software mixing, and it's a 
> genuinely useful feature, you either have to go down the road of running some 
> crappy daemon like arts or esound, or just link against libasound and get it 
> for free. I know I'd rather not have mixing routines in my kernel, thanks.

Duh, then don't put the mixing in the kernel, put the data routing
there.  That's a large part of what the kernel is about, moving data
around, and Linus' new magic pipes are perfect for that kind of use.

Then at system startup and through udev you can start whatever mixers,

(Continue reading)

headers

James Courtier-Dutton | 3 Jan 23:33

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

Olivier Galibert wrote:
> 
> As for the OSS API being crippled, I'd take the 3 ioctl calls you need
> to setup a simple stereo 16bits output with OSS than the 13 ALSA
> library calls anyday.  Especially with the impressive lack of
> documentation you get about what the hell is a period, or what you can
> do except aborting when you get an error.
> 

There is perfectly good documentation. You just have not bothered to 
look at it.
The ALSA api is good enough so you can actually decide what happens when 
you get an error. e.g. an over or under run. You can tell ALSA to stop 
the stream, or you can tell is to continue on just using silence frames 
until you send it some new sounds.
The OSS API cannot achieve that.

James

P.S. Sorry, but I had to wipe all the cross posting addresses.

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

headers

Olivier Galibert | 4 Jan 02:28

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

On Tue, Jan 03, 2006 at 10:33:33PM +0000, James Courtier-Dutton wrote:
> Olivier Galibert wrote:
> >
> >As for the OSS API being crippled, I'd take the 3 ioctl calls you need
> >to setup a simple stereo 16bits output with OSS than the 13 ALSA
> >library calls anyday.  Especially with the impressive lack of
> >documentation you get about what the hell is a period, or what you can
> >do except aborting when you get an error.
> >
> 
> There is perfectly good documentation. You just have not bothered to 
> look at it.

Really?  Did you try finding documentation for the simple problem that
is playing dynamically generated stereo with minimum latency recently?
Because I did.  Hey, let's have fun and try it again.

Start with "alsa" is google, you find www.alsa-project.org.  Good
start.  Then you go to documentation.

Ok, let's check:

- Background info.... nah, no background info in there, only PR about
  why it's so much cooler that OSS.  Uninteresting.

- Tutorials.  Too bad they're all about 0.9, so they don't compile
  anymore.  At least they give a start, even if I'd loved to have an
  explanation of why there is writen and writei when there is
  set_access.  And they have zero information about error handling, or
  what the hell a period is (somthing like a buffer size?) or what is

(Continue reading)

headers

Hannu Savolainen | 4 Jan 00:41

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

On Tue, 3 Jan 2006, James Courtier-Dutton wrote:

> The ALSA api is good enough so you can actually decide what happens when you
> get an error. e.g. an over or under run. You can tell ALSA to stop the stream,
> or you can tell is to continue on just using silence frames until you send it
> some new sounds.
> The OSS API cannot achieve that.
I would not say it in this way. I have intentionally left this kind of 
stuff of minimal or no importance out from the OSS API. This decision was 
made more than 10 years ago and it's still valid. In practice it 
will not take more than few hours to add this kind of interface to the 
API but I have no intention to do it. 

The cruel fact is that the application has already failed it it causes an 
overrun/underrun. There is an audible defect in the output or some 
recording data has been lost forever. There is no way to recover the 
error afterwards. So why to waste application programmer's time and 
energy with API features that can't work anyway. 

If an application has timing problems then it's better to force the 
programmer to fix the application design issues. For this reason OSS 
handles underruns in the simpliest possible way (by adding a full 
fragment of silence). This makes xruns clearly audible which in turn 
takes care that the problem will get noticed. 

With sophisticated application/driver interaction it may be possible to 
make the xrun defects almost unaudible but so what. OSS is designed for 
software professionals who do _NOT_ release applications that don't work 
correctly in the given environment.

(Continue reading)

headers

Lee Revell | 5 Jan 07:42

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

On Tue, 2006-01-03 at 20:24 +0100, Olivier Galibert wrote:
> As for the OSS API being crippled, I'd take the 3 ioctl calls you need
> to setup a simple stereo 16bits output with OSS than the 13 ALSA
> library calls anyday.  Especially with the impressive lack of
> documentation you get about what the hell is a period, or what you can
> do except aborting when you get an error. 

Same thing as a fragment in OSS.  It's the number of frames between
interrupts from the audio interface.

Come on, Google could have told you that in 5 seconds.

Lee

-
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

headers

Adrian Bunk | 3 Jan 20:37

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

On Tue, Jan 03, 2006 at 08:24:49PM +0100, Olivier Galibert wrote:
> On Tue, Jan 03, 2006 at 05:16:13PM +0000, Alistair John Strachan wrote:
> > This argument is basically watered down with devfs, udev, sysfs, etc. which 
> > all have exactly the same issues. Should a crippled OSS API be the way 
> > forward for Linux? I think not.
> 
> And they're getting some real backlash because of that now.  Hell,
> Linus' message was about udev in the first place.

The udev breakages might not have been nice, but OSS/ALSA is a 
completely different issue:

OSS has been deprecated since ALSA was merged into the Linux kernel 
_four years ago_.

And I'm only talking about removing drivers _with ALSA drivers for the 
same hardware available_.

> As for the OSS API being crippled, I'd take the 3 ioctl calls you need
> to setup a simple stereo 16bits output with OSS than the 13 ALSA
> library calls anyday.  Especially with the impressive lack of
> documentation you get about what the hell is a period, or what you can
> do except aborting when you get an error.
>...

For a general OSS<->ALSA discussion, you are five years too late.

>   OG.

cu

(Continue reading)

headers

Tomasz Kłoczko | 4 Jan 00:10

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

On Tue, 3 Jan 2006, Adrian Bunk wrote:

> On Tue, Jan 03, 2006 at 08:24:49PM +0100, Olivier Galibert wrote:
>> On Tue, Jan 03, 2006 at 05:16:13PM +0000, Alistair John Strachan wrote:
>>> This argument is basically watered down with devfs, udev, sysfs, etc. which
>>> all have exactly the same issues. Should a crippled OSS API be the way
>>> forward for Linux? I think not.
>>
>> And they're getting some real backlash because of that now.  Hell,
>> Linus' message was about udev in the first place.
>
> The udev breakages might not have been nice, but OSS/ALSA is a
> completely different issue:
>
> OSS has been deprecated since ALSA was merged into the Linux kernel
> _four years ago_.

Also more than four years exist another thing: generaly sound suport in 
Linux kernel is broken by design. Points where it is broken:

1) ALSA API forces not use devices files and many things on sound managing
   level are handled on user space library. This dissallow civilized
   redirection sound stream in runed application without this application
   interractions (try redirect sound stream on runed application for
   example to headset .. simple case skype .. oh you probaly don't know: in
   current ALSA infrastructure there is no civilized way for handle
   gadgests like BT headsets). In current ALSA API (IIRC) you must write in
   special way applications for handle this (look pint 2)).

2) ALSA API is to complicated: most applications opens single sound

(Continue reading)

headers

Joern Nettingsmeier | 4 Jan 13:13

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

Tomasz Kłoczko wrote:
> Also more than four years exist another thing: generaly sound suport
> in Linux kernel is broken by design. Points where it is broken:
> 
> 1) ALSA API forces not use devices files and many things on sound
> managing level are handled on user space library. This dissallow
<snip>
> 2) ALSA API is to complicated: most applications opens single sound 
> stream. All what system user expect it is plaing sound by more then
<snip>
> 3) ALSA kernel architecture is to complicated. This main reason why 
> configuring sound on Linux is SO COMPLICATED. From my system:
<snip>
> ALSA is also requires much more bigger code size than OSS variant 
> (count all snd* modules size, jackd and libasound and compare this
> with OSS modules and user space OSS library size). Simillar is on
<snip>

oh yeah. why is linux so fscking big? my olde msdos would fit on one 
floppy. whiiine.

what a load of crap. alsa is a serious architecture meant for serious, 
maximally efficient usage with all kinds of (wildly different) hardware.

desktop stuff and "you have mail" beeps are a fscking corner case.

this is like whining about the oh so complex networking infrastructure 
and iptables and constantly reminiscing how simple it used to be to set 
up a modem on /dev/ttyS0.

(Continue reading)

headers

Andi Kleen | 4 Jan 13:35

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

> desktop stuff and "you have mail" beeps are a fscking corner case.

Your "fscking corner case" is just all what 90+% of all users need
sound for.

> 
> this is like whining about the oh so complex networking infrastructure 
> and iptables and constantly reminiscing how simple it used to be to set 
> up a modem on /dev/ttyS0.

Can be nearly all CONFIGured out. With the removal of the sane
sound drivers that would be impossible though.

-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

headers

Jaroslav Kysela | 4 Jan 13:41

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

On Wed, 4 Jan 2006, Andi Kleen wrote:

> > this is like whining about the oh so complex networking infrastructure 
> > and iptables and constantly reminiscing how simple it used to be to set 
> > up a modem on /dev/ttyS0.
> 
> Can be nearly all CONFIGured out. With the removal of the sane
> sound drivers that would be impossible though.

The code reduction is possible also for the ALSA midlevel code.
For example, removing the verbose /proc support might save some bytes and 
so on.

						Jaroslav

-----
Jaroslav Kysela <perex <at> suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
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

headers

Alistair John Strachan | 4 Jan 18:31

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

On Wednesday 04 January 2006 12:41, Jaroslav Kysela wrote:
> On Wed, 4 Jan 2006, Andi Kleen wrote:
> > > this is like whining about the oh so complex networking infrastructure
> > > and iptables and constantly reminiscing how simple it used to be to set
> > > up a modem on /dev/ttyS0.
> >
> > Can be nearly all CONFIGured out. With the removal of the sane
> > sound drivers that would be impossible though.
>
> The code reduction is possible also for the ALSA midlevel code.
> For example, removing the verbose /proc support might save some bytes and
> so on.

But can more be done? Andi's not pointed anything out in particular (unless I 
am mistaken), but could more of ALSA be configurable, even if it is at the 
expense of userspace API features?

As has already been pointed out, individual ALSA drivers with comparable 
features tend themselves to be smaller than the original OSS ones. It's the 
ALSA infrastructure that comes at a cost, and surely not all if it is 
mandatory.

--

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-

(Continue reading)

headers

Takashi Iwai | 4 Jan 18:48

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

At Wed, 4 Jan 2006 17:31:18 +0000,
Alistair John Strachan wrote:
> 
> On Wednesday 04 January 2006 12:41, Jaroslav Kysela wrote:
> > On Wed, 4 Jan 2006, Andi Kleen wrote:
> > > > this is like whining about the oh so complex networking infrastructure
> > > > and iptables and constantly reminiscing how simple it used to be to set
> > > > up a modem on /dev/ttyS0.
> > >
> > > Can be nearly all CONFIGured out. With the removal of the sane
> > > sound drivers that would be impossible though.
> >
> > The code reduction is possible also for the ALSA midlevel code.
> > For example, removing the verbose /proc support might save some bytes and
> > so on.
> 
> But can more be done? Andi's not pointed anything out in particular (unless I 
> am mistaken), but could more of ALSA be configurable, even if it is at the 
> expense of userspace API features?

For example, we can make supported ac97 codecs selectable so that not
all codes are compiled in.  The middle layer may contain functions
which are not used by your drivers.  They can be reduced, too.

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

headers

Alistair John Strachan | 4 Jan 10:37

[OT] ALSA userspace API complexity

On Tuesday 03 January 2006 23:10, Tomasz Kłoczko wrote:
[snip]
>
> 2) ALSA API is to complicated: most applications opens single sound
>    stream.

FUD and nonsense. I've written many DSP applications and very often I can 
recycle the same code for use in them. Here's an example, abstracted, 
commented, handling errors from the subsystem, in just over 100 LOC.

http://devzero.co.uk/~alistair/alsa/

The API is really _only_ complicated because it expects you to set things OSS 
either can't handle or doesn't allow you to configure. Things that very often 
an application will eventually care about. All this for the sake of 5 minutes 
reading documentation, and each API call almost identical in design.

Personally, I found the lack of documentation for some of the setup API 
annoying, but it's since been rectified and each call is humanly 
understandable.

--

-- 
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in

(Continue reading)

headers

Jan Engelhardt | 4 Jan 10:03

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


> 2) ALSA API is to complicated: most applications opens single sound
> stream.

Seconded.

> 3) ALSA kernel architecture is to complicated. This main reason why
> configuring sound on Linux is SO COMPLICATED. From my system:
>
> # lsmod | grep ^snd | wc -l
> 19
>

Why would you, or the "Desktop User Joe" using Torvalds-advertised KDE,
care about how many modules are loaded?

Splitting code up to make things more modular is A Good Choice most
of the times. There is, however, one point in which you have reason:
if the overall modular structure is bigger than a mono one, then it's
indeed "complicated".

> ALSA is also requires much more bigger code size than OSS variant
> (count all snd* modules size, jackd and libasound and compare this with
> OSS modules and user space OSS library size). Simillar is on allocated
> memory in all system sound components.
>
jackd does not count - ALSA works without it.

> Many task switches incurred by the current ALSA architecture
> add quickly up to perceivalble deleys during processing. In many cases

(Continue reading)

headers

Thomas Sailer | 4 Jan 01:33

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

On Wed, 2006-01-04 at 00:10 +0100, Tomasz Kłoczko wrote:

> 1) ALSA API forces not use devices files and many things on sound managing
>    level are handled on user space library. This dissallow civilized

Huh? Why's that? Actually, I welcome that ALSA does quite a lot in
userspace, it could even do more. The whole format conversion and
sampling rate conversion has no business in the kernel, IMO.

> 2) ALSA API is to complicated: most applications opens single sound
>    stream.

Agreed. It took me quite some time to get my app ported, even though I
had lots of documentation and sample code...

> 3) ALSA kernel architecture is to complicated. This main reason why
>    configuring sound on Linux is SO COMPLICATED. From my system:

Also agreed. It is IMO the hardest kernel subsystem to read. Instead of
having control passing from VFS to driver and the driver calling core
library routines, control passes from VFS to alsa core, which is calling
lots of callbacks. It's a coding style that should be avoided, it makes
reading and understanding code extremely hard.

> 4) ALSA mixing model is UNSECURE by design because all mixing sound
>    streams (for example with diffrent sampling rates) are performed
>    in user space.

Why is that? Even with kernel space mixing, any application having
access to the soundcard can fuck up the output, so I don't see why the

(Continue reading)

headers

Olivier Galibert | 4 Jan 02:48

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

On Wed, Jan 04, 2006 at 01:33:27AM +0100, Thomas Sailer wrote:
> On Wed, 2006-01-04 at 00:10 +0100, Tomasz K?oczko wrote:
> 
> > 1) ALSA API forces not use devices files and many things on sound managing
> >    level are handled on user space library. This dissallow civilized
> 
> Huh? Why's that? Actually, I welcome that ALSA does quite a lot in
> userspace, it could even do more. The whole format conversion and
> sampling rate conversion has no business in the kernel, IMO.

Doing things in userspace does not necessarily mean doing them in a
library, especially when it is required that the library be shared,
also known as "things _will_ break".

Especially since it tends to hide the real, user-accessible kernel
interface which has very, very annoying security implications.  At
that point, the ALSA kernel-userspace interface seems entirely
un-reviewed by the kernel people who have an eye for race conditions,
wandering userland pointers, information leaks, out-of-range accesses
and this kind of things (no patches from Al Viro on alsa?) and that
does not really give me a warm and fuzzy feeling.  And even if it is
reviewed at time t, it looks like it may change anytime a driver
author thinks it would help.  Not good at all.

  OG.

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

headers

Olivier Galibert | 3 Jan 22:40

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

On Tue, Jan 03, 2006 at 08:37:36PM +0100, Adrian Bunk wrote:
> The udev breakages might not have been nice, but OSS/ALSA is a 
> completely different issue:
> 
> OSS has been deprecated since ALSA was merged into the Linux kernel 
> _four years ago_.

OSS _drivers_ yes, OSS _api_ no.

> And I'm only talking about removing drivers _with ALSA drivers for the 
> same hardware available_.

Sure, and I have no problem with that.  OTOH you'll notice that this
particular subthread was specifically about the OSS api, not the
drivers.

> For a general OSS<->ALSA discussion, you are five years too late.

I couldn't predict 5 years ago that the ALSA API quality would be
somewhat lacking.

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

headers

Andi Kleen | 3 Jan 14:52

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)

headers

Lee Revell | 3 Jan 19:24

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

On Tue, 2006-01-03 at 14:52 +0100, 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.

OSS can't do software mixing of multiple audio streams, it requires a
sound server to do this.  So IMHO the OSS approach causes more bloat on
the desktop.

Lee

-
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

headers

David Lang | 3 Jan 14:58

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

headers

Alistair John Strachan | 3 Jan 15:33

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)

headers

Alistair John Strachan | 3 Jan 15:34

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)

headers

Alistair John Strachan | 3 Jan 15:01

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)