OSS driver removal, 2nd round (v2)

OSS driver removal, 2nd round (v2)

[Adrian Bunk]

Now that I've sent the first round of actually removing the code for OSS 
drivers where ALSA drivers without regressions exist for the same 
hardware, it's time for a second round amongst the remaining drivers.


Removing OSS drivers where ALSA drivers for the same hardware exists has 
two reasons:

1. remove obsolete and mostly unmaintained code
2. get bugs in the ALSA drivers reported that weren't previously
   reported due to the possible workaround of using the OSS drivers


The list below divides the OSS drivers into the following three
categories:
1. ALSA drivers for the same hardware
2. ALSA drivers for the same hardware with known problems
3. no ALSA drivers for the same hardware


My proposed timeline is:
- 2.6.18: let the drivers under 1. in the list below depend on
          OSS_OBSOLETE_DRIVER
- 2.6.20: remove the options depending on OSS_OBSOLETE_DRIVER
- 2.6.22: remove the code for the drivers that were depending on
          OSS_OBSOLETE_DRIVER from the kernel tree


To make a long story short:

If you are using an OSS driver because the ALSA driver doesn't work 
equally well on your hardware listed under 1. below, send me an email 
with a bug number in the ALSA bug tracking system now.


A small FAQ:

Q: But OSS is kewl and ALSA sucks!
A: The decision for the OSS->ALSA move was four years ago.
   If ALSA sucks, please help to improve ALSA.

Q: What about the OSS emulation in ALSA?
A: The OSS emulation in ALSA is not affected by my patches
   (and it's not in any way scheduled for removal).


Please review the following list:


1. ALSA drivers for the same hardware

DMASOUND_PMAC
SOUND_ACI_MIXER and RADIO_MIROPCM20
SOUND_AD1816
SOUND_AD1889
SOUND_ADLIB
SOUND_FUSION
SOUND_NM256
SOUND_OPL3SA2

2. ALSA drivers for the same hardware with known problems

SOUND_CS4232
- ALSA #1520 (Soundchip was not detected on HP Omnibook 5700 CTX)

SOUND_EMU10K1
- ALSA #1782 (really poor sound with my SB Live 1024 and ALSA)

SOUND_ES1371
- ALSA #1774 (missing joystick connector support for PCI Ensoniq ES1371)

SOUND_ICH
- ALSA #1764 (Recording signal quality is inacceptable (using OSS API))
- Alan Cox:
  ALSA driver lacks "support for AC97 wired touchscreens and the like"

SOUND_SSCAPE
- ALSA #2234 (driver does not find Soundscape Elite)

SOUND_TRIDENT
- ALSA #1293 (device supported by OSS but not by ALSA)
- maintainer of the OSS driver wants his driver to stay

SOUND_VIA82CXXX
- ALSA #1906 (1-second overruns reported by arecord,
              complete system hang with jackd -d alsa)


3. no ALSA drivers for the same hardware

DMASOUND_ATARI
DMASOUND_PAULA
DMASOUND_Q40
SOUND_AEDSP16
SOUND_AU1550_AC97
SOUND_BCM_CS4297A
SOUND_HAL2
SOUND_KAHLUA
SOUND_MSNDCLAS
SOUND_MSNDPIN
SOUND_MSS (also due to SOUND_PSS, SOUND_TRIX and perhaps SOUND_AEDSP16)
SOUND_PAS
SOUND_PSS
SOUND_SB (also due to SOUND_KAHLUA, SOUND_PAS and perhaps SOUND_AEDSP16)
SOUND_SH_DAC_AUDIO
SOUND_TRIX
SOUND_VIDC
SOUND_VRC5477
SOUND_VWSND
SOUND_WAVEARTIST

SOUND_IT8172
Ralf Baechle: 
Both board based on the ITE 8172 chipset are on my death list already; I
will probably remove it after 2.6.18 is out unless against all expectation
I receive patches.

Re: OSS driver removal, 2nd round (v2)

[Andi Kleen]

Adrian Bunk <bunk@stusta.de> writes:
> 
> Q: What about the OSS emulation in ALSA?
> A: The OSS emulation in ALSA is not affected by my patches
>    (and it's not in any way scheduled for removal).

I again object to removing the old ICH sound driver.
It does the same as the Alsa driver in much less code and is ideal
for generic monolithic kernels

-Andi

Re: OSS driver removal, 2nd round (v2)

[Andi Kleen]

Adrian Bunk <bunk@stusta.de> writes:
> 
> Q: What about the OSS emulation in ALSA?
> A: The OSS emulation in ALSA is not affected by my patches
>    (and it's not in any way scheduled for removal).

I again object to removing the old ICH sound driver.
It does the same as the Alsa driver in much less code and is ideal
for generic monolithic kernels

-Andi


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: OSS driver removal, 2nd round (v2)

[Adrian Bunk]

On Sat, Jul 08, 2006 at 01:50:00AM +0200, Andi Kleen wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> > 
> > Q: What about the OSS emulation in ALSA?
> > A: The OSS emulation in ALSA is not affected by my patches
> >    (and it's not in any way scheduled for removal).
> 
> I again object to removing the old ICH sound driver.
> It does the same as the Alsa driver in much less code and is ideal
> for generic monolithic kernels

First of all, if you read my email you'll note that this driver isn't 
currently scheduled for removal.

And more important, your comment is already covered by the other FAQ 
entry in my email:

Q: But OSS is kewl and ALSA sucks!
A: The decision for the OSS->ALSA move was four years ago.
   If ALSA sucks, please help to improve ALSA.

> -Andi

cu
Adrian

-- 

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

Re: OSS driver removal, 2nd round (v2)

[Adrian Bunk]

On Sat, Jul 08, 2006 at 01:50:00AM +0200, Andi Kleen wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> > 
> > Q: What about the OSS emulation in ALSA?
> > A: The OSS emulation in ALSA is not affected by my patches
> >    (and it's not in any way scheduled for removal).
> 
> I again object to removing the old ICH sound driver.
> It does the same as the Alsa driver in much less code and is ideal
> for generic monolithic kernels

First of all, if you read my email you'll note that this driver isn't 
currently scheduled for removal.

And more important, your comment is already covered by the other FAQ 
entry in my email:

Q: But OSS is kewl and ALSA sucks!
A: The decision for the OSS->ALSA move was four years ago.
   If ALSA sucks, please help to improve ALSA.

> -Andi

cu
Adrian

-- 

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



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: OSS driver removal, 2nd round (v2)

[Jeff Garzik]

Andi Kleen wrote:
> Adrian Bunk <bunk@stusta.de> writes:
>> Q: What about the OSS emulation in ALSA?
>> A: The OSS emulation in ALSA is not affected by my patches
>>    (and it's not in any way scheduled for removal).
> 
> I again object to removing the old ICH sound driver.
> It does the same as the Alsa driver in much less code and is ideal
> for generic monolithic kernels

Well, consensus seems to be with ALSA, OSS API is dated for modern uses, 
old ICH driver doesn't use the HD audio found on modern chips, and 
nobody is eagerly stepping forward to maintain the driver.

	Jeff

Re: OSS driver removal, 2nd round (v2)

[Jeff Garzik]

Andi Kleen wrote:
> Adrian Bunk <bunk@stusta.de> writes:
>> Q: What about the OSS emulation in ALSA?
>> A: The OSS emulation in ALSA is not affected by my patches
>>    (and it's not in any way scheduled for removal).
> 
> I again object to removing the old ICH sound driver.
> It does the same as the Alsa driver in much less code and is ideal
> for generic monolithic kernels

Well, consensus seems to be with ALSA, OSS API is dated for modern uses, 
old ICH driver doesn't use the HD audio found on modern chips, and 
nobody is eagerly stepping forward to maintain the driver.

	Jeff





-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Lee Revell]

On Sat, 2006-07-08 at 01:50 +0200, Andi Kleen wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> > 
> > Q: What about the OSS emulation in ALSA?
> > A: The OSS emulation in ALSA is not affected by my patches
> >    (and it's not in any way scheduled for removal).
> 
> I again object to removing the old ICH sound driver.
> It does the same as the Alsa driver in much less code and is ideal
> for generic monolithic kernels

It doesn't do the same thing - software mixing is impossible with OSS.

Lee

Re: OSS driver removal, 2nd round (v2)

[Lee Revell]

On Sat, 2006-07-08 at 01:50 +0200, Andi Kleen wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> > 
> > Q: What about the OSS emulation in ALSA?
> > A: The OSS emulation in ALSA is not affected by my patches
> >    (and it's not in any way scheduled for removal).
> 
> I again object to removing the old ICH sound driver.
> It does the same as the Alsa driver in much less code and is ideal
> for generic monolithic kernels

It doesn't do the same thing - software mixing is impossible with OSS.

Lee



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Olivier Galibert]

On Sun, Jul 09, 2006 at 11:18:19AM -0400, Lee Revell wrote:
> It doesn't do the same thing - software mixing is impossible with OSS.

It's exactly as impossible with OSS as it is with ALSA.  Just stop
considering the OSS API support the problem child of the family and
these removals will go *much* easier, you know?

  OG.

Re: OSS driver removal, 2nd round (v2)

[Olivier Galibert]

On Sun, Jul 09, 2006 at 11:18:19AM -0400, Lee Revell wrote:
> It doesn't do the same thing - software mixing is impossible with OSS.

It's exactly as impossible with OSS as it is with ALSA.  Just stop
considering the OSS API support the problem child of the family and
these removals will go *much* easier, you know?

  OG.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Sun, 09 Jul 2006 11:18:19 -0400
Lee Revell <rlrevell@joe-job.com> wrote:

> On Sat, 2006-07-08 at 01:50 +0200, Andi Kleen wrote:
> > Adrian Bunk <bunk@stusta.de> writes:
> > > 
> > > Q: What about the OSS emulation in ALSA?
> > > A: The OSS emulation in ALSA is not affected by my patches
> > >    (and it's not in any way scheduled for removal).
> > 
> > I again object to removing the old ICH sound driver.
> > It does the same as the Alsa driver in much less code and is ideal
> > for generic monolithic kernels
> 
> It doesn't do the same thing - software mixing is impossible with OSS.

Only GPL'ed version has this limitation - its just not implemented because all this
GPL'ed OSS is abandoned.
The commercial version from www.opensound.com does input/output mixing
in software in kernel space.
It is free for home/personal use and only one thing you must do is to update
it regularly - once every 4 months. It works out of the box with 2.6.xx kernels and you don't
need additional sound daemons or hidden library threads (ALSA approach).
It has included scripts for module compilation in case of kernel change
and you can also have automatic updates and mixer settings restore without need
for instaling additional software packages.
It has also text and graphical configuration tools and mixers.
So users have still a choise and they will chose a product which best fits they needs.

>From my point of view ALSA has many advantages if you want to dig in the card driver
buffers/period etc. settings but lacks ease of use and some of simple in theory
functionality is a pain - device enumeration or switching output mode/device
without restarting apps or rewritting them so they have special function for that purpose.

esd, arts, jackd, polypd and other prove that ALSA is not enough
and its functionality is far from perfect.

We have more and more audio devices - USB and Bluetooth ones - and
we need switch ouput from one to other device without changes in apps.

So better is to have some virtual sound device, then some mixing/effects/plugins
modules and then true sound device or network stream. Normal app just doesn't
need to now mutch about sound device. It just sets basic audio parameters
and plays. Is ALSA going in that direction?

ALSA api is too complicated - too many possibilities to obtain the same effect -
and additionaly there is no good docs how to use this api properly.
Some methods don't work in some situactions - callback method for example uses signals
and in case of apps which turns some signals off there will be no sound at all.

Developers of ALSA say that they have no time to write docs. True - but including in kernel
some functionality for which users have no good docs is not good for anybody.
We have many programs which use ALSA and don't work properly.
Forcing users to use ALSA is some kind of misunderstanding in this situaction.

We have also almost no docs about ALSA drvier <-> ALSA lib interface which is a strange
in case of GPL'ed software if we want to implement a new hw driver.

So is ALSA really what the users need? The future is unknown.
 
Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl

Re: OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Sun, 09 Jul 2006 11:18:19 -0400
Lee Revell <rlrevell@joe-job.com> wrote:

> On Sat, 2006-07-08 at 01:50 +0200, Andi Kleen wrote:
> > Adrian Bunk <bunk@stusta.de> writes:
> > > 
> > > Q: What about the OSS emulation in ALSA?
> > > A: The OSS emulation in ALSA is not affected by my patches
> > >    (and it's not in any way scheduled for removal).
> > 
> > I again object to removing the old ICH sound driver.
> > It does the same as the Alsa driver in much less code and is ideal
> > for generic monolithic kernels
> 
> It doesn't do the same thing - software mixing is impossible with OSS.

Only GPL'ed version has this limitation - its just not implemented because all this
GPL'ed OSS is abandoned.
The commercial version from www.opensound.com does input/output mixing
in software in kernel space.
It is free for home/personal use and only one thing you must do is to update
it regularly - once every 4 months. It works out of the box with 2.6.xx kernels and you don't
need additional sound daemons or hidden library threads (ALSA approach).
It has included scripts for module compilation in case of kernel change
and you can also have automatic updates and mixer settings restore without need
for instaling additional software packages.
It has also text and graphical configuration tools and mixers.
So users have still a choise and they will chose a product which best fits they needs.

>From my point of view ALSA has many advantages if you want to dig in the card driver
buffers/period etc. settings but lacks ease of use and some of simple in theory
functionality is a pain - device enumeration or switching output mode/device
without restarting apps or rewritting them so they have special function for that purpose.

esd, arts, jackd, polypd and other prove that ALSA is not enough
and its functionality is far from perfect.

We have more and more audio devices - USB and Bluetooth ones - and
we need switch ouput from one to other device without changes in apps.

So better is to have some virtual sound device, then some mixing/effects/plugins
modules and then true sound device or network stream. Normal app just doesn't
need to now mutch about sound device. It just sets basic audio parameters
and plays. Is ALSA going in that direction?

ALSA api is too complicated - too many possibilities to obtain the same effect -
and additionaly there is no good docs how to use this api properly.
Some methods don't work in some situactions - callback method for example uses signals
and in case of apps which turns some signals off there will be no sound at all.

Developers of ALSA say that they have no time to write docs. True - but including in kernel
some functionality for which users have no good docs is not good for anybody.
We have many programs which use ALSA and don't work properly.
Forcing users to use ALSA is some kind of misunderstanding in this situaction.

We have also almost no docs about ALSA drvier <-> ALSA lib interface which is a strange
in case of GPL'ed software if we want to implement a new hw driver.

So is ALSA really what the users need? The future is unknown.
 
Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[James Courtier-Dutton]

Adam Tlałka wrote:
> We have also almost no docs about ALSA drvier <-> ALSA lib interface which is a strange
> in case of GPL'ed software if we want to implement a new hw driver.
>
>   
To implement a new hw driver, one does not need to know anything about 
the ALSA driver <-> ALSA lib interface.
One simply implements a small set of functions, and ALSA does the rest.
There is good documentation regarding what this small set of functions 
are and what they should do.

James

Re: OSS driver removal, 2nd round (v2)

[James Courtier-Dutton]

Adam Tlałka wrote:
> We have also almost no docs about ALSA drvier <-> ALSA lib interface which is a strange
> in case of GPL'ed software if we want to implement a new hw driver.
>
>   
To implement a new hw driver, one does not need to know anything about 
the ALSA driver <-> ALSA lib interface.
One simply implements a small set of functions, and ALSA does the rest.
There is good documentation regarding what this small set of functions 
are and what they should do.

James



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adrian Bunk]

On Mon, Jul 10, 2006 at 01:28:10PM +0200, Adam Tlałka wrote:
> On Sun, 09 Jul 2006 11:18:19 -0400
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Sat, 2006-07-08 at 01:50 +0200, Andi Kleen wrote:
> > > Adrian Bunk <bunk@stusta.de> writes:
> > > > 
> > > > Q: What about the OSS emulation in ALSA?
> > > > A: The OSS emulation in ALSA is not affected by my patches
> > > >    (and it's not in any way scheduled for removal).
> > > 
> > > I again object to removing the old ICH sound driver.
> > > It does the same as the Alsa driver in much less code and is ideal
> > > for generic monolithic kernels
> > 
> > It doesn't do the same thing - software mixing is impossible with OSS.
> 
> Only GPL'ed version has this limitation - its just not implemented because all this
> GPL'ed OSS is abandoned.
> The commercial version from www.opensound.com does input/output mixing
> in software in kernel space.
>...

When we are talking about OSS, we are talking about what is under 
sound/oss/ in the kernel sources.

The commercial OSS might be much better, but it's not relevant since 
it's not GPL'ed and therefore not a candidate for inclusion into the 
kernel.

As you said yourself, the "GPL'ed OSS is abandoned".
And ALSA is it's successor in the kernel.

cu
Adrian

-- 

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

Re: OSS driver removal, 2nd round (v2)

[Adrian Bunk]

On Mon, Jul 10, 2006 at 01:28:10PM +0200, Adam Tlałka wrote:
> On Sun, 09 Jul 2006 11:18:19 -0400
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Sat, 2006-07-08 at 01:50 +0200, Andi Kleen wrote:
> > > Adrian Bunk <bunk@stusta.de> writes:
> > > > 
> > > > Q: What about the OSS emulation in ALSA?
> > > > A: The OSS emulation in ALSA is not affected by my patches
> > > >    (and it's not in any way scheduled for removal).
> > > 
> > > I again object to removing the old ICH sound driver.
> > > It does the same as the Alsa driver in much less code and is ideal
> > > for generic monolithic kernels
> > 
> > It doesn't do the same thing - software mixing is impossible with OSS.
> 
> Only GPL'ed version has this limitation - its just not implemented because all this
> GPL'ed OSS is abandoned.
> The commercial version from www.opensound.com does input/output mixing
> in software in kernel space.
>...

When we are talking about OSS, we are talking about what is under 
sound/oss/ in the kernel sources.

The commercial OSS might be much better, but it's not relevant since 
it's not GPL'ed and therefore not a candidate for inclusion into the 
kernel.

As you said yourself, the "GPL'ed OSS is abandoned".
And ALSA is it's successor in the kernel.

cu
Adrian

-- 

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



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Lee Revell]

On Mon, 2006-07-10 at 13:28 +0200, Adam Tlałka wrote:
> >From my point of view ALSA has many advantages if you want to dig in
> the card driver buffers/period etc. settings but lacks ease of use and
> some of simple in theory functionality is a pain - device enumeration
> or switching output mode/device without restarting apps or rewritting
> them so they have special function for that purpose.
> 

Does any available sound driver interface allow switching output devices
with no help from the app and without having to restart playback?  OSS
does not, and every Windows app I've used has a configuration option to
set the sound device, and you must stop and start playback for it to
take effect.

> esd, arts, jackd, polypd and other prove that ALSA is not enough
> and its functionality is far from perfect.
> 

esd and artsd are no longer needed since ALSA began to enable software
mixing by default in release 1.0.9.  As for jackd and other apps that
provide additional functionality - no one ever claimed ALSA would handle
every audio related function imaginable.  It's just a low level HAL.

Lee

Re: OSS driver removal, 2nd round (v2)

[Lee Revell]

On Mon, 2006-07-10 at 13:28 +0200, Adam Tlałka wrote:
> >From my point of view ALSA has many advantages if you want to dig in
> the card driver buffers/period etc. settings but lacks ease of use and
> some of simple in theory functionality is a pain - device enumeration
> or switching output mode/device without restarting apps or rewritting
> them so they have special function for that purpose.
> 

Does any available sound driver interface allow switching output devices
with no help from the app and without having to restart playback?  OSS
does not, and every Windows app I've used has a configuration option to
set the sound device, and you must stop and start playback for it to
take effect.

> esd, arts, jackd, polypd and other prove that ALSA is not enough
> and its functionality is far from perfect.
> 

esd and artsd are no longer needed since ALSA began to enable software
mixing by default in release 1.0.9.  As for jackd and other apps that
provide additional functionality - no one ever claimed ALSA would handle
every audio related function imaginable.  It's just a low level HAL.

Lee



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adam Tlałka]

Użytkownik Lee Revell napisał:
> On Mon, 2006-07-10 at 13:28 +0200, Adam Tlałka wrote:
>> >From my point of view ALSA has many advantages if you want to dig in
>> the card driver buffers/period etc. settings but lacks ease of use and
>> some of simple in theory functionality is a pain - device enumeration
>> or switching output mode/device without restarting apps or rewritting
>> them so they have special function for that purpose.
>>
> 
> Does any available sound driver interface allow switching output devices
> with no help from the app and without having to restart playback?  OSS
> does not, and every Windows app I've used has a configuration option to
> set the sound device, and you must stop and start playback for it to
> take effect.

Sorry but is a Windows solution the best on the whole world?
Is there any problem to imagine an abstract sound device which virtually 
always works but uses real device chosen by user, network redirection or 
  emulating work and we have some control panel/app which can control 
connections/plugins/redirections etc. (also this can be done by some 
kind of daemon responding to hw change events)?
Do we really need to program every sound app to have device setting code?

>> esd, arts, jackd, polypd and other prove that ALSA is not enough
>> and its functionality is far from perfect.
>>
> 
> esd and artsd are no longer needed since ALSA began to enable software
> mixing by default in release 1.0.9.
 >

So why they are still exist in so many Linux distributions?

> As for jackd and other apps that
> provide additional functionality - no one ever claimed ALSA would handle
> every audio related function imaginable.  It's just a low level HAL.

Format changing, resampling, mixing and supporting additional plugins
does not seems to be just low level HAL for hw device. It creates some 
kind of virtual functionality which means more then this provided by 
hardware device itself.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl

Re: OSS driver removal, 2nd round (v2)

[Adam Tlałka]

Użytkownik Lee Revell napisał:
> On Mon, 2006-07-10 at 13:28 +0200, Adam Tlałka wrote:
>> >From my point of view ALSA has many advantages if you want to dig in
>> the card driver buffers/period etc. settings but lacks ease of use and
>> some of simple in theory functionality is a pain - device enumeration
>> or switching output mode/device without restarting apps or rewritting
>> them so they have special function for that purpose.
>>
> 
> Does any available sound driver interface allow switching output devices
> with no help from the app and without having to restart playback?  OSS
> does not, and every Windows app I've used has a configuration option to
> set the sound device, and you must stop and start playback for it to
> take effect.

Sorry but is a Windows solution the best on the whole world?
Is there any problem to imagine an abstract sound device which virtually 
always works but uses real device chosen by user, network redirection or 
  emulating work and we have some control panel/app which can control 
connections/plugins/redirections etc. (also this can be done by some 
kind of daemon responding to hw change events)?
Do we really need to program every sound app to have device setting code?

>> esd, arts, jackd, polypd and other prove that ALSA is not enough
>> and its functionality is far from perfect.
>>
> 
> esd and artsd are no longer needed since ALSA began to enable software
> mixing by default in release 1.0.9.
 >

So why they are still exist in so many Linux distributions?

> As for jackd and other apps that
> provide additional functionality - no one ever claimed ALSA would handle
> every audio related function imaginable.  It's just a low level HAL.

Format changing, resampling, mixing and supporting additional plugins
does not seems to be just low level HAL for hw device. It creates some 
kind of virtual functionality which means more then this provided by 
hardware device itself.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Cloning sound output [was Re: [Alsa-devel] OSS driver removal, 2nd round (v2)]

[J.A. Magallón]

On Tue, 11 Jul 2006 01:38:39 +0200, Adam Tlałka <atlka@pg.gda.pl> wrote:

> 
> Format changing, resampling, mixing and supporting additional plugins
> does not seems to be just low level HAL for hw device. It creates some 
> kind of virtual functionality which means more then this provided by 
> hardware device itself.
> 

Slightly OT, I just read this message from all th thread.

A quick question (you can answer me in private if this is not suitable for
this list).

How can I clone the output from one card to other ? I want to say something
like 'all PCM that goes to this emu10k1, copy it to this other card'.
Basically, I want to play music on two cards at the same time.

TIA

--
J.A. Magallon <jamagallon()ono!com>     \               Software is like sex:
                                         \         It's better when it's free
Mandriva Linux release 2007.0 (Cooker) for i586
Linux 2.6.17-jam03 (gcc 4.1.1 20060518 (prerelease)) #3 SMP PREEMPT Mon

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Lee Revell]

On Tue, 2006-07-11 at 01:38 +0200, Adam Tlałka wrote:
> Użytkownik Lee Revell napisał:
> > On Mon, 2006-07-10 at 13:28 +0200, Adam Tlałka wrote:
> >> >From my point of view ALSA has many advantages if you want to dig in
> >> the card driver buffers/period etc. settings but lacks ease of use and
> >> some of simple in theory functionality is a pain - device enumeration
> >> or switching output mode/device without restarting apps or rewritting
> >> them so they have special function for that purpose.
> >>
> > 
> > Does any available sound driver interface allow switching output devices
> > with no help from the app and without having to restart playback?  OSS
> > does not, and every Windows app I've used has a configuration option to
> > set the sound device, and you must stop and start playback for it to
> > take effect.
> 
> Sorry but is a Windows solution the best on the whole world?
> Is there any problem to imagine an abstract sound device which virtually 
> always works but uses real device chosen by user, network redirection or 
>   emulating work and we have some control panel/app which can control 
> connections/plugins/redirections etc. (also this can be done by some 
> kind of daemon responding to hw change events)?
> Do we really need to program every sound app to have device setting code?
> 

The problem is you trade ease of development for performance, penalizing
the users to save developer time.  Your proposals would require every
app to go through a software buffering layer.

Of course, you're free to develop a system like this.

> >> esd, arts, jackd, polypd and other prove that ALSA is not enough
> >> and its functionality is far from perfect.
> >>
> > 
> > esd and artsd are no longer needed since ALSA began to enable software
> > mixing by default in release 1.0.9.
>  >
> 
> So why they are still exist in so many Linux distributions?
> 

Backwards compatibility, bugs still being worked out, waiting for
upstream to catch up, etc.  Same reason that distros never have the very
latest version of every app.

> > As for jackd and other apps that
> > provide additional functionality - no one ever claimed ALSA would handle
> > every audio related function imaginable.  It's just a low level HAL.
> 
> Format changing, resampling, mixing and supporting additional plugins
> does not seems to be just low level HAL for hw device. It creates some 
> kind of virtual functionality which means more then this provided by 
> hardware device itself.

OK, but my point is that it does not make sense to put every imaginable
audio feature in ALSA.

Lee

Re: OSS driver removal, 2nd round (v2)

[Lee Revell]

On Tue, 2006-07-11 at 01:38 +0200, Adam Tlałka wrote:
> Użytkownik Lee Revell napisał:
> > On Mon, 2006-07-10 at 13:28 +0200, Adam Tlałka wrote:
> >> >From my point of view ALSA has many advantages if you want to dig in
> >> the card driver buffers/period etc. settings but lacks ease of use and
> >> some of simple in theory functionality is a pain - device enumeration
> >> or switching output mode/device without restarting apps or rewritting
> >> them so they have special function for that purpose.
> >>
> > 
> > Does any available sound driver interface allow switching output devices
> > with no help from the app and without having to restart playback?  OSS
> > does not, and every Windows app I've used has a configuration option to
> > set the sound device, and you must stop and start playback for it to
> > take effect.
> 
> Sorry but is a Windows solution the best on the whole world?
> Is there any problem to imagine an abstract sound device which virtually 
> always works but uses real device chosen by user, network redirection or 
>   emulating work and we have some control panel/app which can control 
> connections/plugins/redirections etc. (also this can be done by some 
> kind of daemon responding to hw change events)?
> Do we really need to program every sound app to have device setting code?
> 

The problem is you trade ease of development for performance, penalizing
the users to save developer time.  Your proposals would require every
app to go through a software buffering layer.

Of course, you're free to develop a system like this.

> >> esd, arts, jackd, polypd and other prove that ALSA is not enough
> >> and its functionality is far from perfect.
> >>
> > 
> > esd and artsd are no longer needed since ALSA began to enable software
> > mixing by default in release 1.0.9.
>  >
> 
> So why they are still exist in so many Linux distributions?
> 

Backwards compatibility, bugs still being worked out, waiting for
upstream to catch up, etc.  Same reason that distros never have the very
latest version of every app.

> > As for jackd and other apps that
> > provide additional functionality - no one ever claimed ALSA would handle
> > every audio related function imaginable.  It's just a low level HAL.
> 
> Format changing, resampling, mixing and supporting additional plugins
> does not seems to be just low level HAL for hw device. It creates some 
> kind of virtual functionality which means more then this provided by 
> hardware device itself.

OK, but my point is that it does not make sense to put every imaginable
audio feature in ALSA.

Lee



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Olivier Galibert]

On Tue, Jul 11, 2006 at 01:38:39AM +0200, Adam Tla?ka wrote:
> Sorry but is a Windows solution the best on the whole world?

ALSA, with its "the API is a DLL", is a Windows solution.


> >esd and artsd are no longer needed since ALSA began to enable software
> >mixing by default in release 1.0.9.
> 
> So why they are still exist in so many Linux distributions?

That's an extremely recent change in distribution-time.


> Format changing, resampling, mixing and supporting additional plugins
> does not seems to be just low level HAL for hw device. It creates some 
> kind of virtual functionality which means more then this provided by 
> hardware device itself.

ALSA lib has something like 7 different methods just to play a sound.
Their view of "low level" is quite interesting.  Using it is pure
hell.  Debugging what you've done is worse.  And don't bother to hope
that your code will still work in six months.

  OG.

Re: OSS driver removal, 2nd round (v2)

[Olivier Galibert]

On Tue, Jul 11, 2006 at 01:38:39AM +0200, Adam Tla?ka wrote:
> Sorry but is a Windows solution the best on the whole world?

ALSA, with its "the API is a DLL", is a Windows solution.


> >esd and artsd are no longer needed since ALSA began to enable software
> >mixing by default in release 1.0.9.
> 
> So why they are still exist in so many Linux distributions?

That's an extremely recent change in distribution-time.


> Format changing, resampling, mixing and supporting additional plugins
> does not seems to be just low level HAL for hw device. It creates some 
> kind of virtual functionality which means more then this provided by 
> hardware device itself.

ALSA lib has something like 7 different methods just to play a sound.
Their view of "low level" is quite interesting.  Using it is pure
hell.  Debugging what you've done is worse.  And don't bother to hope
that your code will still work in six months.

  OG.



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Lee Revell]

On Tue, 2006-07-11 at 01:59 +0200, Olivier Galibert wrote:
> ALSA lib has something like 7 different methods just to play a sound.
> Their view of "low level" is quite interesting.  Using it is pure
> hell.  Debugging what you've done is worse.  And don't bother to hope
> that your code will still work in six months.
> 

A small FAQ:

Q: But OSS is kewl and ALSA sucks!
A: The decision for the OSS->ALSA move was four years ago.
   If ALSA sucks, please help to improve ALSA.

Re: OSS driver removal, 2nd round (v2)

[Lee Revell]

On Tue, 2006-07-11 at 01:59 +0200, Olivier Galibert wrote:
> ALSA lib has something like 7 different methods just to play a sound.
> Their view of "low level" is quite interesting.  Using it is pure
> hell.  Debugging what you've done is worse.  And don't bother to hope
> that your code will still work in six months.
> 

A small FAQ:

Q: But OSS is kewl and ALSA sucks!
A: The decision for the OSS->ALSA move was four years ago.
   If ALSA sucks, please help to improve ALSA.




-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

On Tue, 11 Jul 2006 01:38:39 +0200, =?ISO-8859-2?Q?Adam_Tla=B3ka?= said:
> U¿ytkownik Lee Revell napisa³:
>
> > esd and artsd are no longer needed since ALSA began to enable software
> > mixing by default in release 1.0.9.
>  >
> 
> So why they are still exist in so many Linux distributions?

As soon as somebody writes a patch to make the e16 window manager talk ALSA
rather than use esd, I'm heaving esd over the side.

Of course, I've been saying that since ALSA 1.0.9 came out.  (And don't
suggest I write it myself - I could if I was motivated enough, but I'm not
motivated at the current time. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: OSS driver removal, 2nd round (v2)

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 619 bytes --]

On Tue, 11 Jul 2006 01:38:39 +0200, =?ISO-8859-2?Q?Adam_Tla=B3ka?= said:
> U¿ytkownik Lee Revell napisa³:
>
> > esd and artsd are no longer needed since ALSA began to enable software
> > mixing by default in release 1.0.9.
>  >
> 
> So why they are still exist in so many Linux distributions?

As soon as somebody writes a patch to make the e16 window manager talk ALSA
rather than use esd, I'm heaving esd over the side.

Of course, I've been saying that since ALSA 1.0.9 came out.  (And don't
suggest I write it myself - I could if I was motivated enough, but I'm not
motivated at the current time. :)

[-- Attachment #1.2: Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 375 bytes --]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Mon, 10 Jul 2006 22:09:51 -0400
Valdis.Kletnieks@vt.edu wrote:

> On Tue, 11 Jul 2006 01:38:39 +0200, =?ISO-8859-2?Q?Adam_Tla=B3ka?= said:
> > Użytkownik Lee Revell napisał:
> >
> > > esd and artsd are no longer needed since ALSA began to enable software
> > > mixing by default in release 1.0.9.
> >  >
> > 
> > So why they are still exist in so many Linux distributions?
> 
> As soon as somebody writes a patch to make the e16 window manager talk ALSA
> rather than use esd, I'm heaving esd over the side.

Sorry to say but it is just not that way. Window manager is for managing windows
and it shouldn't depend on any audio system. It should use an external app using exec call
to play sounds (aplay, sox, wavplay etc.) configured by some config option.
Generally it is a big mess in may distros where desktop apps depends on sound.
Yes, it is nice to have sound but it is not absolutly needed to use an editor for example. 

> Of course, I've been saying that since ALSA 1.0.9 came out.  (And don't
> suggest I write it myself - I could if I was motivated enough, but I'm not
> motivated at the current time. :)
> 

If you are the author then I just suggest to use exec(3) call, for example:

if (!fork()){
	execvp("aplay","beep.wav");
	exit(0);
}

Simple, and you don't need to know anything about sound programming ;-).

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl

Re: OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Mon, 10 Jul 2006 22:09:51 -0400
Valdis.Kletnieks@vt.edu wrote:

> On Tue, 11 Jul 2006 01:38:39 +0200, =?ISO-8859-2?Q?Adam_Tla=B3ka?= said:
> > Użytkownik Lee Revell napisał:
> >
> > > esd and artsd are no longer needed since ALSA began to enable software
> > > mixing by default in release 1.0.9.
> >  >
> > 
> > So why they are still exist in so many Linux distributions?
> 
> As soon as somebody writes a patch to make the e16 window manager talk ALSA
> rather than use esd, I'm heaving esd over the side.

Sorry to say but it is just not that way. Window manager is for managing windows
and it shouldn't depend on any audio system. It should use an external app using exec call
to play sounds (aplay, sox, wavplay etc.) configured by some config option.
Generally it is a big mess in may distros where desktop apps depends on sound.
Yes, it is nice to have sound but it is not absolutly needed to use an editor for example. 

> Of course, I've been saying that since ALSA 1.0.9 came out.  (And don't
> suggest I write it myself - I could if I was motivated enough, but I'm not
> motivated at the current time. :)
> 

If you are the author then I just suggest to use exec(3) call, for example:

if (!fork()){
	execvp("aplay","beep.wav");
	exit(0);
}

Simple, and you don't need to know anything about sound programming ;-).

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Mon, 10 Jul 2006 20:39:03 -0400
Lee Revell <rlrevell@joe-job.com> wrote:

> On Tue, 2006-07-11 at 01:59 +0200, Olivier Galibert wrote:
> > ALSA lib has something like 7 different methods just to play a sound.
> > Their view of "low level" is quite interesting.  Using it is pure
> > hell.  Debugging what you've done is worse.  And don't bother to hope
> > that your code will still work in six months.
> > 
> 
> A small FAQ:
> 
> Q: But OSS is kewl and ALSA sucks!
> A: The decision for the OSS->ALSA move was four years ago.
>    If ALSA sucks, please help to improve ALSA.

The problem is that ALSA is done a Windows way with too many not always working ways
of obtaining sound and lack of user docs. So there is still the general question:
Is it the proper way? How I can help improve ALSA if I just dislike its design?

I spent some time improving dmix and aoss in the past. I have a version of aoss
which uses callbacks and works properly with some not properly written OSS apps.
It's very interesting that with some apps aoss method gives better sound A/V synchronization then using native ALSA app support ;-).
But callbacks not always work and LD_PRELOAD method is generally not secure
and some kind of a hack. So I just don't think it could be improved with it's current design.
In my opinion it should work out of the box without need to rewrite old or proprietary apps
and messing with LD_PRELOAD. So /dev/dsp compatibility is a must. But with all input/output
mixing of course. Userspace thread method leads to many problems - swapping and rescheduling leads to bad acustic effects. Of course if an app can't supply data when it should we can't do anything but if scheduling or swapping causes problems the design seems to be bad.

There are many devices which need to be served at the some critical point in time
- sound cards, video and tv grabbers, some dedicated lab cards, i/o ports etc.
Generally on the really low level this is a kernel driver which sticks to the hardware and should ``know'' how critical is to serve hw requests just in time. If we have data in a buffer programing DMA transfer is a quite quick operation but must be done at the proper moment.
So maybe we should delay a bit other io for example and just do it. But it must be done in kernel because kernel should know these critical time parameters for all devices in the system and decide which to serve and when. Maybe this is not needed for all devices but for audio/video devices it's a must. Better kernel support for these kind of devices is absolutely needed.

ALSA in lib way has its limitations and drawbacks and adding more feaures this way
leads to more complications only IMHO.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl

Re: OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Mon, 10 Jul 2006 20:39:03 -0400
Lee Revell <rlrevell@joe-job.com> wrote:

> On Tue, 2006-07-11 at 01:59 +0200, Olivier Galibert wrote:
> > ALSA lib has something like 7 different methods just to play a sound.
> > Their view of "low level" is quite interesting.  Using it is pure
> > hell.  Debugging what you've done is worse.  And don't bother to hope
> > that your code will still work in six months.
> > 
> 
> A small FAQ:
> 
> Q: But OSS is kewl and ALSA sucks!
> A: The decision for the OSS->ALSA move was four years ago.
>    If ALSA sucks, please help to improve ALSA.

The problem is that ALSA is done a Windows way with too many not always working ways
of obtaining sound and lack of user docs. So there is still the general question:
Is it the proper way? How I can help improve ALSA if I just dislike its design?

I spent some time improving dmix and aoss in the past. I have a version of aoss
which uses callbacks and works properly with some not properly written OSS apps.
It's very interesting that with some apps aoss method gives better sound A/V synchronization then using native ALSA app support ;-).
But callbacks not always work and LD_PRELOAD method is generally not secure
and some kind of a hack. So I just don't think it could be improved with it's current design.
In my opinion it should work out of the box without need to rewrite old or proprietary apps
and messing with LD_PRELOAD. So /dev/dsp compatibility is a must. But with all input/output
mixing of course. Userspace thread method leads to many problems - swapping and rescheduling leads to bad acustic effects. Of course if an app can't supply data when it should we can't do anything but if scheduling or swapping causes problems the design seems to be bad.

There are many devices which need to be served at the some critical point in time
- sound cards, video and tv grabbers, some dedicated lab cards, i/o ports etc.
Generally on the really low level this is a kernel driver which sticks to the hardware and should ``know'' how critical is to serve hw requests just in time. If we have data in a buffer programing DMA transfer is a quite quick operation but must be done at the proper moment.
So maybe we should delay a bit other io for example and just do it. But it must be done in kernel because kernel should know these critical time parameters for all devices in the system and decide which to serve and when. Maybe this is not needed for all devices but for audio/video devices it's a must. Better kernel support for these kind of devices is absolutely needed.

ALSA in lib way has its limitations and drawbacks and adding more feaures this way
leads to more complications only IMHO.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Andi Kleen]

> The problem is that ALSA is done a Windows way with too many not always
> working ways of obtaining sound and lack of user docs. So there is still
> the general question: Is it the proper way? How I can help improve ALSA if
> I just dislike its design?

Can you please drop me from the cc list of  this discussion? Thanks.

-Andi

Re: OSS driver removal, 2nd round (v2)

[Andi Kleen]

> The problem is that ALSA is done a Windows way with too many not always
> working ways of obtaining sound and lack of user docs. So there is still
> the general question: Is it the proper way? How I can help improve ALSA if
> I just dislike its design?

Can you please drop me from the cc list of  this discussion? Thanks.

-Andi




-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Jaroslav Kysela]

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

On Tue, 11 Jul 2006, Adam Tlałka wrote:

> On Mon, 10 Jul 2006 20:39:03 -0400
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Tue, 2006-07-11 at 01:59 +0200, Olivier Galibert wrote:
> > > ALSA lib has something like 7 different methods just to play a sound.
> > > Their view of "low level" is quite interesting.  Using it is pure
> > > hell.  Debugging what you've done is worse.  And don't bother to hope
> > > that your code will still work in six months.
> > > 
> > 
> > A small FAQ:
> > 
> > Q: But OSS is kewl and ALSA sucks!
> > A: The decision for the OSS->ALSA move was four years ago.
> >    If ALSA sucks, please help to improve ALSA.
> 
> The problem is that ALSA is done a Windows way with too many not always 
> working ways of obtaining sound and lack of user docs. So there is still 

The docs are available: 
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html

If you have some comment or idea to improve it, please, post it to 
the relevant mailing list.

> the general question: Is it the proper way? How I can help improve ALSA 
> if I just dislike its design?

Then it is your problem. I've not seen a single problematic technical 
information from your mails.

> I spent some time improving dmix and aoss in the past. I have a version 
> of aoss which uses callbacks and works properly with some not properly 
> written OSS apps. It's very interesting that with some apps aoss method 
> gives better sound A/V synchronization then using native ALSA app 
> support ;-). But callbacks not always work and LD_PRELOAD method is 
> generally not secure and some kind of a hack. So I just don't think it 
> could be improved with it's current design. In my opinion it should work 
> out of the box without need to rewrite old or proprietary apps and 
> messing with LD_PRELOAD. So /dev/dsp compatibility is a must. But with 
> all input/output mixing of course. Userspace thread method leads to many 
> problems - swapping and rescheduling leads to bad acustic effects. Of 
> course if an app can't supply data when it should we can't do anything 
> but if scheduling or swapping causes problems the design seems to be 
> bad.
>
> There are many devices which need to be served at the some critical 
> point in time
> - sound cards, video and tv grabbers, some dedicated lab cards, i/o 
>   ports etc.  Generally on the really low level this is a kernel driver 
>   which sticks to the hardware and should ``know'' how critical is to 
>   serve hw requests just in time. If we have data in a buffer programing 
>   DMA transfer is a quite quick operation but must be done at the proper 
>   moment.  So maybe we should delay a bit other io for example and just 
>   do it. But it must be done in kernel because kernel should know these 
>   critical time parameters for all devices in the system and decide 
>   which to serve and when. Maybe this is not needed for all devices but 
>   for audio/video devices it's a must. Better kernel support for these 
>   kind of devices is absolutely needed.

You're a bit mixing things:

a) we're not trying to be more compatible than OSS code in kernel, if you 
   like to do the mixing in kernel, simply write a new ALSA lowlevel 
   driver which will do it; I'm sure when the quality of your code will be 
   good,  we'll include it to the ALSA tree, but we are not going this
   way unless someone else will maintain this code
b) you're requestion to avoid scheduler participation in the audio 
   processing and yes, we have this solution already (dmix), but not in 
   kernel
c) as you said, the kernel should contain only critical code to drive
   hardware, sample rate conversion, sample format conversions and so on
   are NOT part of this code in my opinion

> ALSA in lib way has its limitations and drawbacks and adding more 
> feaures this way leads to more complications only IMHO.

Which limitations? We can do all things like OSS API. The whole point of 
all problems is that OSS has the API entry point in syscalls which is 
quite bad so the redirection is problematic.

						Jaroslav

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

Re: OSS driver removal, 2nd round (v2)

[Jaroslav Kysela]

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

On Tue, 11 Jul 2006, Adam Tlałka wrote:

> On Mon, 10 Jul 2006 20:39:03 -0400
> Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > On Tue, 2006-07-11 at 01:59 +0200, Olivier Galibert wrote:
> > > ALSA lib has something like 7 different methods just to play a sound.
> > > Their view of "low level" is quite interesting.  Using it is pure
> > > hell.  Debugging what you've done is worse.  And don't bother to hope
> > > that your code will still work in six months.
> > > 
> > 
> > A small FAQ:
> > 
> > Q: But OSS is kewl and ALSA sucks!
> > A: The decision for the OSS->ALSA move was four years ago.
> >    If ALSA sucks, please help to improve ALSA.
> 
> The problem is that ALSA is done a Windows way with too many not always 
> working ways of obtaining sound and lack of user docs. So there is still 

The docs are available: 
http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html

If you have some comment or idea to improve it, please, post it to 
the relevant mailing list.

> the general question: Is it the proper way? How I can help improve ALSA 
> if I just dislike its design?

Then it is your problem. I've not seen a single problematic technical 
information from your mails.

> I spent some time improving dmix and aoss in the past. I have a version 
> of aoss which uses callbacks and works properly with some not properly 
> written OSS apps. It's very interesting that with some apps aoss method 
> gives better sound A/V synchronization then using native ALSA app 
> support ;-). But callbacks not always work and LD_PRELOAD method is 
> generally not secure and some kind of a hack. So I just don't think it 
> could be improved with it's current design. In my opinion it should work 
> out of the box without need to rewrite old or proprietary apps and 
> messing with LD_PRELOAD. So /dev/dsp compatibility is a must. But with 
> all input/output mixing of course. Userspace thread method leads to many 
> problems - swapping and rescheduling leads to bad acustic effects. Of 
> course if an app can't supply data when it should we can't do anything 
> but if scheduling or swapping causes problems the design seems to be 
> bad.
>
> There are many devices which need to be served at the some critical 
> point in time
> - sound cards, video and tv grabbers, some dedicated lab cards, i/o 
>   ports etc.  Generally on the really low level this is a kernel driver 
>   which sticks to the hardware and should ``know'' how critical is to 
>   serve hw requests just in time. If we have data in a buffer programing 
>   DMA transfer is a quite quick operation but must be done at the proper 
>   moment.  So maybe we should delay a bit other io for example and just 
>   do it. But it must be done in kernel because kernel should know these 
>   critical time parameters for all devices in the system and decide 
>   which to serve and when. Maybe this is not needed for all devices but 
>   for audio/video devices it's a must. Better kernel support for these 
>   kind of devices is absolutely needed.

You're a bit mixing things:

a) we're not trying to be more compatible than OSS code in kernel, if you 
   like to do the mixing in kernel, simply write a new ALSA lowlevel 
   driver which will do it; I'm sure when the quality of your code will be 
   good,  we'll include it to the ALSA tree, but we are not going this
   way unless someone else will maintain this code
b) you're requestion to avoid scheduler participation in the audio 
   processing and yes, we have this solution already (dmix), but not in 
   kernel
c) as you said, the kernel should contain only critical code to drive
   hardware, sample rate conversion, sample format conversions and so on
   are NOT part of this code in my opinion

> ALSA in lib way has its limitations and drawbacks and adding more 
> feaures this way leads to more complications only IMHO.

Which limitations? We can do all things like OSS API. The whole point of 
all problems is that OSS has the API entry point in syscalls which is 
quite bad so the redirection is problematic.

						Jaroslav

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

[-- Attachment #2: Type: text/plain, Size: 375 bytes --]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Tue, 11 Jul 2006 09:58:26 +0200 (CEST)
Jaroslav Kysela <perex@suse.cz> wrote:

> On Tue, 11 Jul 2006, Adam Tlałka wrote:
> 
> > On Mon, 10 Jul 2006 20:39:03 -0400
> > Lee Revell <rlrevell@joe-job.com> wrote:
> > 
> > > On Tue, 2006-07-11 at 01:59 +0200, Olivier Galibert wrote:
> > > > ALSA lib has something like 7 different methods just to play a sound.
> > > > Their view of "low level" is quite interesting.  Using it is pure
> > > > hell.  Debugging what you've done is worse.  And don't bother to hope
> > > > that your code will still work in six months.
> > > > 
> > > 
> > > A small FAQ:
> > > 
> > > Q: But OSS is kewl and ALSA sucks!
> > > A: The decision for the OSS->ALSA move was four years ago.
> > >    If ALSA sucks, please help to improve ALSA.
> > 
> > The problem is that ALSA is done a Windows way with too many not always 
> > working ways of obtaining sound and lack of user docs. So there is still 
> 
> The docs are available: 
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html
> 
> If you have some comment or idea to improve it, please, post it to 
> the relevant mailing list.
>

I posted some ideas in the past but with current design it's no go.
 
> > the general question: Is it the proper way? How I can help improve ALSA 
> > if I just dislike its design?
> 
> Then it is your problem. I've not seen a single problematic technical 
> information from your mails.

Pity. Me and probably many users have this problem.

> 
> > I spent some time improving dmix and aoss in the past. I have a version 
> > of aoss which uses callbacks and works properly with some not properly 
> > written OSS apps. It's very interesting that with some apps aoss method 
> > gives better sound A/V synchronization then using native ALSA app 
> > support ;-). But callbacks not always work and LD_PRELOAD method is 
> > generally not secure and some kind of a hack. So I just don't think it 
> > could be improved with it's current design. In my opinion it should work 
> > out of the box without need to rewrite old or proprietary apps and 
> > messing with LD_PRELOAD. So /dev/dsp compatibility is a must. But with 
> > all input/output mixing of course. Userspace thread method leads to many 
> > problems - swapping and rescheduling leads to bad acustic effects. Of 
> > course if an app can't supply data when it should we can't do anything 
> > but if scheduling or swapping causes problems the design seems to be 
> > bad.
> >
> > There are many devices which need to be served at the some critical 
> > point in time
> > - sound cards, video and tv grabbers, some dedicated lab cards, i/o 
> >   ports etc.  Generally on the really low level this is a kernel driver 
> >   which sticks to the hardware and should ``know'' how critical is to 
> >   serve hw requests just in time. If we have data in a buffer programing 
> >   DMA transfer is a quite quick operation but must be done at the proper 
> >   moment.  So maybe we should delay a bit other io for example and just 
> >   do it. But it must be done in kernel because kernel should know these 
> >   critical time parameters for all devices in the system and decide 
> >   which to serve and when. Maybe this is not needed for all devices but 
> >   for audio/video devices it's a must. Better kernel support for these 
> >   kind of devices is absolutely needed.
> 
> You're a bit mixing things:
> 
> a) we're not trying to be more compatible than OSS code in kernel, if you 
>    like to do the mixing in kernel, simply write a new ALSA lowlevel 
>    driver which will do it; I'm sure when the quality of your code will be 
>    good,  we'll include it to the ALSA tree, but we are not going this
>    way unless someone else will maintain this code

OSS kernel compatibility is only partial and aoss method is not fully compatible either
I will try to write some code but I have very little free time for that so I am trying
to convince people to rethinking the case 
 
> b) you're requestion to avoid scheduler participation in the audio 
>    processing and yes, we have this solution already (dmix), but not in 
>    kernel

just the contrary - scheduler participation is needed to avoid sound distortion
and missing samples 

> c) as you said, the kernel should contain only critical code to drive
>    hardware, sample rate conversion, sample format conversions and so on
>    are NOT part of this code in my opinion

if doing this operations behind application back can lead to not delivering
data to kernel driver in time then these are time critical operations too!

> 
> > ALSA in lib way has its limitations and drawbacks and adding more 
> > feaures this way leads to more complications only IMHO.
> 
> Which limitations? We can do all things like OSS API. The whole point of 
> all problems is that OSS has the API entry point in syscalls which is 
> quite bad so the redirection is problematic.

Yes but what a complicated way. And you cannot use kernel OSS emulation
and ALSA aware apps at the same time. Also aoss with dmix are in
conflict with jackd for example.

Kernel redirector is not a bad solution - there should be some kind
of interface for such redirectors for different purposes. netlink device maybe?
For example you should redirect all these traffic to some RT daemon
doing all job.

Same with filesystem redirections. I hate these special gnomevfs or kdeio
helpers which forces to rebuilding apps with more and more libs.
Change LD_PRELOAD or LD_LIBRARY_PATH and you app will go to hell.
This is the Windows way of doing uncontrolled mess.
This plugin architecture without mandatory kernel access control leads
to serious security risc.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl

Re: OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Tue, 11 Jul 2006 09:58:26 +0200 (CEST)
Jaroslav Kysela <perex@suse.cz> wrote:

> On Tue, 11 Jul 2006, Adam Tlałka wrote:
> 
> > On Mon, 10 Jul 2006 20:39:03 -0400
> > Lee Revell <rlrevell@joe-job.com> wrote:
> > 
> > > On Tue, 2006-07-11 at 01:59 +0200, Olivier Galibert wrote:
> > > > ALSA lib has something like 7 different methods just to play a sound.
> > > > Their view of "low level" is quite interesting.  Using it is pure
> > > > hell.  Debugging what you've done is worse.  And don't bother to hope
> > > > that your code will still work in six months.
> > > > 
> > > 
> > > A small FAQ:
> > > 
> > > Q: But OSS is kewl and ALSA sucks!
> > > A: The decision for the OSS->ALSA move was four years ago.
> > >    If ALSA sucks, please help to improve ALSA.
> > 
> > The problem is that ALSA is done a Windows way with too many not always 
> > working ways of obtaining sound and lack of user docs. So there is still 
> 
> The docs are available: 
> http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html
> 
> If you have some comment or idea to improve it, please, post it to 
> the relevant mailing list.
>

I posted some ideas in the past but with current design it's no go.
 
> > the general question: Is it the proper way? How I can help improve ALSA 
> > if I just dislike its design?
> 
> Then it is your problem. I've not seen a single problematic technical 
> information from your mails.

Pity. Me and probably many users have this problem.

> 
> > I spent some time improving dmix and aoss in the past. I have a version 
> > of aoss which uses callbacks and works properly with some not properly 
> > written OSS apps. It's very interesting that with some apps aoss method 
> > gives better sound A/V synchronization then using native ALSA app 
> > support ;-). But callbacks not always work and LD_PRELOAD method is 
> > generally not secure and some kind of a hack. So I just don't think it 
> > could be improved with it's current design. In my opinion it should work 
> > out of the box without need to rewrite old or proprietary apps and 
> > messing with LD_PRELOAD. So /dev/dsp compatibility is a must. But with 
> > all input/output mixing of course. Userspace thread method leads to many 
> > problems - swapping and rescheduling leads to bad acustic effects. Of 
> > course if an app can't supply data when it should we can't do anything 
> > but if scheduling or swapping causes problems the design seems to be 
> > bad.
> >
> > There are many devices which need to be served at the some critical 
> > point in time
> > - sound cards, video and tv grabbers, some dedicated lab cards, i/o 
> >   ports etc.  Generally on the really low level this is a kernel driver 
> >   which sticks to the hardware and should ``know'' how critical is to 
> >   serve hw requests just in time. If we have data in a buffer programing 
> >   DMA transfer is a quite quick operation but must be done at the proper 
> >   moment.  So maybe we should delay a bit other io for example and just 
> >   do it. But it must be done in kernel because kernel should know these 
> >   critical time parameters for all devices in the system and decide 
> >   which to serve and when. Maybe this is not needed for all devices but 
> >   for audio/video devices it's a must. Better kernel support for these 
> >   kind of devices is absolutely needed.
> 
> You're a bit mixing things:
> 
> a) we're not trying to be more compatible than OSS code in kernel, if you 
>    like to do the mixing in kernel, simply write a new ALSA lowlevel 
>    driver which will do it; I'm sure when the quality of your code will be 
>    good,  we'll include it to the ALSA tree, but we are not going this
>    way unless someone else will maintain this code

OSS kernel compatibility is only partial and aoss method is not fully compatible either
I will try to write some code but I have very little free time for that so I am trying
to convince people to rethinking the case 
 
> b) you're requestion to avoid scheduler participation in the audio 
>    processing and yes, we have this solution already (dmix), but not in 
>    kernel

just the contrary - scheduler participation is needed to avoid sound distortion
and missing samples 

> c) as you said, the kernel should contain only critical code to drive
>    hardware, sample rate conversion, sample format conversions and so on
>    are NOT part of this code in my opinion

if doing this operations behind application back can lead to not delivering
data to kernel driver in time then these are time critical operations too!

> 
> > ALSA in lib way has its limitations and drawbacks and adding more 
> > feaures this way leads to more complications only IMHO.
> 
> Which limitations? We can do all things like OSS API. The whole point of 
> all problems is that OSS has the API entry point in syscalls which is 
> quite bad so the redirection is problematic.

Yes but what a complicated way. And you cannot use kernel OSS emulation
and ALSA aware apps at the same time. Also aoss with dmix are in
conflict with jackd for example.

Kernel redirector is not a bad solution - there should be some kind
of interface for such redirectors for different purposes. netlink device maybe?
For example you should redirect all these traffic to some RT daemon
doing all job.

Same with filesystem redirections. I hate these special gnomevfs or kdeio
helpers which forces to rebuilding apps with more and more libs.
Change LD_PRELOAD or LD_LIBRARY_PATH and you app will go to hell.
This is the Windows way of doing uncontrolled mess.
This plugin architecture without mandatory kernel access control leads
to serious security risc.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Jaroslav Kysela]

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

On Tue, 11 Jul 2006, Adam Tlałka wrote:

> OSS kernel compatibility is only partial and aoss method is not fully 

Partial? Elaborate please. And talk about OSS drivers in 2.6 kernel.

> > b) you're requestion to avoid scheduler participation in the audio 
> >    processing and yes, we have this solution already (dmix), but not in 
> >    kernel
> 
> just the contrary - scheduler participation is needed to avoid sound 
> distortion and missing samples

Nope. You're missing that dmix does not add any extra latencies, because
samples are written directly to the DMA buffer.

> > c) as you said, the kernel should contain only critical code to drive
> >    hardware, sample rate conversion, sample format conversions and so on
> >    are NOT part of this code in my opinion
> 
> if doing this operations behind application back can lead to not delivering
> data to kernel driver in time then these are time critical operations too!

Sorry, but you have limited resources (CPU power). It's completely 
irrelevant, if you do processing in the user space or in kernel (in my 
opinion it's even worse to do such things in the interrupt context).
It's probably better to think how to instruct scheduler to wake up
the sound applications as soon as possible.

> > > ALSA in lib way has its limitations and drawbacks and adding more 
> > > feaures this way leads to more complications only IMHO.
> > 
> > Which limitations? We can do all things like OSS API. The whole point of 
> > all problems is that OSS has the API entry point in syscalls which is 
> > quite bad so the redirection is problematic.
> 
> Yes but what a complicated way. And you cannot use kernel OSS emulation
> and ALSA aware apps at the same time. Also aoss with dmix are in
> conflict with jackd for example.

??? Elaborate. It should work.

> Kernel redirector is not a bad solution - there should be some kind of 
> interface for such redirectors for different purposes. netlink device 
> maybe? For example you should redirect all these traffic to some RT 
> daemon doing all job.

I would prefer probably a network lowlevel ALSA driver. You'll get the 
network transparency as benefit.

> Same with filesystem redirections. I hate these special gnomevfs or kdeio
> helpers which forces to rebuilding apps with more and more libs.
> Change LD_PRELOAD or LD_LIBRARY_PATH and you app will go to hell.
> This is the Windows way of doing uncontrolled mess.
> This plugin architecture without mandatory kernel access control leads
> to serious security risc.

Unfortunately, more functionality requires more code. You have to deal 
with bloating the user or kernel space.

						Jaroslav

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

Re: OSS driver removal, 2nd round (v2)

[Jaroslav Kysela]

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

On Tue, 11 Jul 2006, Adam Tlałka wrote:

> OSS kernel compatibility is only partial and aoss method is not fully 

Partial? Elaborate please. And talk about OSS drivers in 2.6 kernel.

> > b) you're requestion to avoid scheduler participation in the audio 
> >    processing and yes, we have this solution already (dmix), but not in 
> >    kernel
> 
> just the contrary - scheduler participation is needed to avoid sound 
> distortion and missing samples

Nope. You're missing that dmix does not add any extra latencies, because
samples are written directly to the DMA buffer.

> > c) as you said, the kernel should contain only critical code to drive
> >    hardware, sample rate conversion, sample format conversions and so on
> >    are NOT part of this code in my opinion
> 
> if doing this operations behind application back can lead to not delivering
> data to kernel driver in time then these are time critical operations too!

Sorry, but you have limited resources (CPU power). It's completely 
irrelevant, if you do processing in the user space or in kernel (in my 
opinion it's even worse to do such things in the interrupt context).
It's probably better to think how to instruct scheduler to wake up
the sound applications as soon as possible.

> > > ALSA in lib way has its limitations and drawbacks and adding more 
> > > feaures this way leads to more complications only IMHO.
> > 
> > Which limitations? We can do all things like OSS API. The whole point of 
> > all problems is that OSS has the API entry point in syscalls which is 
> > quite bad so the redirection is problematic.
> 
> Yes but what a complicated way. And you cannot use kernel OSS emulation
> and ALSA aware apps at the same time. Also aoss with dmix are in
> conflict with jackd for example.

??? Elaborate. It should work.

> Kernel redirector is not a bad solution - there should be some kind of 
> interface for such redirectors for different purposes. netlink device 
> maybe? For example you should redirect all these traffic to some RT 
> daemon doing all job.

I would prefer probably a network lowlevel ALSA driver. You'll get the 
network transparency as benefit.

> Same with filesystem redirections. I hate these special gnomevfs or kdeio
> helpers which forces to rebuilding apps with more and more libs.
> Change LD_PRELOAD or LD_LIBRARY_PATH and you app will go to hell.
> This is the Windows way of doing uncontrolled mess.
> This plugin architecture without mandatory kernel access control leads
> to serious security risc.

Unfortunately, more functionality requires more code. You have to deal 
with bloating the user or kernel space.

						Jaroslav

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

[-- Attachment #2: Type: text/plain, Size: 375 bytes --]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adrian Bunk]

On Tue, Jul 11, 2006 at 11:08:10AM +0200, Adam Tlałka wrote:
> On Tue, 11 Jul 2006 09:58:26 +0200 (CEST)
> Jaroslav Kysela <perex@suse.cz> wrote:
>...
> > You're a bit mixing things:
> > 
> > a) we're not trying to be more compatible than OSS code in kernel, if you 
> >    like to do the mixing in kernel, simply write a new ALSA lowlevel 
> >    driver which will do it; I'm sure when the quality of your code will be 
> >    good,  we'll include it to the ALSA tree, but we are not going this
> >    way unless someone else will maintain this code
> 
> OSS kernel compatibility is only partial and aoss method is not fully compatible either

Except for some corner cases, ALSA is capable of emulating the 
in-kernel OSS.

And considering the low number of applications that are still OSS-only, 
I doubt it's really that important improving the OSS emulation even 
further.

But this is open source software, so feel free to send patches.

> I will try to write some code but I have very little free time for that so I am trying
> to convince people to rethinking the case 
>...

This is not how open source software works.

If you think something is missing, you have to implement it.

If you spend your "very little free time" on such discussions instead, 
you are not only wasting the time you could spend on implementing what 
you are thinking of but also the limited time of other developers.

> Regards

cu
Adrian

-- 

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

Re: OSS driver removal, 2nd round (v2)

[Adrian Bunk]

On Tue, Jul 11, 2006 at 11:08:10AM +0200, Adam Tlałka wrote:
> On Tue, 11 Jul 2006 09:58:26 +0200 (CEST)
> Jaroslav Kysela <perex@suse.cz> wrote:
>...
> > You're a bit mixing things:
> > 
> > a) we're not trying to be more compatible than OSS code in kernel, if you 
> >    like to do the mixing in kernel, simply write a new ALSA lowlevel 
> >    driver which will do it; I'm sure when the quality of your code will be 
> >    good,  we'll include it to the ALSA tree, but we are not going this
> >    way unless someone else will maintain this code
> 
> OSS kernel compatibility is only partial and aoss method is not fully compatible either

Except for some corner cases, ALSA is capable of emulating the 
in-kernel OSS.

And considering the low number of applications that are still OSS-only, 
I doubt it's really that important improving the OSS emulation even 
further.

But this is open source software, so feel free to send patches.

> I will try to write some code but I have very little free time for that so I am trying
> to convince people to rethinking the case 
>...

This is not how open source software works.

If you think something is missing, you have to implement it.

If you spend your "very little free time" on such discussions instead, 
you are not only wasting the time you could spend on implementing what 
you are thinking of but also the limited time of other developers.

> Regards

cu
Adrian

-- 

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



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Diego Calleja]

El Tue, 11 Jul 2006 11:52:56 +0200 (CEST),
Jaroslav Kysela <perex@suse.cz> escribió:


> > Kernel redirector is not a bad solution - there should be some kind of 
> > interface for such redirectors for different purposes. netlink device 
> > maybe? For example you should redirect all these traffic to some RT 
> > daemon doing all job.
> 
> I would prefer probably a network lowlevel ALSA driver. You'll get the 
> network transparency as benefit.


Shouldn't the plan9 filesystem (the implementation merged in Linux) be able
to do networking transparency already? It should be able to export /dev
devices nodes through the network transparently, AFAIK.

Re: OSS driver removal, 2nd round (v2)

[Diego Calleja]

El Tue, 11 Jul 2006 11:52:56 +0200 (CEST),
Jaroslav Kysela <perex@suse.cz> escribió:


> > Kernel redirector is not a bad solution - there should be some kind of 
> > interface for such redirectors for different purposes. netlink device 
> > maybe? For example you should redirect all these traffic to some RT 
> > daemon doing all job.
> 
> I would prefer probably a network lowlevel ALSA driver. You'll get the 
> network transparency as benefit.


Shouldn't the plan9 filesystem (the implementation merged in Linux) be able
to do networking transparency already? It should be able to export /dev
devices nodes through the network transparently, AFAIK.


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Tue, 11 Jul 2006 11:52:56 +0200 (CEST)
Jaroslav Kysela <perex@suse.cz> wrote:

> On Tue, 11 Jul 2006, Adam Tlałka wrote:
> 
> > OSS kernel compatibility is only partial and aoss method is not fully 
> 
> Partial? Elaborate please. And talk about OSS drivers in 2.6 kernel.

I don't remember the case exactly - original OSS as stated in pdf describing
its behaviour locks buffer size after some ioctls. So you can't change parameters
unless you do reset or reopen the device. aoss does it differently.
Also aoss has no mixer ioctls working with audio stream fd implemented.

> > > b) you're requestion to avoid scheduler participation in the audio 
> > >    processing and yes, we have this solution already (dmix), but not in 
> > >    kernel
> > 
> > just the contrary - scheduler participation is needed to avoid sound 
> > distortion and missing samples
> 
> Nope. You're missing that dmix does not add any extra latencies, because
> samples are written directly to the DMA buffer.

That is true but it is a process (thread exactly but in Linux world it is a special kind of process) so it can be scheduled down or swapped off.
 
> > > c) as you said, the kernel should contain only critical code to drive
> > >    hardware, sample rate conversion, sample format conversions and so on
> > >    are NOT part of this code in my opinion
> > 
> > if doing this operations behind application back can lead to not delivering
> > data to kernel driver in time then these are time critical operations too!
> 
> Sorry, but you have limited resources (CPU power). It's completely 
> irrelevant, if you do processing in the user space or in kernel (in my 
> opinion it's even worse to do such things in the interrupt context).
> It's probably better to think how to instruct scheduler to wake up
> the sound applications as soon as possible.

If I have enough resources to do this in kernel space and obtain good results
why not do it?

> > > > ALSA in lib way has its limitations and drawbacks and adding more 
> > > > feaures this way leads to more complications only IMHO.
> > > 
> > > Which limitations? We can do all things like OSS API. The whole point of 
> > > all problems is that OSS has the API entry point in syscalls which is 
> > > quite bad so the redirection is problematic.
> > 
> > Yes but what a complicated way. And you cannot use kernel OSS emulation
> > and ALSA aware apps at the same time. Also aoss with dmix are in
> > conflict with jackd for example.
> 
> ??? Elaborate. It should work.

There was reports of jack mixing problems with dmix active. Proposed solution was to use jack attached directly to alsa hw device and not to the default.

> 
> > Kernel redirector is not a bad solution - there should be some kind of 
> > interface for such redirectors for different purposes. netlink device 
> > maybe? For example you should redirect all these traffic to some RT 
> > daemon doing all job.
> 
> I would prefer probably a network lowlevel ALSA driver. You'll get the 
> network transparency as benefit.
>

Quite nice conception.
 
> > Same with filesystem redirections. I hate these special gnomevfs or kdeio
> > helpers which forces to rebuilding apps with more and more libs.
> > Change LD_PRELOAD or LD_LIBRARY_PATH and you app will go to hell.
> > This is the Windows way of doing uncontrolled mess.
> > This plugin architecture without mandatory kernel access control leads
> > to serious security risc.
> 
> Unfortunately, more functionality requires more code. You have to deal 
> with bloating the user or kernel space.

Of course.

As I said it could be done by a small kernel message passing redirector connected
to a bloated user space RT process which does the rest. But some kernel support for proper waking up, rescheduling etc. is a must.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl

Re: OSS driver removal, 2nd round (v2)

[Adam Tlałka]

On Tue, 11 Jul 2006 11:52:56 +0200 (CEST)
Jaroslav Kysela <perex@suse.cz> wrote:

> On Tue, 11 Jul 2006, Adam Tlałka wrote:
> 
> > OSS kernel compatibility is only partial and aoss method is not fully 
> 
> Partial? Elaborate please. And talk about OSS drivers in 2.6 kernel.

I don't remember the case exactly - original OSS as stated in pdf describing
its behaviour locks buffer size after some ioctls. So you can't change parameters
unless you do reset or reopen the device. aoss does it differently.
Also aoss has no mixer ioctls working with audio stream fd implemented.

> > > b) you're requestion to avoid scheduler participation in the audio 
> > >    processing and yes, we have this solution already (dmix), but not in 
> > >    kernel
> > 
> > just the contrary - scheduler participation is needed to avoid sound 
> > distortion and missing samples
> 
> Nope. You're missing that dmix does not add any extra latencies, because
> samples are written directly to the DMA buffer.

That is true but it is a process (thread exactly but in Linux world it is a special kind of process) so it can be scheduled down or swapped off.
 
> > > c) as you said, the kernel should contain only critical code to drive
> > >    hardware, sample rate conversion, sample format conversions and so on
> > >    are NOT part of this code in my opinion
> > 
> > if doing this operations behind application back can lead to not delivering
> > data to kernel driver in time then these are time critical operations too!
> 
> Sorry, but you have limited resources (CPU power). It's completely 
> irrelevant, if you do processing in the user space or in kernel (in my 
> opinion it's even worse to do such things in the interrupt context).
> It's probably better to think how to instruct scheduler to wake up
> the sound applications as soon as possible.

If I have enough resources to do this in kernel space and obtain good results
why not do it?

> > > > ALSA in lib way has its limitations and drawbacks and adding more 
> > > > feaures this way leads to more complications only IMHO.
> > > 
> > > Which limitations? We can do all things like OSS API. The whole point of 
> > > all problems is that OSS has the API entry point in syscalls which is 
> > > quite bad so the redirection is problematic.
> > 
> > Yes but what a complicated way. And you cannot use kernel OSS emulation
> > and ALSA aware apps at the same time. Also aoss with dmix are in
> > conflict with jackd for example.
> 
> ??? Elaborate. It should work.

There was reports of jack mixing problems with dmix active. Proposed solution was to use jack attached directly to alsa hw device and not to the default.

> 
> > Kernel redirector is not a bad solution - there should be some kind of 
> > interface for such redirectors for different purposes. netlink device 
> > maybe? For example you should redirect all these traffic to some RT 
> > daemon doing all job.
> 
> I would prefer probably a network lowlevel ALSA driver. You'll get the 
> network transparency as benefit.
>

Quite nice conception.
 
> > Same with filesystem redirections. I hate these special gnomevfs or kdeio
> > helpers which forces to rebuilding apps with more and more libs.
> > Change LD_PRELOAD or LD_LIBRARY_PATH and you app will go to hell.
> > This is the Windows way of doing uncontrolled mess.
> > This plugin architecture without mandatory kernel access control leads
> > to serious security risc.
> 
> Unfortunately, more functionality requires more code. You have to deal 
> with bloating the user or kernel space.

Of course.

As I said it could be done by a small kernel message passing redirector connected
to a bloated user space RT process which does the rest. But some kernel support for proper waking up, rescheduling etc. is a must.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Tue, 11 Jul 2006 08:15:28 +0200, Adam =?ISO-8859-2?B?VGxhs2th?= said:
> On Mon, 10 Jul 2006 22:09:51 -0400
> Valdis.Kletnieks@vt.edu wrote:
> 
> > On Tue, 11 Jul 2006 01:38:39 +0200, =?ISO-8859-2?Q?Adam_Tla=B3ka?= said:
> > > U¿ytkownik Lee Revell napisa³:
> > >
> > > > esd and artsd are no longer needed since ALSA began to enable software
> > > > mixing by default in release 1.0.9.
> > >  >
> > > 
> > > So why they are still exist in so many Linux distributions?
> > 
> > As soon as somebody writes a patch to make the e16 window manager talk ALSA
> > rather than use esd, I'm heaving esd over the side.
> 
> Sorry to say but it is just not that way. Window manager is for managing windows
> and it shouldn't depend on any audio system. It should use an external app using exec call
> to play sounds (aplay, sox, wavplay etc.) configured by some config option.

So what you're saying is that something like 'esd' *is* needed.  (It's
certainly silly to keep doing fork/exec for every little sound sample when
you can just leave the app running and hand it requests...)

Either ALSA is up to the task, or it isn't and needs a front-end program
to babysit it. It doesn't matter if the program trying to play the sound
is a window manager, or an e-mail program, or something else....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: OSS driver removal, 2nd round (v2)

[Valdis.Kletnieks]

[-- Attachment #1.1: Type: text/plain, Size: 1315 bytes --]

On Tue, 11 Jul 2006 08:15:28 +0200, Adam =?ISO-8859-2?B?VGxhs2th?= said:
> On Mon, 10 Jul 2006 22:09:51 -0400
> Valdis.Kletnieks@vt.edu wrote:
> 
> > On Tue, 11 Jul 2006 01:38:39 +0200, =?ISO-8859-2?Q?Adam_Tla=B3ka?= said:
> > > U¿ytkownik Lee Revell napisa³:
> > >
> > > > esd and artsd are no longer needed since ALSA began to enable software
> > > > mixing by default in release 1.0.9.
> > >  >
> > > 
> > > So why they are still exist in so many Linux distributions?
> > 
> > As soon as somebody writes a patch to make the e16 window manager talk ALSA
> > rather than use esd, I'm heaving esd over the side.
> 
> Sorry to say but it is just not that way. Window manager is for managing windows
> and it shouldn't depend on any audio system. It should use an external app using exec call
> to play sounds (aplay, sox, wavplay etc.) configured by some config option.

So what you're saying is that something like 'esd' *is* needed.  (It's
certainly silly to keep doing fork/exec for every little sound sample when
you can just leave the app running and hand it requests...)

Either ALSA is up to the task, or it isn't and needs a front-end program
to babysit it. It doesn't matter if the program trying to play the sound
is a window manager, or an e-mail program, or something else....

[-- Attachment #1.2: Type: application/pgp-signature, Size: 226 bytes --]

[-- Attachment #2: Type: text/plain, Size: 375 bytes --]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 161 bytes --]

_______________________________________________
Alsa-devel mailing list
Alsa-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Lee Revell]

On Tue, 2006-07-11 at 10:30 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 11 Jul 2006 08:15:28 +0200, Adam =?ISO-8859-2?B?VGxhs2th?= said:
> > Sorry to say but it is just not that way. Window manager is for managing windows
> > and it shouldn't depend on any audio system. It should use an external app using exec call
> > to play sounds (aplay, sox, wavplay etc.) configured by some config option.
> 
> So what you're saying is that something like 'esd' *is* needed.  (It's
> certainly silly to keep doing fork/exec for every little sound sample when
> you can just leave the app running and hand it requests...)

That approach also won't be reliable as it ignores the realtime
constraint that is inherent in audio playback.  It will probably work on
a fast/lightly loaded machine but will glitch out under load.

It's how GDM plays startup/shutdown sounds and it sucks - on shutdown
the sound is choppy.  You either need a dedicated daemon running
SCHED_FIFO or an RT thread for reliable audio playback.

Lee

Re: OSS driver removal, 2nd round (v2)

[Lee Revell]

On Tue, 2006-07-11 at 10:30 -0400, Valdis.Kletnieks@vt.edu wrote:
> On Tue, 11 Jul 2006 08:15:28 +0200, Adam =?ISO-8859-2?B?VGxhs2th?= said:
> > Sorry to say but it is just not that way. Window manager is for managing windows
> > and it shouldn't depend on any audio system. It should use an external app using exec call
> > to play sounds (aplay, sox, wavplay etc.) configured by some config option.
> 
> So what you're saying is that something like 'esd' *is* needed.  (It's
> certainly silly to keep doing fork/exec for every little sound sample when
> you can just leave the app running and hand it requests...)

That approach also won't be reliable as it ignores the realtime
constraint that is inherent in audio playback.  It will probably work on
a fast/lightly loaded machine but will glitch out under load.

It's how GDM plays startup/shutdown sounds and it sucks - on shutdown
the sound is choppy.  You either need a dedicated daemon running
SCHED_FIFO or an RT thread for reliable audio playback.

Lee



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: [Alsa-devel] OSS driver removal, 2nd round (v2)

[Adam Tlałka]

Użytkownik Lee Revell napisał:
> On Tue, 2006-07-11 at 10:30 -0400, Valdis.Kletnieks@vt.edu wrote:
>> On Tue, 11 Jul 2006 08:15:28 +0200, Adam =?ISO-8859-2?B?VGxhs2th?= said:
>>> Sorry to say but it is just not that way. Window manager is for managing windows
>>> and it shouldn't depend on any audio system. It should use an external app using exec call
>>> to play sounds (aplay, sox, wavplay etc.) configured by some config option.
>> So what you're saying is that something like 'esd' *is* needed.  (It's
>> certainly silly to keep doing fork/exec for every little sound sample when
>> you can just leave the app running and hand it requests...)
> 
> That approach also won't be reliable as it ignores the realtime
> constraint that is inherent in audio playback.  It will probably work on
> a fast/lightly loaded machine but will glitch out under load.

Yes, that is true. It was just simple example how you can get simple 
sound effects without many lines of code. In case of heavy load or too 
many events in short period of time this method is not working correctly 
but this is not the main functionality of a window manager program.
Anyway you can aggregate events if there are too many of them and play 
only one sound or not play anything at all. For this kind of program
it is quite acceptable and not breaks main functionality.

> It's how GDM plays startup/shutdown sounds and it sucks - on shutdown
> the sound is choppy.  You either need a dedicated daemon running
> SCHED_FIFO or an RT thread for reliable audio playback.

True - and that makes things more complicated. I don't know if it is 
worth it just for bells and whistles. In other cases you do need to 
program more sophisticated sound support and RT thread probably will be 
your solution. Or some kind of sound server which holds your sound 
samples so you can fire them at the proper time.
ALSA lib is a low level library. Sometimes we need more abstract 
functions like load(s, "sound.wav) and then play(s) without bothering 
about all these parameters settings. So maybe OpenAL is a some kind of a 
solution but I don't know its current status.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl

Re: OSS driver removal, 2nd round (v2)

[Adam Tlałka]

Użytkownik Lee Revell napisał:
> On Tue, 2006-07-11 at 10:30 -0400, Valdis.Kletnieks@vt.edu wrote:
>> On Tue, 11 Jul 2006 08:15:28 +0200, Adam =?ISO-8859-2?B?VGxhs2th?= said:
>>> Sorry to say but it is just not that way. Window manager is for managing windows
>>> and it shouldn't depend on any audio system. It should use an external app using exec call
>>> to play sounds (aplay, sox, wavplay etc.) configured by some config option.
>> So what you're saying is that something like 'esd' *is* needed.  (It's
>> certainly silly to keep doing fork/exec for every little sound sample when
>> you can just leave the app running and hand it requests...)
> 
> That approach also won't be reliable as it ignores the realtime
> constraint that is inherent in audio playback.  It will probably work on
> a fast/lightly loaded machine but will glitch out under load.

Yes, that is true. It was just simple example how you can get simple 
sound effects without many lines of code. In case of heavy load or too 
many events in short period of time this method is not working correctly 
but this is not the main functionality of a window manager program.
Anyway you can aggregate events if there are too many of them and play 
only one sound or not play anything at all. For this kind of program
it is quite acceptable and not breaks main functionality.

> It's how GDM plays startup/shutdown sounds and it sucks - on shutdown
> the sound is choppy.  You either need a dedicated daemon running
> SCHED_FIFO or an RT thread for reliable audio playback.

True - and that makes things more complicated. I don't know if it is 
worth it just for bells and whistles. In other cases you do need to 
program more sophisticated sound support and RT thread probably will be 
your solution. Or some kind of sound server which holds your sound 
samples so you can fire them at the proper time.
ALSA lib is a low level library. Sometimes we need more abstract 
functions like load(s, "sound.wav) and then play(s) without bothering 
about all these parameters settings. So maybe OpenAL is a some kind of a 
solution but I don't know its current status.

Regards
-- 
Adam Tlałka       mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

Re: OSS driver removal, 2nd round (v2)

[Lee Revell]

On Wed, 2006-07-12 at 00:31 +0200, Adam Tlałka wrote:
> True - and that makes things more complicated. I don't know if it is 
> worth it just for bells and whistles. In other cases you do need to 
> program more sophisticated sound support and RT thread probably will be 
> your solution. Or some kind of sound server which holds your sound 
> samples so you can fire them at the proper time.
> ALSA lib is a low level library. Sometimes we need more abstract 
> functions like load(s, "sound.wav) and then play(s) without bothering 
> about all these parameters settings. So maybe OpenAL is a some kind of a 
> solution but I don't know its current status.

Let's remove linux-kernel from the CC list, as this thread is now OT.

Lee



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

OSS driver removal, 2nd round (v2)

[Adrian Bunk]

Now that I've sent the first round of actually removing the code for OSS 
drivers where ALSA drivers without regressions exist for the same 
hardware, it's time for a second round amongst the remaining drivers.


Removing OSS drivers where ALSA drivers for the same hardware exists has 
two reasons:

1. remove obsolete and mostly unmaintained code
2. get bugs in the ALSA drivers reported that weren't previously
   reported due to the possible workaround of using the OSS drivers


The list below divides the OSS drivers into the following three
categories:
1. ALSA drivers for the same hardware
2. ALSA drivers for the same hardware with known problems
3. no ALSA drivers for the same hardware


My proposed timeline is:
- 2.6.18: let the drivers under 1. in the list below depend on
          OSS_OBSOLETE_DRIVER
- 2.6.20: remove the options depending on OSS_OBSOLETE_DRIVER
- 2.6.22: remove the code for the drivers that were depending on
          OSS_OBSOLETE_DRIVER from the kernel tree


To make a long story short:

If you are using an OSS driver because the ALSA driver doesn't work 
equally well on your hardware listed under 1. below, send me an email 
with a bug number in the ALSA bug tracking system now.


A small FAQ:

Q: But OSS is kewl and ALSA sucks!
A: The decision for the OSS->ALSA move was four years ago.
   If ALSA sucks, please help to improve ALSA.

Q: What about the OSS emulation in ALSA?
A: The OSS emulation in ALSA is not affected by my patches
   (and it's not in any way scheduled for removal).


Please review the following list:


1. ALSA drivers for the same hardware

DMASOUND_PMAC
SOUND_ACI_MIXER and RADIO_MIROPCM20
SOUND_AD1816
SOUND_AD1889
SOUND_ADLIB
SOUND_FUSION
SOUND_NM256
SOUND_OPL3SA2

2. ALSA drivers for the same hardware with known problems

SOUND_CS4232
- ALSA #1520 (Soundchip was not detected on HP Omnibook 5700 CTX)

SOUND_EMU10K1
- ALSA #1782 (really poor sound with my SB Live 1024 and ALSA)

SOUND_ES1371
- ALSA #1774 (missing joystick connector support for PCI Ensoniq ES1371)

SOUND_ICH
- ALSA #1764 (Recording signal quality is inacceptable (using OSS API))
- Alan Cox:
  ALSA driver lacks "support for AC97 wired touchscreens and the like"

SOUND_SSCAPE
- ALSA #2234 (driver does not find Soundscape Elite)

SOUND_TRIDENT
- ALSA #1293 (device supported by OSS but not by ALSA)
- maintainer of the OSS driver wants his driver to stay

SOUND_VIA82CXXX
- ALSA #1906 (1-second overruns reported by arecord,
              complete system hang with jackd -d alsa)


3. no ALSA drivers for the same hardware

DMASOUND_ATARI
DMASOUND_PAULA
DMASOUND_Q40
SOUND_AEDSP16
SOUND_AU1550_AC97
SOUND_BCM_CS4297A
SOUND_HAL2
SOUND_KAHLUA
SOUND_MSNDCLAS
SOUND_MSNDPIN
SOUND_MSS (also due to SOUND_PSS, SOUND_TRIX and perhaps SOUND_AEDSP16)
SOUND_PAS
SOUND_PSS
SOUND_SB (also due to SOUND_KAHLUA, SOUND_PAS and perhaps SOUND_AEDSP16)
SOUND_SH_DAC_AUDIO
SOUND_TRIX
SOUND_VIDC
SOUND_VRC5477
SOUND_VWSND
SOUND_WAVEARTIST

SOUND_IT8172
Ralf Baechle: 
Both board based on the ITE 8172 chipset are on my death list already; I
will probably remove it after 2.6.18 is out unless against all expectation
I receive patches.



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642