[2.6 patch] schedule obsolete OSS drivers for removal

[2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

This patch schedules obsolete OSS drivers (with ALSA drivers that 
support the same hardware) for removal.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
or more of these drivers, and I've also Cc'ed the ALSA people.

Please tell if any my driver selections is wrong.

 Documentation/feature-removal-schedule.txt |    7 +
 sound/oss/Kconfig                          |   79 ++++++++++++---------
 2 files changed, 54 insertions(+), 32 deletions(-)

--- linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt.old	2005-07-26 16:50:05.000000000 +0200
+++ linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt	2005-07-26 16:51:24.000000000 +0200
@@ -44,0 +45,7 @@
+What:	drivers depending on OBSOLETE_OSS_DRIVER
+When:	October 2005
+Why:	OSS drivers with ALSA replacements
+Who:	Adrian Bunk <bunk@stusta.de>
+
+---------------------------
+
--- linux-2.6.13-rc3-mm1-modular/sound/oss/Kconfig.old	2005-07-23 21:04:56.000000000 +0200
+++ linux-2.6.13-rc3-mm1-modular/sound/oss/Kconfig	2005-07-24 01:22:11.000000000 +0200
@@ -4,9 +4,24 @@
 # More hacking for modularisation.
 #
 # Prompt user for primary drivers.
+
+config OBSOLETE_OSS_DRIVER
+	bool "Obsolete OSS drivers"
+	depends on SOUND_PRIME
+	help
+	  This patch enables support for obsolete OSS drivers that
+	  are scheduled for removal in the near future since there
+	  are ALSA drivers for the same hardware.
+
+	  Please contact Adrian Bunk <bunk@stusta.de> if you had to
+	  say Y here because your soundcard is not properly supported
+	  by ALSA.
+
+	  If unsure, say N.
+
 config SOUND_BT878
 	tristate "BT878 audio dma"
-	depends on SOUND_PRIME
+	depends on SOUND_PRIME && OBSOLETE_OSS_DRIVER
 	---help---
 	  Audio DMA support for bt878 based grabber boards.  As you might have
 	  already noticed, bt878 is listed with two functions in /proc/pci.
@@ -22,7 +37,7 @@
 
 config SOUND_CMPCI
 	tristate "C-Media PCI (CMI8338/8738)"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a PCI sound card using the CMI8338
 	  or the CMI8738 chipset.  Data on these chips are available at
@@ -61,7 +76,7 @@
 
 config SOUND_EMU10K1
 	tristate "Creative SBLive! (EMU10K1)"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	---help---
 	  Say Y or M if you have a PCI sound card using the EMU10K1 chipset,
 	  such as the Creative SBLive!, SB PCI512 or Emu-APS.
@@ -95,7 +110,7 @@
 
 config SOUND_CS4281
 	tristate "Crystal Sound CS4281"
-	depends on SOUND_PRIME
+	depends on SOUND_PRIME && OBSOLETE_OSS_DRIVER
 	help
 	  Picture and feature list at
 	  <http://www.pcbroker.com/crystal4281.html>.
@@ -112,7 +127,7 @@
 
 config SOUND_ES1370
 	tristate "Ensoniq AudioPCI (ES1370)"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a PCI sound card utilizing the Ensoniq
 	  ES1370 chipset, such as Ensoniq's AudioPCI (non-97). To find
@@ -125,7 +140,7 @@
 
 config SOUND_ES1371
 	tristate "Creative Ensoniq AudioPCI 97 (ES1371)"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a PCI sound card utilizing the Ensoniq
 	  ES1371 chipset, such as Ensoniq's AudioPCI97. To find out if
@@ -138,7 +153,7 @@
 
 config SOUND_ESSSOLO1
 	tristate "ESS Technology Solo1" 
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a PCI sound card utilizing the ESS Technology
 	  Solo1 chip. To find out if your sound card uses a
@@ -149,7 +164,7 @@
 
 config SOUND_MAESTRO
 	tristate "ESS Maestro, Maestro2, Maestro2E driver"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a sound system driven by ESS's Maestro line
 	  of PCI sound chips.  These include the Maestro 1, Maestro 2, and
@@ -158,28 +173,28 @@
 
 config SOUND_MAESTRO3
 	tristate "ESS Maestro3/Allegro driver (EXPERIMENTAL)"
-	depends on SOUND_PRIME && PCI && EXPERIMENTAL
+	depends on SOUND_PRIME && PCI && EXPERIMENTAL && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a sound system driven by ESS's Maestro 3
 	  PCI sound chip.
 
 config SOUND_ICH
 	tristate "Intel ICH (i8xx) audio support"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Support for integral audio in Intel's I/O Controller Hub (ICH)
 	  chipset, as used on the 810/820/840 motherboards.
 
 config SOUND_HARMONY
 	tristate "PA Harmony audio driver"
-	depends on GSC_LASI && SOUND_PRIME
+	depends on GSC_LASI && SOUND_PRIME && OBSOLETE_OSS_DRIVER
 	help
 	  Say 'Y' or 'M' to include support for Harmony soundchip
 	  on HP 712, 715/new and many other GSC based machines.
 
 config SOUND_SONICVIBES
 	tristate "S3 SonicVibes"
-	depends on SOUND_PRIME
+	depends on SOUND_PRIME && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a PCI sound card utilizing the S3
 	  SonicVibes chipset. To find out if your sound card uses a
@@ -218,7 +233,7 @@
 
 config SOUND_AU1000
 	tristate "Au1000 Sound"
-	depends on SOUND_PRIME && (SOC_AU1000 || SOC_AU1100 || SOC_AU1500)
+	depends on SOUND_PRIME && (SOC_AU1000 || SOC_AU1100 || SOC_AU1500) && OBSOLETE_OSS_DRIVER
 
 config SOUND_AU1550_AC97
 	tristate "Au1550 AC97 Sound"
@@ -492,7 +507,7 @@
 
 config SOUND_VIA82CXXX
 	tristate "VIA 82C686 Audio Codec"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y here to include support for the audio codec found on VIA
 	  82Cxxx-based chips. Typically these are built into a motherboard.
@@ -546,7 +561,7 @@
 
 config SOUND_AD1816
 	tristate "AD1816(A) based cards (EXPERIMENTAL)"
-	depends on EXPERIMENTAL && SOUND_OSS
+	depends on EXPERIMENTAL && SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  Say M here if you have a sound card based on the Analog Devices
 	  AD1816(A) chip.
@@ -563,7 +578,7 @@
 
 config SOUND_SGALAXY
 	tristate "Aztech Sound Galaxy (non-PnP) cards"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  This module initializes the older non Plug and Play sound galaxy
 	  cards from Aztech. It supports the Waverider Pro 32 - 3D and the
@@ -599,7 +614,7 @@
 
 config SOUND_CS4232
 	tristate "Crystal CS4232 based (PnP) cards"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y here if you have a card based on the Crystal CS4232 chip set,
 	  which uses its own Plug and Play protocol.
@@ -613,7 +628,7 @@
 
 config SOUND_SSCAPE
 	tristate "Ensoniq SoundScape support"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  Answer Y if you have a sound card based on the Ensoniq SoundScape
 	  chipset. Such cards are being manufactured at least by Ensoniq, Spea
@@ -625,7 +640,7 @@
 
 config SOUND_GUS
 	tristate "Gravis Ultrasound support"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y here for any type of Gravis Ultrasound card, including the GUS
 	  or GUS MAX.  See also <file:Documentation/sound/oss/ultrasound> for more
@@ -727,7 +742,7 @@
 
 config SOUND_NM256
 	tristate "NM256AV/NM256ZX audio support"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  Say M here to include audio support for the NeoMagic 256AV/256ZX
 	  chipsets. These are the audio chipsets found in the Sony
@@ -739,7 +754,7 @@
 
 config SOUND_MAD16
 	tristate "OPTi MAD16 and/or Mozart based cards"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	---help---
 	  Answer Y if your card has a Mozart (OAK OTI-601) or MAD16 (OPTi
 	  82C928 or 82C929 or 82C931) audio interface chip. These chips are
@@ -860,7 +875,7 @@
 
 config SOUND_AWE32_SYNTH
 	tristate "AWE32 synth"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y here if you have a Sound Blaster SB32, AWE32-PnP, SB AWE64 or
 	  similar sound card. See <file:Documentation/sound/oss/README.awe>,
@@ -870,7 +885,7 @@
 
 config SOUND_WAVEFRONT
 	tristate "Full support for Turtle Beach WaveFront (Tropez Plus, Tropez, Maui) synth/soundcards"
-	depends on SOUND_OSS && m
+	depends on SOUND_OSS && m && OBSOLETE_OSS_DRIVER
 	help
 	  Answer Y or M if you have a Tropez Plus, Tropez or Maui sound card
 	  and read the files <file:Documentation/sound/oss/Wavefront> and
@@ -878,7 +893,7 @@
 
 config SOUND_MAUI
 	tristate "Limited support for Turtle Beach Wave Front (Maui, Tropez) synthesizers"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y here if you have a Turtle Beach Wave Front, Maui, or Tropez
 	  sound card.
@@ -904,7 +919,7 @@
 
 config SOUND_YM3812
 	tristate "Yamaha FM synthesizer (YM3812/OPL-3) support"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	---help---
 	  Answer Y if your card has a FM chip made by Yamaha (OPL2/OPL3/OPL4).
 	  Answering Y is usually a safe and recommended choice, however some
@@ -920,7 +935,7 @@
 
 config SOUND_OPL3SA1
 	tristate "Yamaha OPL3-SA1 audio controller"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a Yamaha OPL3-SA1 sound chip, which is
 	  usually built into motherboards. Read
@@ -932,7 +947,7 @@
 
 config SOUND_OPL3SA2
 	tristate "Yamaha OPL3-SA2 and SA3 based PnP cards"
-	depends on SOUND_OSS
+	depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a card based on one of these Yamaha sound
 	  chipsets or the "SAx", which is actually a SA3. Read
@@ -946,7 +961,7 @@
 
 config SOUND_YMFPCI
 	tristate "Yamaha YMF7xx PCI audio (native mode)"
-	depends on SOUND_OSS && PCI
+	depends on SOUND_OSS && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Support for Yamaha cards including the YMF711, YMF715, YMF718,
 	  YMF719, YMF724, Waveforce 192XG, and Waveforce 192 Digital.
@@ -1088,11 +1103,11 @@
 
 config SOUND_ALI5455
 	tristate "ALi5455 audio support"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 
 config SOUND_FORTE
 	tristate "ForteMedia FM801 driver"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you want driver support for the ForteMedia FM801 PCI
 	  audio controller (Abit AU10, Genius Sound Maker, HP Workstation
@@ -1100,7 +1115,7 @@
 
 config SOUND_RME96XX
 	tristate "RME Hammerfall (RME96XX) support"
-	depends on SOUND_PRIME && PCI
+	depends on SOUND_PRIME && PCI && OBSOLETE_OSS_DRIVER
 	help
 	  Say Y or M if you have a Hammerfall or Hammerfall light
 	  multichannel card from RME. If you want to access advanced
@@ -1108,7 +1123,7 @@
 
 config SOUND_AD1980
 	tristate "AD1980 front/back switch plugin"
-	depends on SOUND_PRIME
+	depends on SOUND_PRIME && OBSOLETE_OSS_DRIVER
 
 config SOUND_SH_DAC_AUDIO
 	tristate "SuperH DAC audio support"

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

[Jesper Juhl]

On 7/26/05, Adrian Bunk <bunk@stusta.de> wrote:
> This patch schedules obsolete OSS drivers (with ALSA drivers that
> support the same hardware) for removal.
> 
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> ---
> 
> I've Cc'ed the people listed in MAINTAINERS as being responsible for one
> or more of these drivers, and I've also Cc'ed the ALSA people.
> 
> Please tell if any my driver selections is wrong.
> 
>  Documentation/feature-removal-schedule.txt |    7 +
>  sound/oss/Kconfig                          |   79 ++++++++++++---------
>  2 files changed, 54 insertions(+), 32 deletions(-)
> 
> --- linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt.old    2005-07-26 16:50:05.000000000 +0200
> +++ linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt        2005-07-26 16:51:24.000000000 +0200
> @@ -44,0 +45,7 @@
> +What:  drivers depending on OBSOLETE_OSS_DRIVER
> +When:  October 2005
> +Why:   OSS drivers with ALSA replacements
> +Who:   Adrian Bunk <bunk@stusta.de>
> +
> +---------------------------
> +
> --- linux-2.6.13-rc3-mm1-modular/sound/oss/Kconfig.old  2005-07-23 21:04:56.000000000 +0200
> +++ linux-2.6.13-rc3-mm1-modular/sound/oss/Kconfig      2005-07-24 01:22:11.000000000 +0200
> @@ -4,9 +4,24 @@
>  # More hacking for modularisation.
>  #
>  # Prompt user for primary drivers.
> +
> +config OBSOLETE_OSS_DRIVER
> +       bool "Obsolete OSS drivers"
> +       depends on SOUND_PRIME
> +       help
> +         This patch enables support for obsolete OSS drivers that

                      s/patch/option/  ???

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

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

[Adrian Bunk]

On Tue, Jul 26, 2005 at 05:41:31PM +0200, Jesper Juhl wrote:
>...
> > +         This patch enables support for obsolete OSS drivers that
> 
>                       s/patch/option/  ???

Sure.

I'll correct this before resending the patch.

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: [2.6 patch] schedule obsolete OSS drivers for removal

[Thomas Sailer]

On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
> This patch schedules obsolete OSS drivers (with ALSA drivers that 
> support the same hardware) for removal.
> 
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Thomas Sailer <sailer@ife.ee.ethz.ch>

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

[Jeff Garzik]

Adrian Bunk wrote:
> This patch schedules obsolete OSS drivers (with ALSA drivers that 
> support the same hardware) for removal.
> 
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> ---
> 
> I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
> or more of these drivers, and I've also Cc'ed the ALSA people.
> 
> Please tell if any my driver selections is wrong.
> 
>  Documentation/feature-removal-schedule.txt |    7 +
>  sound/oss/Kconfig                          |   79 ++++++++++++---------
>  2 files changed, 54 insertions(+), 32 deletions(-)

Please CHECK before doing this.

ACK for via82cxxx.

NAK for i810_audio:  ALSA doesn't have all the PCI IDs (which must be 
verified -- you cannot just add the PCI IDs for some hardware)

	Jeff

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

[Adrian Bunk]

On Tue, Jul 26, 2005 at 11:48:04AM -0400, Jeff Garzik wrote:
> Adrian Bunk wrote:
> >This patch schedules obsolete OSS drivers (with ALSA drivers that 
> >support the same hardware) for removal.
> >
> >
> >Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >
> >---
> >
> >I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
> >or more of these drivers, and I've also Cc'ed the ALSA people.
> >
> >Please tell if any my driver selections is wrong.
> >
> > Documentation/feature-removal-schedule.txt |    7 +
> > sound/oss/Kconfig                          |   79 ++++++++++++---------
> > 2 files changed, 54 insertions(+), 32 deletions(-)
> 
> Please CHECK before doing this.

I did (but I don't claim that I didn't miss anything).

> ACK for via82cxxx.

Thanks.

> NAK for i810_audio:  ALSA doesn't have all the PCI IDs (which must be 
> verified -- you cannot just add the PCI IDs for some hardware)

I though I found every single PCI ID from this driver in ALSA.
Which PCI IDs did I miss?

> 	Jeff

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: [2.6 patch] schedule obsolete OSS drivers for removal

[Lee Revell]

On Tue, 2005-07-26 at 11:48 -0400, Jeff Garzik wrote:
> NAK for i810_audio:  ALSA doesn't have all the PCI IDs (which must be 
> verified -- you cannot just add the PCI IDs for some hardware)

Some of them might be in snd-hda-intel in addition to snd-intel8x0.

Lee

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

[John W. Linville]

On Tue, Jul 26, 2005 at 12:49:46PM -0400, Lee Revell wrote:
> On Tue, 2005-07-26 at 11:48 -0400, Jeff Garzik wrote:
> > NAK for i810_audio:  ALSA doesn't have all the PCI IDs (which must be 
> > verified -- you cannot just add the PCI IDs for some hardware)
> 
> Some of them might be in snd-hda-intel in addition to snd-intel8x0.

Hmmm...I don't think that would work.  If there are IDs listed in
both i810_audio and snd-hda-intel, it is probably a mistake.

John
-- 
John W. Linville
linville@tuxdriver.com

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

[Gene Heskett]

On Tuesday 26 July 2005 11:48, Jeff Garzik wrote:
>Adrian Bunk wrote:
>> This patch schedules obsolete OSS drivers (with ALSA drivers that
>> support the same hardware) for removal.
>>
>>
>> Signed-off-by: Adrian Bunk <bunk@stusta.de>
>>
>> ---
>>
>> I've Cc'ed the people listed in MAINTAINERS as being responsible
>> for one or more of these drivers, and I've also Cc'ed the ALSA
>> people.
>>
>> Please tell if any my driver selections is wrong.
>>
>>  Documentation/feature-removal-schedule.txt |    7 +
>>  sound/oss/Kconfig                          |   79
>> ++++++++++++--------- 2 files changed, 54 insertions(+), 32
>> deletions(-)
>
>Please CHECK before doing this.
>
>ACK for via82cxxx.

I'm still running a box that needs this one.  The darned thing refuses 
to die. :)

>NAK for i810_audio:  ALSA doesn't have all the PCI IDs (which must
> be verified -- you cannot just add the PCI IDs for some hardware)
>
> Jeff
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

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

[Adrian Bunk]

On Tue, Jul 26, 2005 at 01:03:39PM -0400, Gene Heskett wrote:
> On Tuesday 26 July 2005 11:48, Jeff Garzik wrote:
> >Adrian Bunk wrote:
> >> This patch schedules obsolete OSS drivers (with ALSA drivers that
> >> support the same hardware) for removal.
> >>
> >>
> >> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> >>
> >> ---
> >>
> >> I've Cc'ed the people listed in MAINTAINERS as being responsible
> >> for one or more of these drivers, and I've also Cc'ed the ALSA
> >> people.
> >>
> >> Please tell if any my driver selections is wrong.
> >>
> >>  Documentation/feature-removal-schedule.txt |    7 +
> >>  sound/oss/Kconfig                          |   79
> >> ++++++++++++--------- 2 files changed, 54 insertions(+), 32
> >> deletions(-)
> >
> >Please CHECK before doing this.
> >
> >ACK for via82cxxx.
> 
> I'm still running a box that needs this one.  The darned thing refuses 
> to die. :)
>...


Why doesn't the ALSA driver work for you?


> Cheers, Gene


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: [2.6 patch] schedule obsolete OSS drivers for removal

[Gene Heskett]

On Tuesday 26 July 2005 14:13, Adrian Bunk wrote:
>On Tue, Jul 26, 2005 at 01:03:39PM -0400, Gene Heskett wrote:
>> On Tuesday 26 July 2005 11:48, Jeff Garzik wrote:
>> >Adrian Bunk wrote:
>> >> This patch schedules obsolete OSS drivers (with ALSA drivers
>> >> that support the same hardware) for removal.
[...]
>> >ACK for via82cxxx.
>>
>> I'm still running a box that needs this one.  The darned thing
>> refuses to die. :)
>>...
>
>Why doesn't the ALSA driver work for you?

Humm, I missread that it was OSS you were talking about, my bad.

I'll go quietly officer. :(

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

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

[Lee Revell]

On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
> This patch schedules obsolete OSS drivers (with ALSA drivers that 
> support the same hardware) for removal.

How many non-obsolete OSS drivers were there?

Lee

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

[Jeff Garzik]

Lee Revell wrote:
> On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
> 
>>This patch schedules obsolete OSS drivers (with ALSA drivers that 
>>support the same hardware) for removal.
> 
> 
> How many non-obsolete OSS drivers were there?

someone needs to test the remaining PCI ID(s) that are in i810_audio but 
not ALSA.

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

[Lee Revell]

On Tue, 2005-07-26 at 11:57 -0400, Jeff Garzik wrote:
> Lee Revell wrote:
> > On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
> > 
> >>This patch schedules obsolete OSS drivers (with ALSA drivers that 
> >>support the same hardware) for removal.
> > 
> > 
> > How many non-obsolete OSS drivers were there?
> 
> someone needs to test the remaining PCI ID(s) that are in i810_audio but 
> not ALSA.
> 

Good luck finding someone with all that old hardware...

Lee

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

[Adrian Bunk]

On Tue, Jul 26, 2005 at 11:57:04AM -0400, Jeff Garzik wrote:
> Lee Revell wrote:
> >On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
> >
> >>This patch schedules obsolete OSS drivers (with ALSA drivers that 
> >>support the same hardware) for removal.
> >
> >
> >How many non-obsolete OSS drivers were there?
> 
> someone needs to test the remaining PCI ID(s) that are in i810_audio but 
> not ALSA.

I've grep'ed a second time for every single PCI ID in the OSS 
i810_audio, and I still haven't found WTF you are talking about.

Once again my question:

I though I found every single PCI ID from this driver in ALSA.
Which PCI IDs did I miss?

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: [2.6 patch] schedule obsolete OSS drivers for removal

[John W. Linville]

On Wed, Jul 27, 2005 at 08:24:28PM +0200, Adrian Bunk wrote:

> I've grep'ed a second time for every single PCI ID in the OSS 
> i810_audio, and I still haven't found WTF you are talking about.

I looked as well, and I found nothing either.

Jeff, can you enlighten us?

John
-- 
John W. Linville
linville@tuxdriver.com

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

[Jeff Garzik]

John W. Linville wrote:
> On Wed, Jul 27, 2005 at 08:24:28PM +0200, Adrian Bunk wrote:
> 
> 
>>I've grep'ed a second time for every single PCI ID in the OSS 
>>i810_audio, and I still haven't found WTF you are talking about.
> 
> 
> I looked as well, and I found nothing either.
> 
> Jeff, can you enlighten us?


ISTR Alan saying there was some ALi hardware that either wasn't in ALSA, 
or most likely didn't work in ALSA.  If Alan says I'm smoking crack, 
then you all can ignore me :)

	Jeff

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

[Alan Cox]

On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
> ISTR Alan saying there was some ALi hardware that either wasn't in ALSA, 
> or most likely didn't work in ALSA.  If Alan says I'm smoking crack, 
> then you all can ignore me :)

The only big thing I know that still needed OSS (and may still do so) is
the support for AC97 wired touchscreens and the like. Has that been
ported to ALSA ?

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

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Alan Cox wrote:

> On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
> > ISTR Alan saying there was some ALi hardware that either wasn't in ALSA, 
> > or most likely didn't work in ALSA.  If Alan says I'm smoking crack, 
> > then you all can ignore me :)
> 
> The only big thing I know that still needed OSS (and may still do so) is
> the support for AC97 wired touchscreens and the like. Has that been
> ported to ALSA ?

We're working on this issue right now.

						Jaroslav

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

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

[Adrian Bunk]

On Thu, Jul 28, 2005 at 03:43:49PM +0200, Jaroslav Kysela wrote:
> On Thu, 28 Jul 2005, Alan Cox wrote:
> 
> > On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
> > > ISTR Alan saying there was some ALi hardware that either wasn't in ALSA, 
> > > or most likely didn't work in ALSA.  If Alan says I'm smoking crack, 
> > > then you all can ignore me :)
> > 
> > The only big thing I know that still needed OSS (and may still do so) is
> > the support for AC97 wired touchscreens and the like. Has that been
> > ported to ALSA ?
> 
> We're working on this issue right now.

Does "right now" mean it will be done in a few days or a few months?

I'm asking because in the latter case I'll remove the driver from my 
current "scheduled for removal" list.

> 						Jaroslav

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: [2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

On Thu, Jul 28, 2005 at 03:43:49PM +0200, Jaroslav Kysela wrote:
> On Thu, 28 Jul 2005, Alan Cox wrote:
> 
> > On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
> > > ISTR Alan saying there was some ALi hardware that either wasn't in ALSA, 
> > > or most likely didn't work in ALSA.  If Alan says I'm smoking crack, 
> > > then you all can ignore me :)
> > 
> > The only big thing I know that still needed OSS (and may still do so) is
> > the support for AC97 wired touchscreens and the like. Has that been
> > ported to ALSA ?
> 
> We're working on this issue right now.

What's the current status of this issue?

> 						Jaroslav

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: [2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

On Tue, Jul 26, 2005 at 11:51:13AM -0400, Lee Revell wrote:
> On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
> > This patch schedules obsolete OSS drivers (with ALSA drivers that 
> > support the same hardware) for removal.
> 
> How many non-obsolete OSS drivers were there?

I haven't counted them, but there are still many.

> Lee

cu
Adrian

-- 

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

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

[Andrew Haninger]

On 7/26/05, Adrian Bunk <bunk@stusta.de> wrote:
>  config SOUND_OPL3SA2
>         tristate "Yamaha OPL3-SA2 and SA3 based PnP cards"
> -       depends on SOUND_OSS
> +       depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
>         help
>           Say Y or M if you have a card based on one of these Yamaha sound
>           chipsets or the "SAx", which is actually a SA3. Read
Forgive me if I'm misreading this (I'm hardly a coder and no kernel
hacker) but, as it stands, the OPL3SA2 driver provided by ALSA and the
main kernel tree work but are not correctly detected by ALSA's
detection routines (in alsaconf) on the 2.6 kernel. The OSS drivers
work, as well, but (AFAIK) there are no methods of automatic
configuration with the OSS drivers.

So, for people who don't feel like configuring ALSA with their OPL3SA2
card, the OSS modules may be easier to configure and thus should be
left in until the ALSA/2.6 kernel problems are worked out with the
OPL3SA2.

-Andy

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

[Adrian Bunk]

On Tue, Jul 26, 2005 at 12:17:14PM -0400, Andrew Haninger wrote:
> On 7/26/05, Adrian Bunk <bunk@stusta.de> wrote:
> >  config SOUND_OPL3SA2
> >         tristate "Yamaha OPL3-SA2 and SA3 based PnP cards"
> > -       depends on SOUND_OSS
> > +       depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
> >         help
> >           Say Y or M if you have a card based on one of these Yamaha sound
> >           chipsets or the "SAx", which is actually a SA3. Read
> Forgive me if I'm misreading this (I'm hardly a coder and no kernel
> hacker) but, as it stands, the OPL3SA2 driver provided by ALSA and the
> main kernel tree work but are not correctly detected by ALSA's
> detection routines (in alsaconf) on the 2.6 kernel. The OSS drivers
> work, as well, but (AFAIK) there are no methods of automatic
> configuration with the OSS drivers.
> 
> So, for people who don't feel like configuring ALSA with their OPL3SA2
> card, the OSS modules may be easier to configure and thus should be
> left in until the ALSA/2.6 kernel problems are worked out with the
> OPL3SA2.

This is kernel bug #3117 [1] / ALSA bug #879 [2]?

> -Andy

cu
Adrian

[1] http://bugzilla.kernel.org/show_bug.cgi?id=3117
[2] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=879

-- 

       "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: [2.6 patch] schedule obsolete OSS drivers for removal

[Zach Brown]

Adrian Bunk wrote:
> This patch schedules obsolete OSS drivers (with ALSA drivers that 
> support the same hardware) for removal.

> I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
> or more of these drivers, and I've also Cc'ed the ALSA people.

I haven't touched the maestro drivers in so long (for near-total lack of
docs, etc.) that I can't be considered authoritative for approving it's
removal.  If people are relying on it I certainly don't know who they
are.  In better news, Takashi should now have the pile of maestro
hardware that I used in the first pass to help him maintain the ALSA
driver..

- z

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

[Krzysztof Halasa]

Zach Brown <zab@zabbo.net> writes:

> I haven't touched the maestro drivers in so long (for near-total lack of
> docs, etc.) that I can't be considered authoritative for approving it's
> removal.

Maestro3 ALSA does work fine for me.
-- 
Krzysztof Halasa

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

[Zoran Dzelajlija]

Zach Brown <zab@zabbo.net> wrote:
> Adrian Bunk wrote:
> > This patch schedules obsolete OSS drivers (with ALSA drivers that 
> > support the same hardware) for removal.

> > I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
> > or more of these drivers, and I've also Cc'ed the ALSA people.

> I haven't touched the maestro drivers in so long (for near-total lack of
> docs, etc.) that I can't be considered authoritative for approving it's
> removal. If people are relying on it I certainly don't know who they
> are.  In better news, Takashi should now have the pile of maestro
> hardware that I used in the first pass to help him maintain the ALSA
> driver..

The OSS maestro driver works better on my old Armada E500 laptop.  I tried
ALSA after switching to 2.6, but the computer hung with 2.6.8.1 or 2.6.10 if
I touched the volume buttons.  With OSS they just work.  The four separate
dsp devices also look kind of more useful.

Zoran

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

[Lee Revell]

On Wed, 2005-07-27 at 01:38 +0200, Zoran Dzelajlija wrote:
> The OSS maestro driver works better on my old Armada E500 laptop.  I tried
> ALSA after switching to 2.6, but the computer hung with 2.6.8.1 or 2.6.10 if
> I touched the volume buttons.

Please test a newer ALSA version, like the one in 2.6.12.

Lee

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

[Rogério Brito]

On Jul 27 2005, Lee Revell wrote:
> On Wed, 2005-07-27 at 01:38 +0200, Zoran Dzelajlija wrote:
> > The OSS maestro driver works better on my old Armada E500 laptop.
> > I tried ALSA after switching to 2.6, but the computer hung with
> > 2.6.8.1 or 2.6.10 if I touched the volume buttons.
> 
> Please test a newer ALSA version, like the one in 2.6.12.

I have an Armada V300 laptop that uses the maestro2 chipset (and I
wouldn't be surprised if your E500 used that very same chip) and it
works fine with the ALSA provided in kernels since the 2.6.10-mm era
(actually, I think it worked fine with even earlier kernels, but I am
not sure).


Just another datapoint, Rogério.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

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

[Takashi Iwai]

At Wed, 27 Jul 2005 01:38:37 +0200,
Zoran Dzelajlija wrote:
> 
> Zach Brown <zab@zabbo.net> wrote:
> > Adrian Bunk wrote:
> > > This patch schedules obsolete OSS drivers (with ALSA drivers that 
> > > support the same hardware) for removal.
> 
> > > I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
> > > or more of these drivers, and I've also Cc'ed the ALSA people.
> 
> > I haven't touched the maestro drivers in so long (for near-total lack of
> > docs, etc.) that I can't be considered authoritative for approving it's
> > removal. If people are relying on it I certainly don't know who they
> > are.  In better news, Takashi should now have the pile of maestro
> > hardware that I used in the first pass to help him maintain the ALSA
> > driver..
> 
> The OSS maestro driver works better on my old Armada E500 laptop.  I tried
> ALSA after switching to 2.6, but the computer hung with 2.6.8.1 or 2.6.10 if
> I touched the volume buttons.  With OSS they just work.  The four separate
> dsp devices also look kind of more useful.

The bug around h/w volume control should have been fixed in the recent
version of ALSA drivers.  Hopefully everything will get merged into
2.6.13...


Takashi

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

[Adrian Bunk]

On Wed, Jul 27, 2005 at 01:38:37AM +0200, Zoran Dzelajlija wrote:
> Zach Brown <zab@zabbo.net> wrote:
> > Adrian Bunk wrote:
> > > This patch schedules obsolete OSS drivers (with ALSA drivers that 
> > > support the same hardware) for removal.
> 
> > > I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
> > > or more of these drivers, and I've also Cc'ed the ALSA people.
> 
> > I haven't touched the maestro drivers in so long (for near-total lack of
> > docs, etc.) that I can't be considered authoritative for approving it's
> > removal. If people are relying on it I certainly don't know who they
> > are.  In better news, Takashi should now have the pile of maestro
> > hardware that I used in the first pass to help him maintain the ALSA
> > driver..
> 
> The OSS maestro driver works better on my old Armada E500 laptop.  I tried
> ALSA after switching to 2.6, but the computer hung with 2.6.8.1 or 2.6.10 if
> I touched the volume buttons.  With OSS they just work.  The four separate
> dsp devices also look kind of more useful.

I've left it on the list of OSS drivers scheduled for removal based on 
Takashi's comment that the volume button problem should be fixed now.

If this problem is still present in 2.6.13-rc4, please open a bug at the 
ALSA bug tracking system [1] and tell me the bug number so that I can 
track it.

> Zoran

cu
Adrian

[1] https://bugtrack.alsa-project.org/alsa-bug/

-- 

       "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: [2.6 patch] schedule obsolete OSS drivers for removal

[Kyle McMartin]

On Tue, Jul 26, 2005 at 05:08:37PM +0200, Adrian Bunk wrote:
> This patch schedules obsolete OSS drivers (with ALSA drivers that 
> support the same hardware) for removal.

oss/harmony.c can probably go, unless someone from parisc-linux
objects. I've written a (working) replacement[1] for oss/ad1889.c
which is in our cvs, and will go upstream shortly. oss/ad1889.c
doesn't (and hasn't ever) worked, so it should probably be removed.

Stuart, Randolph, comments?

1. http://cvs.parisc-linux.org/linux-2.6/sound/pci/ad1889.c?rev=1.30&view=markup

Cheers,
-- 
Kyle McMartin

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

[Randolph Chung]

> Stuart, Randolph, comments?
> 
> 1. http://cvs.parisc-linux.org/linux-2.6/sound/pci/ad1889.c?rev=1.30&view=markup

sure, kill the OSS ad1889 driver.

randolph

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

[Adrian Bunk]

On Wed, Jul 27, 2005 at 02:39:42PM -0400, Kyle McMartin wrote:
> On Tue, Jul 26, 2005 at 05:08:37PM +0200, Adrian Bunk wrote:
> > This patch schedules obsolete OSS drivers (with ALSA drivers that 
> > support the same hardware) for removal.
> 
> oss/harmony.c can probably go, unless someone from parisc-linux
> objects. I've written a (working) replacement[1] for oss/ad1889.c
> which is in our cvs, and will go upstream shortly. oss/ad1889.c
> doesn't (and hasn't ever) worked, so it should probably be removed.
>...

:-)

The sooner your driver goes through the ALSA people in Linus' tree, the 
sooner we can schedule the OSS driver for removal.

> Cheers,
> Kyle McMartin

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: [2.6 patch] schedule obsolete OSS drivers for removal

[Thorsten Knabe]

On Tue, 26 Jul 2005, Adrian Bunk wrote:

> This patch schedules obsolete OSS drivers (with ALSA drivers that
> support the same hardware) for removal.

Hello Adrian.

I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two 
problems of the ALSA AD1816 driver, that do not show up with the OSS 
driver:
- According to my own experience and user reports audio is choppy with 
some VoIP Softphones like gnophone at least when used with the ALSA OSS 
emulation layer, whereas the OSS driver is crystal clear.
- Users reported, that on some HP Kayak systems the on-board AD1816A 
was not properly detected by the ALSA driver or was detected, but 
there was no audio output. I'm not sure if the problem is still present in 
the current ALSA driver, as I do not own such a system.

Maybe the OSS driver should stay in the kernel, until those problems are 
fixed in the ALSA driver.

Regards
Thorsten

-- 
___
  |        | /                 E-Mail: linux@thorsten-knabe.de
  |horsten |/\nabe                WWW: http://linux.thorsten-knabe.de

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

[Adrian Bunk]

On Thu, Jul 28, 2005 at 05:04:20PM +0200, Thorsten Knabe wrote:
> On Tue, 26 Jul 2005, Adrian Bunk wrote:
> 
> >This patch schedules obsolete OSS drivers (with ALSA drivers that
> >support the same hardware) for removal.
> 
> Hello Adrian.

Hi Thorsten,

> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two 
> problems of the ALSA AD1816 driver, that do not show up with the OSS 
> driver:
> - According to my own experience and user reports audio is choppy with 
> some VoIP Softphones like gnophone at least when used with the ALSA OSS 
> emulation layer, whereas the OSS driver is crystal clear.
> - Users reported, that on some HP Kayak systems the on-board AD1816A 
> was not properly detected by the ALSA driver or was detected, but 
> there was no audio output. I'm not sure if the problem is still present in 
> the current ALSA driver, as I do not own such a system.
> 
> Maybe the OSS driver should stay in the kernel, until those problems are 
> fixed in the ALSA driver.

thanks for this note, I'll drop the AD1816 driver from my list.

> Regards
> Thorsten

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: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Lee Revell]

On Thu, 2005-07-28 at 17:04 +0200, Thorsten Knabe wrote:
> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two 
> problems of the ALSA AD1816 driver, that do not show up with the OSS 
> driver:
> - According to my own experience and user reports audio is choppy with 
> some VoIP Softphones like gnophone at least when used with the ALSA OSS 
> emulation layer, whereas the OSS driver is crystal clear.
> - Users reported, that on some HP Kayak systems the on-board AD1816A 
> was not properly detected by the ALSA driver or was detected, but 
> there was no audio output. I'm not sure if the problem is still present in 
> the current ALSA driver, as I do not own such a system.

What are the bug id #s in the ALSA BTS?  If it's not in the bug tracker
it's never going to get fixed.

Lee

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

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Thorsten Knabe wrote:

> On Tue, 26 Jul 2005, Adrian Bunk wrote:
> 
> > This patch schedules obsolete OSS drivers (with ALSA drivers that
> > support the same hardware) for removal.
> 
> Hello Adrian.
> 
> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two 
> problems of the ALSA AD1816 driver, that do not show up with the OSS 
> driver:
> - According to my own experience and user reports audio is choppy with 
>   some VoIP Softphones like gnophone at least when used with the ALSA 
>   OSS emulation layer, whereas the OSS driver is crystal clear.
> - Users reported, that on some HP Kayak systems the on-board AD1816A was 
>   not properly detected by the ALSA driver or was detected, but there 
>   was no audio output. I'm not sure if the problem is still present in 
>   the current ALSA driver, as I do not own such a system.
> 
> Maybe the OSS driver should stay in the kernel, until those problems are 
> fixed in the ALSA driver.

The problem is that nobody reported us mentioned problems. We have no 
bug-report regarding the AD1816A driver. Perhaps, it would be a good idea 
to add a notice to the help file and/or driver that the ALSA driver should 
be tested and bugs reported to the ALSA bug-tracking-system.

					Thanks,
						Jaroslav

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

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

[Adrian Bunk]

On Fri, Jul 29, 2005 at 08:52:45AM +0200, Jaroslav Kysela wrote:
> 
> The problem is that nobody reported us mentioned problems. We have no 
> bug-report regarding the AD1816A driver. Perhaps, it would be a good idea 
> to add a notice to the help file and/or driver that the ALSA driver should 
> be tested and bugs reported to the ALSA bug-tracking-system.

Although it wouldn't have helped with this driver, could you review the 
currently 35 open ALSA bugs in the kernel Bugzilla [1]?

- Some might first require a question to the submitter whether the
  problem is still present in recent kernels.
- Some might be problems in other parts of the kernel
  (e.g. ACPI interrupt configuration problems).
- But some bugs might be bugs still present in recent ALSA.

The Gentoo people are using a pretty easy and nice way for forwarding 
their bugs to the kernel Bugzilla, that would work the following way for 
forwarding Bugs from the kernel Bugzilla to the ALSA BTS:
- open a new bug in the ALSA BTS:
  - short description of the issue
  - more information is at 
      http://bugzilla.kernel.org/show_bug.cgi?id=12345
- add a comment to the kernel Bugzilla (but leave the bug open):
    this bug is now handled at the ALSA BTS at 
    https://bugtrack.alsa-project.org/alsa-bug/view.php?id=23456

You could also do this the other way round if e.g. a ACPI interrupt 
configuration problem was reported to the ALSA BTS.

> 					Thanks,
> 						Jaroslav

cu
Adrian

[1] http://bugzilla.kernel.org/

-- 

       "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: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Thorsten Knabe]

On Fri, 29 Jul 2005, Jaroslav Kysela wrote:

> On Thu, 28 Jul 2005, Thorsten Knabe wrote:
>
>> On Tue, 26 Jul 2005, Adrian Bunk wrote:
>>
>>> This patch schedules obsolete OSS drivers (with ALSA drivers that
>>> support the same hardware) for removal.
>>
>> Hello Adrian.
>>
>> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two
>> problems of the ALSA AD1816 driver, that do not show up with the OSS
>> driver:
>> - According to my own experience and user reports audio is choppy with
>>   some VoIP Softphones like gnophone at least when used with the ALSA
>>   OSS emulation layer, whereas the OSS driver is crystal clear.
>> - Users reported, that on some HP Kayak systems the on-board AD1816A was
>>   not properly detected by the ALSA driver or was detected, but there
>>   was no audio output. I'm not sure if the problem is still present in
>>   the current ALSA driver, as I do not own such a system.
>>
>> Maybe the OSS driver should stay in the kernel, until those problems are
>> fixed in the ALSA driver.
>
> The problem is that nobody reported us mentioned problems. We have no
> bug-report regarding the AD1816A driver. Perhaps, it would be a good idea
> to add a notice to the help file and/or driver that the ALSA driver should
> be tested and bugs reported to the ALSA bug-tracking-system.

Hello Jaroslav.

I'll do some testing during the upcoming weekend to confirm, that the 
mentioned problems still exist with the current ALSA release. Last time I 
checked was sometime around Linux 2.6.10. I'll file a bug report of my 
findings to the ALSA bug tracking system and contact the author of the 
driver. Initially I had not spent much time on those problems, because I 
had an alternative working OSS driver, but since removal of the OSS seems 
to get closer, it's probably time to fix these issues now.

Regards
Thorsten

-- 
___
  |        | /                 E-Mail: linux@thorsten-knabe.de
  |horsten |/\nabe                WWW: http://linux.thorsten-knabe.de

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

[Adrian Bunk]

On Fri, Jul 29, 2005 at 05:58:18PM +0200, Thorsten Knabe wrote:
> 
> Hello Jaroslav.
> 
> I'll do some testing during the upcoming weekend to confirm, that the 
> mentioned problems still exist with the current ALSA release. Last time I 
> checked was sometime around Linux 2.6.10. I'll file a bug report of my 
> findings to the ALSA bug tracking system and contact the author of the 
> driver. Initially I had not spent much time on those problems, because I 
> had an alternative working OSS driver, but since removal of the OSS seems 
> to get closer, it's probably time to fix these issues now.

Thanks a lot!

Can you send me the bug numbers in the ALSA bug tracking system if you 
have to send bug reports, so that I can track when these issues will be 
resolved?

> Regards
> Thorsten

TIA
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: [Alsa-devel] Re: [2.6 patch] schedule obsolete OSS drivers for removal

[Andrew Haninger]

On 7/31/05, Adrian Bunk <bunk@stusta.de> wrote:
> Can you send me the bug numbers in the ALSA bug tracking system if you
> have to send bug reports, so that I can track when these issues will be
> resolved?
Thorsten: Please remember to include the list(s) when emailing those
links/numbers. I'd like to be able to watch it, too, and add any
information that I can, rather than entering a duplicate bug.

Thanks.

-Andy

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

[Thorsten Knabe]

On Mon, 1 Aug 2005, Andrew Haninger wrote:

> Thorsten: Please remember to include the list(s) when emailing those
> links/numbers. I'd like to be able to watch it, too, and add any
> information that I can, rather than entering a duplicate bug.

Hello.

I have taken a closer look at the ALSA AD1816 sound driver during the last 
weekend. Here are my findings:

On vanilla Linux 2.6.12.3 and 2.6.13-rc4 modprobe hangs in D-state when 
loading the snd-ad1816a module. No messages have been logged to the syslog 
and the system is otherwise stable. Of course the sound card is unusable.
On Linux 2.6.8 (as shipped with current Debian Sarge), vanilla Linux 
2.6.10 and Linux 2.6.11.12 the module loads fine.

I have done some tests with xmms(Debian), kphone(VoIP-Phone/Debian) and 
iaxcomm(VoIP-Phone/self-made). Audio playback with xmms is always fine 
using either ALSA or OSS emulation. Using OSS emulation with one of the 
VoIP phones, playback and recording stop a few seconds after the call is 
started. Using the ALSA interface with kphone works, but there is a 
continuous clicking approximately 3 times per second. Also audio latency 
is poor compared to the OSS driver. iaxcomm does not support the ALSA 
audio interface, thus no problems here. :-)
The native OSS driver is fine on all kernels with all tested applications.

Also the ALSA driver does not have an equivalent for the 
"ad1816_clockfreq" option of the OSS driver. The AD1816 chip requires a 
33MHz reference clock, however some cards use a different (mostly 
32.125MHz) clock, thus the audio sample rate has to be corrected before it 
is written to the hardware registers for proper playback and recording 
speed.

I have not filed any bug reports to the ALSA bug tracking system so far, 
but will do so tomorrow and add the corresponding bug numbers to this 
thread.

Thorsten

-- 
___
  |        | /                 E-Mail: linux@thorsten-knabe.de
  |horsten |/\nabe                WWW: http://linux.thorsten-knabe.de

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

[Lee Revell]

On Tue, 2005-08-02 at 02:13 +0200, Thorsten Knabe wrote:
> Using OSS emulation with one of the 
> VoIP phones

Are you referring to the in-kernel OSS emulation, or the alsa-lib
emulation ("aoss ./app")?

Lee

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

[James Courtier-Dutton]

Thorsten Knabe wrote:

> On Mon, 1 Aug 2005, Andrew Haninger wrote:
>
>> Thorsten: Please remember to include the list(s) when emailing those
>> links/numbers. I'd like to be able to watch it, too, and add any
>> information that I can, rather than entering a duplicate bug.
>
>
> Hello.
>
> I have taken a closer look at the ALSA AD1816 sound driver during the 
> last weekend. Here are my findings:
>
> On vanilla Linux 2.6.12.3 and 2.6.13-rc4 modprobe hangs in D-state 
> when loading the snd-ad1816a module. No messages have been logged to 
> the syslog and the system is otherwise stable. Of course the sound 
> card is unusable.
> On Linux 2.6.8 (as shipped with current Debian Sarge), vanilla Linux 
> 2.6.10 and Linux 2.6.11.12 the module loads fine.
>
> I have done some tests with xmms(Debian), kphone(VoIP-Phone/Debian) 
> and iaxcomm(VoIP-Phone/self-made). Audio playback with xmms is always 
> fine using either ALSA or OSS emulation. Using OSS emulation with one 
> of the VoIP phones, playback and recording stop a few seconds after 
> the call is started. Using the ALSA interface with kphone works, but 
> there is a continuous clicking approximately 3 times per second. Also 
> audio latency is poor compared to the OSS driver. iaxcomm does not 
> support the ALSA audio interface, thus no problems here. :-)
> The native OSS driver is fine on all kernels with all tested 
> applications.
>
> Also the ALSA driver does not have an equivalent for the 
> "ad1816_clockfreq" option of the OSS driver. The AD1816 chip requires 
> a 33MHz reference clock, however some cards use a different (mostly 
> 32.125MHz) clock, thus the audio sample rate has to be corrected 
> before it is written to the hardware registers for proper playback and 
> recording speed.
>
> I have not filed any bug reports to the ALSA bug tracking system so 
> far, but will do so tomorrow and add the corresponding bug numbers to 
> this thread.
>
> Thorsten
>
It sounds to me that the best way to fix this is either:
a) Detect sound card subversion number and select different clock based 
on that.
b) Some how auto detect the clock, much like the intel8x0 driver does.
c) Provide a manual option like the OSS driver. (We should probably have 
this as well as (a) for the cases where (a) does not know about 
particular soundcard X yet.

James

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

[Thorsten Knabe]

Hello.

Here are the bug id's for the various issues from the ALSA bugtracking 
system:

On Tue, 2 Aug 2005, Thorsten Knabe wrote:
> On vanilla Linux 2.6.12.3 and 2.6.13-rc4 modprobe hangs in D-state when 
> loading the snd-ad1816a module. No messages have been logged to the syslog 
> and the system is otherwise stable. Of course the sound card is unusable.

#1300: modprobe goes into D-state when inserting snd-ad1816a

> Using OSS emulation with one of the VoIP 
> phones, playback and recording stop a few seconds after the call is started. 
> Using the ALSA interface with kphone works, but there is a continuous 
> clicking approximately 3 times per second. Also audio latency is poor 
> compared to the OSS driver.

#1301: Kernel OSS emulation stops working after a few seconds when used 
with VoIP softphones

#1302: Clicking noise when using kphone with the ALSA AD1816A sound driver

> Also the ALSA driver does not have an equivalent for the "ad1816_clockfreq" 
> option of the OSS driver.

#1303: AD1816A sound driver has no parameter to adjust reference clock 
frequency

Regards
Thorsten

-- 
___
  |        | /                 E-Mail: linux@thorsten-knabe.de
  |horsten |/\nabe                WWW: http://linux.thorsten-knabe.de

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

[James Courtier-Dutton]

Adrian Bunk wrote:
> This patch schedules obsolete OSS drivers (with ALSA drivers that 
> support the same hardware) for removal.
> 
> 
> Signed-off-by: Adrian Bunk <bunk@stusta.de>
> 
> ---
> 
> I've Cc'ed the people listed in MAINTAINERS as being responsible for one 
> or more of these drivers, and I've also Cc'ed the ALSA people.
> 

I am happy for the emu10k1 OSS driver to go.
The ALSA driver has considerably more features now.

James

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

[Andi Kleen]

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

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

This means ac97_codec.c also has to stay.

-Andi

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

[Alistair John Strachan]

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

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

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

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

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

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

-- 
Cheers,
Alistair.

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

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

[Andi Kleen]

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

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

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

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

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

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

Avoiding bloat is more important.

-Andi

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

[David Lang]

On Tue, 3 Jan 2006, Andi Kleen wrote:

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

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

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

David Lang

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

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

[Alistair John Strachan]

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

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

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

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

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

-- 
Cheers,
Alistair.

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

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

[Alistair John Strachan]

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

-- 
Cheers,
Alistair.

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

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

[Alistair John Strachan]

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

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

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

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

Okay, fair point.

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

I can't agree with that.

-- 
Cheers,
Alistair.

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

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

[Lee Revell]

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

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

Lee

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

[Pete Zaitcev]

On Tue, 3 Jan 2006 14:01:40 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:

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

If ALSA's OSS emulator does not support mixing properly, it's a bug
in ALSA, clearly, because real OSS in 2.4 allowed for mixing, as long
as the hardware supported it. I played Doom while listening to MP3s on
ymfpci (which, in fact, was a copy of ALSA's ymfpci with OSS API on top).

If ALSA developers wanted, they could have supported mixing in their OSS
emulator. They intentionally chose not to, in order to create an incentive
for developers to program in native ALSA.

-- Pete

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

[Jaroslav Kysela]

On Wed, 4 Jan 2006, Pete Zaitcev wrote:

> On Tue, 3 Jan 2006 14:01:40 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> 
> > Is multiple-source mixing really a "high end" requirement? When I last 
> > checked, the OSS driver didn't support multiple applications claiming it at 
> > once, thus requiring you to use "more bloat" like esound, arts, or some other 
> > crap to access your soundcard more than once at any given time.
> 
> If ALSA's OSS emulator does not support mixing properly, it's a bug
> in ALSA, clearly, because real OSS in 2.4 allowed for mixing, as long
> as the hardware supported it. I played Doom while listening to MP3s on
> ymfpci (which, in fact, was a copy of ALSA's ymfpci with OSS API on top).
> 
> If ALSA developers wanted, they could have supported mixing in their OSS
> emulator. They intentionally chose not to, in order to create an incentive
> for developers to program in native ALSA.

You're in a mistake. ALSA supported multi-open feature for the hardware 
capable devices as first before any OSS drivers and it's available for the 
OSS emulation, too.

The thread is about simple hardware without this capability, so the mixing 
must be processed in software.

						Jaroslav

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

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

[Jan Engelhardt]

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

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


Jan Engelhardt
-- 

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

[Alistair John Strachan]

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

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

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

-- 
Cheers,
Alistair.

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

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

[Jan Engelhardt]

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

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



Jan Engelhardt
-- 

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

[Alistair John Strachan]

On Tuesday 03 January 2006 14:50, Jan Engelhardt wrote:
> >The problem with using OSS compatibility, at least on this machine with
> > ALSA 1.0.9, is that if you use it you automatically lose the software
> > mixing capabilities of ALSA, so it really is less than ideal.
>
> Well, I am able to open /dev/dsp multiple times here without problems.
> (Is /dev/dsp soft- or hardmixing?)

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

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

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

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

And on another terminal

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

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

[alistair] 15:20 [~/Music/Led Zeppelin - I] ogg123 -q --device=oss 01\ -\ 
Good\ Times\ Bad\ Times.ogg
Error: Cannot open device oss.

In fact, ogg123 hangs at this point (oh dear). If I try what you suggested and 
play two OSS sources, this doesn't work either:

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

Works, but then:

ogg123 -q --device=oss 01\ -\ Good\ Times\ Bad\ Times.ogg
Error: Cannot open device oss

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

-- 
Cheers,
Alistair.

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

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

[Tomasz Torcz]

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

On Tue, Jan 03, 2006 at 03:22:06PM +0000, Alistair John Strachan wrote:
> On Tuesday 03 January 2006 14:50, Jan Engelhardt wrote:
> > >The problem with using OSS compatibility, at least on this machine with
> > > ALSA 1.0.9, is that if you use it you automatically lose the software
> > > mixing capabilities of ALSA, so it really is less than ideal.
> >
> > Well, I am able to open /dev/dsp multiple times here without problems.
> > (Is /dev/dsp soft- or hardmixing?)
> 
> As far as I'm aware, it depends on your hardware. For example, software mixing 
> kicks in with zero configuration on most hardware that won't mix in hardware, 
> e.g. my laptop's i810 audio.
> 
> [alistair] 15:18 [~] cat /proc/asound/cards
> 0 [I82801DBICH4   ]: ICH4 - Intel 82801DB-ICH4
>                      Intel 82801DB-ICH4 with AD1981B at 0xa0100000, irq 11
> 1 [Modem          ]: ICH-MODEM - Intel 82801DB-ICH4 Modem
>                      Intel 82801DB-ICH4 Modem at 0x3400, irq 11
> 
> I can successfully hear two mixed sources when I execute the following:
> 
> ogg123 -q --device=alsa09 01\ -\ Good\ Times\ Bad\ Times.ogg
> 
> And on another terminal
> 
> ogg123 -q --device=alsa09 01\ -\ Good\ Times\ Bad\ Times.og
> 
> This is ALSA soft mixing the two sources for me. Very nifty. However, if I 
> throw an OSS into the mix (whilst these other two are playing).
> 
> [alistair] 15:20 [~/Music/Led Zeppelin - I] ogg123 -q --device=oss 01\ -\ 
> Good\ Times\ Bad\ Times.ogg
> Error: Cannot open device oss.

 Proper way (using userspace OSS emulation):
aoss ogg123 -q --device=oss [...]

-- 
Tomasz Torcz                "Funeral in the morning, IDE hacking
zdzichu@irc.-nie.spam-.pl    in the afternoon and evening." - Alan Cox


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

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

[Alistair John Strachan]

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

I'm aware of this.

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

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

-- 
Cheers,
Alistair.

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

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

[Olivier Galibert]

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

Especially not with plugins.  Flashplayer anybody?


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

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

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

  OG.

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

[Alistair John Strachan]

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

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

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

This argument is basically watered down with devfs, udev, sysfs, etc. which 
all have exactly the same issues. Should a crippled OSS API be the way 
forward for Linux? I think not.
 
> Also, not everybody wants to depend on a shared library.  I find this
> "the alsa lib must be kept in lockstep with the kernel version" quite
> annoying.  I'd rather not have the windows dll hell on linux, TYVM.
> Or in other words, the public API of a kernel interface should _NEVER_
> be a library only.  At least OSS, with all its issues, had that right.

Okay, I agree it's not ideal. But if you want software mixing, and it's a 
genuinely useful feature, you either have to go down the road of running some 
crappy daemon like arts or esound, or just link against libasound and get it 
for free. I know I'd rather not have mixing routines in my kernel, thanks.

-- 
Cheers,
Alistair.

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

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

[Olivier Galibert]

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

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

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


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

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

Then at system startup and through udev you can start whatever mixers,
sequencers, virtual interfaces and stuff you want.  Applications don't
need to care, and you don't have the amusing security issues around
what happens when different users want to use the sound card at the
same time.

  OG.

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

[Adrian Bunk]

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

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

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

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

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

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

>   OG.

cu
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: [2.6 patch] schedule obsolete OSS drivers for removal

[Olivier Galibert]

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

OSS _drivers_ yes, OSS _api_ no.


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

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


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

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

  OG.

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

[Tomasz Kłoczko]

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

On Tue, 3 Jan 2006, Adrian Bunk wrote:

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

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

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

2) ALSA API is to complicated: most applications opens single sound
   stream.
   All what system user expect it is plaing sound by more then one
   application with simple mixing sound streams. For me ALSA is prepared
   like for handle ANY sound case .. EXCEPT all most simpler.

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

# lsmod | grep ^snd | wc -l
19

   All this for handle ONLY ONE sound card. Why not one alsa main module
   and one with hardware backend module like in comarcial OSS ?

   ALSA is also requires much more bigger code size than OSS variant
   (count all snd* modules size, jackd and libasound and compare this with
   OSS modules and user space OSS library size). Simillar is on allocated
   memory in all system sound components.
   Many task switches incurred by the current ALSA architecture
   add quickly up to perceivalble deleys during processing. In many cases
   sound must be handled with RT piorites so all code sise must possible
   small for handle this with minimal latency.

4) ALSA mixing model is UNSECURE by design because all mixing sound
   streams (for example with diffrent sampling rates) are performed
   in user space.
   Also using jackd also "creates problems" with RTing this proccess and
   much more bigger problems on configure stage (for joe user).
   All this can be handled in secure and proprer RT prioprities
   ONLY on kernel space (so all gaming mith jackd or so is plain waste
   of time). Only on kernel level is possible correctly handle all this.
   With ALSA you can't extend in esy way for example SELinux for prevent
   intercept sound streem from microphone by remote user. Current OSS API
   is much more better for SELinux.
   Why ? because all mixing on OSS is performed on kernel level.

   I can't understand why ALSA developers still do not understands this
   fundamentalt facts.

5) OSS API can be used not only on Linux. ALSA API can be used ONLY on
   Linux.
   This was, still is and (looks like allways) will be main reason
   for not spending so many time as it is required on polish sound
   interractions on Linux applications.
   Still I can't understand why introducing ALSA *must* break OSS user
   space API in so deep way.
   OSS user space API also have some weak poinst on to big complications
   because it allow implemet the same cases in to many forms (for some
   cases it provides more than two ways for handle some scenarios).
   I do not understand why on developing Linux soud support was forgoten
   "don't move .. improve" sentence :>
   OSS API paralelism looks lik was "correctly" implemnted in ALSA .. so
   ALSA do not improves sound handling for user space applications and
   additionaly introduces other own complications (ASA API documentations
   in many cases isn't clear).

Conclution: removing OSS from Linux kernel and force using ALSA in last 
four years was IMO one of the main resons why Linux still can't 
effectively fight on desktop area and in future will be/can be one of the 
most importand weak point which can drive Linux to die at all (in longer 
period).

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

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

[Thomas Sailer]

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

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

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

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

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


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

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

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

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

Tom

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

[Olivier Galibert]

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

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

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

  OG.

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

[Jan Engelhardt]

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

Seconded.

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

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

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

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

> Many task switches incurred by the current ALSA architecture
> add quickly up to perceivalble deleys during processing. In many cases
> sound must be handled with RT piorites so all code sise must possible
> small for handle this with minimal latency.
>
> 4) ALSA mixing model is UNSECURE by design because all mixing sound
> streams (for example with diffrent sampling rates) are performed
> in user space.
>
I'd rather have libasound segfault rather than my kernel oopsing, in case
someone forgot a NULL check.

> Also using jackd also "creates problems" with RTing this proccess and
> much more bigger problems on configure stage (for joe user).
> All this can be handled in secure and proprer RT prioprities
> ONLY on kernel space (so all gaming mith jackd or so is plain waste
> of time). Only on kernel level is possible correctly handle all this.
> With ALSA you can't extend in esy way for example SELinux for prevent
> intercept sound streem from microphone by remote user. Current OSS API
> is much more better for SELinux.
> Why ? because all mixing on OSS is performed on kernel level.
>
AFAICS, OSS does not do mixing at all in its current state.



Jan Engelhardt
-- 

[OT] ALSA userspace API complexity

[Alistair John Strachan]

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

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

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

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

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

-- 
Cheers,
Alistair.

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

Re: [OT] ALSA userspace API complexity

[Pete Zaitcev]

On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:

> > 2) ALSA API is to complicated: most applications opens single sound
> >    stream.
> 
> FUD and nonsense. []
> http://devzero.co.uk/~alistair/alsa/

That's the kicker, isn't it? Once you get used to it, it's a workable
API, if kinky and verbose. I have a real life example, too:
 http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
But arriving on the solution costed a lot of torn hair. Look at this
bald head here! And who is going to pay my medical bills when ALSA
causes me ulcers, Jaroslav?

-- Pete

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Wed, 4 Jan 2006, Pete Zaitcev wrote:

> On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> 
> > > 2) ALSA API is to complicated: most applications opens single sound
> > >    stream.
> > 
> > FUD and nonsense. []
> > http://devzero.co.uk/~alistair/alsa/
> 
> That's the kicker, isn't it? Once you get used to it, it's a workable
> API, if kinky and verbose. I have a real life example, too:
>  http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
> But arriving on the solution costed a lot of torn hair. Look at this
> bald head here! And who is going to pay my medical bills when ALSA
> causes me ulcers, Jaroslav?

Well, the ALSA primary goal is to be the complete HAL not hidding the 
extra hardware capabilities to applications. So API might look a bit 
complicated for the first glance, but the ALSA interface code for simple 
applications is not so big, isn't?

Also, note that app developers are not forced to use ALSA directly - there 
is a lot of "portable" sound API libraries having an ALSA backend doing
this job quite effectively. We can add a simple (like OSS) API layer 
into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
some support functions for the easy PCM device initialization might be
a good idea.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Pete Zaitcev]

On Wed, 4 Jan 2006 12:35:25 +0100 (CET), Jaroslav Kysela <perex@suse.cz> wrote:

> [...] We can add a simple (like OSS) API layer 
> into alsa-lib, but I'm not sure, if it's worth to do it.

Probably not worth it. But having more examples like Alistair's in docs
would be a good idea, I expect. The silly patch I quoted is one of
the hottest documents on my webpage. People need this stuff, and
cannot find it.

-- Pete

Re: [OT] ALSA userspace API complexity

[Alistair John Strachan]

On Wednesday 04 January 2006 11:35, Jaroslav Kysela wrote:
> On Wed, 4 Jan 2006, Pete Zaitcev wrote:
> > On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan 
<s0348365@sms.ed.ac.uk> wrote:
> > > > 2) ALSA API is to complicated: most applications opens single sound
> > > >    stream.
> > >
> > > FUD and nonsense. []
> > > http://devzero.co.uk/~alistair/alsa/
> >
> > That's the kicker, isn't it? Once you get used to it, it's a workable
> > API, if kinky and verbose. I have a real life example, too:
> >  http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
> > But arriving on the solution costed a lot of torn hair. Look at this
> > bald head here! And who is going to pay my medical bills when ALSA
> > causes me ulcers, Jaroslav?
>
> Well, the ALSA primary goal is to be the complete HAL not hidding the
> extra hardware capabilities to applications. So API might look a bit
> complicated for the first glance, but the ALSA interface code for simple
> applications is not so big, isn't?
>
> Also, note that app developers are not forced to use ALSA directly - there
> is a lot of "portable" sound API libraries having an ALSA backend doing
> this job quite effectively. We can add a simple (like OSS) API layer
> into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
> some support functions for the easy PCM device initialization might be
> a good idea.

I agree. I see a lot of steam blowing and hot air from people complaining 
about ALSA. Your API is perfectly usable and aptly translates generic issues 
with any sound hardware (such as xruns and hardware buffering) without hiding 
them away so they cannot be manipulated.

The only significant issue with ALSA is the number of tunables that you have 
to set with individual function calls. Personally, I like this approach, but 
I do always end up wrapping them in some structure, so perhaps you could have 
a "quick and dirty" one liner that would either be:

snd_hw_set_params (fd, ... long list of sensible parameters ...)
snd_sw_set_params (fd, ... ditto ...)

Or, take an ioctl approach (which people here seem to love; urgh):

struct hw_params my_hw_params = {
	PCM_LE_16,
	2,
	blah,
};
...

snd_hw_set_params (fd, &my_hw_params);
snd_sw_set_params (fd, &my_sw_params);

I think your time is better spent addressing the issues of "bloat" in the 
kernel side of things (the more code in userspace the better, despite what 
ridiculous statements there have been on this thread to the contrary).

_Documentation_ clearly distinguishing between "sw" paramters and "hw" 
parameters would also be good, as when I first learnt ALSA (some 3 years 
ago), I didn't even know what these were!

-- 
Cheers,
Alistair.

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

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Wed, Jan 04, 2006 at 02:23:42PM +0000, Alistair John Strachan wrote:
> Or, take an ioctl approach (which people here seem to love; urgh):

I'm afraid you missed the point there.  ioctl or not ioctl is not
important, and yes, ioctls have a lot of problems.  The problem is
having a library define the public interface for kernel services.  I
don't see how come Linus accepted that, unless he doesn't really use
sound and just doesn't care, which is my current interpretation.

  OG.

Re: [OT] ALSA userspace API complexity

[Tomasz Kłoczko]

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

On Wed, 4 Jan 2006, Jaroslav Kysela wrote:

> On Wed, 4 Jan 2006, Pete Zaitcev wrote:
>
>> On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
>>
>>>> 2) ALSA API is to complicated: most applications opens single sound
>>>>    stream.
>>>
>>> FUD and nonsense. []
>>> http://devzero.co.uk/~alistair/alsa/
>>
>> That's the kicker, isn't it? Once you get used to it, it's a workable
>> API, if kinky and verbose. I have a real life example, too:
>>  http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
>> But arriving on the solution costed a lot of torn hair. Look at this
>> bald head here! And who is going to pay my medical bills when ALSA
>> causes me ulcers, Jaroslav?
>
> Well, the ALSA primary goal is to be the complete HAL not hidding the
> extra hardware capabilities to applications. So API might look a bit
> complicated for the first glance, but the ALSA interface code for simple
> applications is not so big, isn't?

Sorry Jaroslav byt this not unix way.
Wny applications myst know anything about hardware layer ?
In unix way all this details are rolled on kernel layer.

> Also, note that app developers are not forced to use ALSA directly - there
> is a lot of "portable" sound API libraries having an ALSA backend doing
> this job quite effectively. We can add a simple (like OSS) API layer
> into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
> some support functions for the easy PCM device initialization might be
> a good idea.

If we have so many "portable" sound API libraries .. look most of them 
uses the same way for handle sound on kernel interaction. Is this 
complicated ALSA way is realy neccessary ?
For example .. jackd can use OSS API for handle sound device.

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

Allow me translate sentence from my signature to english
"People do not have problems they create them themselves"
and ALSA case matches in 100%.

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

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

On Thu, 5 Jan 2006, Tomasz Kłoczko wrote:

> On Wed, 4 Jan 2006, Jaroslav Kysela wrote:

> > Well, the ALSA primary goal is to be the complete HAL not hidding the
> > extra hardware capabilities to applications. So API might look a bit
> > complicated for the first glance, but the ALSA interface code for simple
> > applications is not so big, isn't?
> 
> Sorry Jaroslav byt this not unix way.
> Wny applications myst know anything about hardware layer ?
> In unix way all this details are rolled on kernel layer.

It means that you are saying that kernel should be bigger and bigger.
Please, see the graphics APIs. Why we have X servers in user space (and
only some supporting code is in the kernel) then? It's because if we 
would move everything into kernel it will be even more bloated. The kernel 
should do really the basic things like direct hardware access, DMA 
transfer etc.

> > Also, note that app developers are not forced to use ALSA directly - 
> > there is a lot of "portable" sound API libraries having an ALSA 
> > backend doing this job quite effectively. We can add a simple (like 
> > OSS) API layer into alsa-lib, but I'm not sure, if it's worth to do 
> > it. Perhaps, adding some support functions for the easy PCM device 
> > initialization might be a good idea.
> 
> If we have so many "portable" sound API libraries .. look most of them 
> uses the same way for handle sound on kernel interaction. Is this 
> complicated ALSA way is realy neccessary ? For example .. jackd can use 
> OSS API for handle sound device.

The grounds of ALSA APIs are not complicated. The complicated are the 
extra features (like stream linking) which can be included conditionaly. 
Note that during API development, mostly users requesting extra features 
were speak loudly, others were only watching.

We know that the reduction requests have points for embedded systems etc.
And we will definitely try to sort "real-core" and "extra" things.

Also, note that if OSS used a library to access to sound devices, we won't 
ever have such problems with the OSS API redirection to another API.
I already created a prototype of OSS API redirector (part of alsa-oss 
package), see:

http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-oss/oss-redir/README?rev=1.1&view=markup
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-oss/oss-redir/oss-redir.h?rev=1.6&view=markup
http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-oss/oss-redir/oss-redir.c?rev=1.9&view=markup

But it's a question, if OSS application developers take this proposal.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Thu, Jan 05, 2006 at 01:23:23PM +0100, Jaroslav Kysela wrote:
> It means that you are saying that kernel should be bigger and bigger.
> Please, see the graphics APIs. Why we have X servers in user space (and
> only some supporting code is in the kernel) then? It's because if we 
> would move everything into kernel it will be even more bloated. The kernel 
> should do really the basic things like direct hardware access, DMA 
> transfer etc.

You plan to remove the network stack from the kernel when then?  X is
in user space for some rather strange values of userspace[1] for
historical and political reasons, not technical ones.  When
performance raises its ugly head and you end up having to listen to
engineers again you end up with DRI and that:

Module                  Size  Used by
nvidia               3464380  12 

X is a beautiful example of how things should not have been done.  Its
only redeeming quality is that it exists and works, and that's
definitively a non-negligible one.


> But it's a question, if OSS application developers take this proposal.

You seem to be missing the point that the entire reason why OSS is
important is that it isn't a library.

  OG.

[1] Direct hardware access, DMA, pci enumeration, hardware
    reconfiguration, what a beautiful userspace we have there.

Re: [parisc-linux] Re: [OT] ALSA userspace API complexity

[Alan Cox]

On Iau, 2006-01-05 at 15:21 +0100, Olivier Galibert wrote:
> historical and political reasons, not technical ones.  When
> performance raises its ugly head and you end up having to listen to
> engineers again you end up with DRI and that:
> 
> Module                  Size  Used by
> nvidia               3464380  12 

That isn't DRI. DRI is a good deal smaller than the crazy nvidia stuff.

radeon                 81089  1
drm                    83433  2 radeon

.. speaks volumes doesn't it 8)

> X is a beautiful example of how things should not have been done.  Its
> only redeeming quality is that it exists and works, and that's
> definitively a non-negligible one.

X servers have been implemented a variety of ways involving mixed user
and kernel space environments, user space only, pure kernel space, and
even downloading the server onto a graphics coprocessor and talking X
protocol to it.

The actual performance properties are heavily dependant upon the
architecture of the cards of the period. The flavour of the past few
years is the DMA command stream which happens to lend itself well to
splitting rendering between the kernel and user space. 

Alan

Re: [parisc-linux] Re: [OT] ALSA userspace API complexity

[Jan Engelhardt]

>> historical and political reasons, not technical ones.  When
>> performance raises its ugly head and you end up having to listen to
>> engineers again you end up with DRI and that:
>> 
>> Module                  Size  Used by
>> nvidia               3464380  12 
>
>That isn't DRI. DRI is a good deal smaller than the crazy nvidia stuff.
>
>radeon                 81089  1
>drm                    83433  2 radeon
>
>.. speaks volumes doesn't it 8)

What nvidia version number is that? I remember it being over 5 megs in size. Oh
BTW, that's one GOOD REASON for me to believe having certain parts in userspace
(e.g. X was mentioned) being a good thing - after all, you can't swap kernel
memory. If nvidia continued like that, their kernel module would eventually
exceed the amount of RAM that is apparently installed.

>> X is a beautiful example of how things should not have been done.  Its
>> only redeeming quality is that it exists and works, and that's
>> definitively a non-negligible one.
>
>X servers have been implemented a variety of ways involving mixed user
>and kernel space environments, user space only, pure kernel space, and
>even downloading the server onto a graphics coprocessor and talking X
>protocol to it.



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/
| jengelh's site, http://jengelh.hopto.org/

Re: [OT] ALSA userspace API complexity

[Tomasz Kłoczko]

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

On Thu, 5 Jan 2006, Jaroslav Kysela wrote:

> On Thu, 5 Jan 2006, Tomasz Kłoczko wrote:
>
>> On Wed, 4 Jan 2006, Jaroslav Kysela wrote:
>
>>> Well, the ALSA primary goal is to be the complete HAL not hidding the
>>> extra hardware capabilities to applications. So API might look a bit
>>> complicated for the first glance, but the ALSA interface code for simple
>>> applications is not so big, isn't?
>>
>> Sorry Jaroslav byt this not unix way.
>> Wny applications myst know anything about hardware layer ?
>> In unix way all this details are rolled on kernel layer.
>
> It means that you are saying that kernel should be bigger and bigger.
> Please, see the graphics APIs. Why we have X servers in user space (and
> only some supporting code is in the kernel) then? It's because if we
> would move everything into kernel it will be even more bloated. The kernel
> should do really the basic things like direct hardware access, DMA
> transfer etc.

List all neccessary feactures and abstract them. Below this layer you 
can plug to this all device drivers. Where is the problem ?
Cureent way moves some importand details like mixing to user space 
library.
All abstraction are NOW coded but some parts of this abstraction are on 
library level and you are wrong because this still ONE abstraction
(not multiple/growing).
Moving some patrs of this abstraction to user space level DISSALLOW secure 
manage because you do not have *single point of entry to this layer*. Try
plug library abstraction to SELinux layer. Can you do this with ALSA way ?

If you have sound device with hardware mixer(s) ALSA now work 
transparently. 
If you have sound device without this soft mixing is moved to user space 
.. but  applications do not need know about this even now because all
neccessary details are handled on library level. Is it ?
So question is: why the hell *ALL* mixing details are not moved to kernel 
space to SIMPLE and NOT GROWING abstraction ?

Next thing: look again on diffrent types sound devices. What do you have ?
Sound  output/input device(s) wich acan be oppened with diffrent sampling 
rates and diffrent samle sizes or only constatns sample rates/sizes, mixer
devic(s), midi ... all ot them CAN BE abstracted to form with hidded ALL
hardware details. Problem with growing abstraction size ocurres ONLY when 
some new hardware will provides new hardware sound part class/type.
Generaly this NOT OCCURRES in case sound devices.
So .. I don't see your "kernel should be bigger and bigger". If you 
want continue please describe this.

BTW X11: please don't use X11 examplary. Despite the fact that ther are 
quite a lot of people working around it's defficiencies in a moderately 
successfully way, X11 has to be considered a piece of rotten bloated 
mindless utter crap and by no way as an exemplary piece of software design 
exercise.

In case ALSA now questions are very basic:

- all hardware mixers are very simillar with very izomorphic interface
   (read this as: this can be very easy abstracted) and we have only one
   other case with soft mixing when this hardwware must be emulated in
   software .. so all this details can be rolled to one leyer on kernel
   level.
   So: why all mixing details are not in kernel space ?

- KNOWN FACT is OSS provides simpler API for user space for handle
   usual cases.
   Why Linux can't provide only OSS API abstraction for user space
   application ? And/or why ALSA developers want to replace this by
   mostly bloated and pourly documented ALSA user space API ?

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

Re: [OT] ALSA userspace API complexity

[Takashi Iwai]

At Thu, 5 Jan 2006 16:07:02 +0100 (CET),
Tomasz Kłoczko wrote:
> 
> On Thu, 5 Jan 2006, Jaroslav Kysela wrote:
> 
> > On Thu, 5 Jan 2006, Tomasz Kłoczko wrote:
> >
> >> On Wed, 4 Jan 2006, Jaroslav Kysela wrote:
> >
> >>> Well, the ALSA primary goal is to be the complete HAL not hidding the
> >>> extra hardware capabilities to applications. So API might look a bit
> >>> complicated for the first glance, but the ALSA interface code for simple
> >>> applications is not so big, isn't?
> >>
> >> Sorry Jaroslav byt this not unix way.
> >> Wny applications myst know anything about hardware layer ?
> >> In unix way all this details are rolled on kernel layer.
> >
> > It means that you are saying that kernel should be bigger and bigger.
> > Please, see the graphics APIs. Why we have X servers in user space (and
> > only some supporting code is in the kernel) then? It's because if we
> > would move everything into kernel it will be even more bloated. The kernel
> > should do really the basic things like direct hardware access, DMA
> > transfer etc.
> 
> List all neccessary feactures and abstract them. Below this layer you 
> can plug to this all device drivers. Where is the problem ?
> Cureent way moves some importand details like mixing to user space 
> library.
> All abstraction are NOW coded but some parts of this abstraction are on 
> library level and you are wrong because this still ONE abstraction
> (not multiple/growing).
> Moving some patrs of this abstraction to user space level DISSALLOW secure 
> manage because you do not have *single point of entry to this layer*. Try
> plug library abstraction to SELinux layer. Can you do this with ALSA way ?

I don't understand this.  The alsa-lib doesn't skip the h/w access.
It still accesses the device file as usual, open/close/ioctls.  If the
h/w to do softmix is restricted, you can't use it, too.
Or, am I missing something else?


> If you have sound device with hardware mixer(s) ALSA now work 
> transparently. 
> If you have sound device without this soft mixing is moved to user space 
> .. but  applications do not need know about this even now because all
> neccessary details are handled on library level. Is it ?
> So question is: why the hell *ALL* mixing details are not moved to kernel 
> space to SIMPLE and NOT GROWING abstraction ?

Because many people believe that the softmix in the kernel space is
evil.  The discussion aboult this could be a long thread.


(snip)
> In case ALSA now questions are very basic:
> 
> - all hardware mixers are very simillar with very izomorphic interface
>    (read this as: this can be very easy abstracted) and we have only one
>    other case with soft mixing when this hardwware must be emulated in
>    software .. so all this details can be rolled to one leyer on kernel
>    level.
>    So: why all mixing details are not in kernel space ?

The problem is not the interface but the implementation.

> - KNOWN FACT is OSS provides simpler API for user space for handle
>    usual cases.

Please define "usual cases".

>    Why Linux can't provide only OSS API abstraction for user space
>    application ? And/or why ALSA developers want to replace this by
>    mostly bloated and pourly documented ALSA user space API ?

Because OSS API doesn't cover many things.  For example, 

- PCM with non-interleaved formats
- PCM with 3-bytes-packed 24bit formats

These functions are popluar on many sound devices.

In addition, imagine how you would implement the following:

- Combination of multiple devices
- Split of channels to concurrent accesses
- Handling of floating pointer samples
- Post/pre-effects (like chorus/reverb)

Forcing OSS API means to force to process the all things above in
the kernel.  I guess many people would disagree with it.


Takashi

Re: [OT] ALSA userspace API complexity

[Marcin Dalecki]

On 2006-01-05, at 17:14, Takashi Iwai wrote:
>
> Because OSS API doesn't cover many things.  For example,
>
> - PCM with non-interleaved formats
> - PCM with 3-bytes-packed 24bit formats
>
> These functions are popluar on many sound devices.
>
> In addition, imagine how you would implement the following:
>
> - Combination of multiple devices
> - Split of channels to concurrent accesses
> - Handling of floating pointer samples
> - Post/pre-effects (like chorus/reverb)
>
> Forcing OSS API means to force to process the all things above in
> the kernel.  I guess many people would disagree with it.

Not at all. What a sane system would do would be the following:

1. Provide kernel devices, which are supposed to be used by a single  
user space helper
daemon claiming them once and for ever. Those would expose the  
extensive low level hardware interface
which is required to implement this kind of processing. Those  
controlling devices would be basically
accessible by the root user.

2. Provide kernel devices, which are supposed to be used by consumer  
applications. Those would
be basically just engaged in the data lifting between the user space  
application
the kernel and the processing daemon application.

Very much a design similar what can be found in the area of terminal  
support where there is a distinction
between a pseudo tty and a tty driver. Actually if one thinks about  
it the sound output and feeding *should* be associated with a  
terminal device. Keyboard/Micro Display/Speakers - pretty much the  
same data flow.

Very much the same as the relation between the ethernet interface  
card drivers and the netowork stack support.

No the alsa mess just basically hurrying up to map the hardware  
facilities as primitively as possible in to user space for messing  
around inside some "library" which is supposed to do wonders.

Re: [OT] ALSA userspace API complexity

[Tomasz Kłoczko]

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

[..]
>>> It means that you are saying that kernel should be bigger and bigger.
>>> Please, see the graphics APIs. Why we have X servers in user space (and
>>> only some supporting code is in the kernel) then? It's because if we
>>> would move everything into kernel it will be even more bloated. The kernel
>>> should do really the basic things like direct hardware access, DMA
>>> transfer etc.
>>
>> List all neccessary feactures and abstract them. Below this layer you
>> can plug to this all device drivers. Where is the problem ?
>> Cureent way moves some importand details like mixing to user space
>> library.
>> All abstraction are NOW coded but some parts of this abstraction are on
>> library level and you are wrong because this still ONE abstraction
>> (not multiple/growing).
>> Moving some patrs of this abstraction to user space level DISSALLOW secure
>> manage because you do not have *single point of entry to this layer*. Try
>> plug library abstraction to SELinux layer. Can you do this with ALSA way ?
>
> I don't understand this.  The alsa-lib doesn't skip the h/w access.
> It still accesses the device file as usual, open/close/ioctls.  If the
> h/w to do softmix is restricted, you can't use it, too.
> Or, am I missing something else?

Soft mixing is performed by writing to allocated shared memory block.
Try to use SELinux on dissalow use SHM only for mixing souds.
In case performing ALL (possible) mixing tricks you have SINGLE point of 
entry from any application. Using SHM with r/w permission allow one
allicattions dump sound streams writed by other applications.

>> If you have sound device with hardware mixer(s) ALSA now work
>> transparently.
>> If you have sound device without this soft mixing is moved to user space
>> .. but  applications do not need know about this even now because all
>> neccessary details are handled on library level. Is it ?
>> So question is: why the hell *ALL* mixing details are not moved to kernel
>> space to SIMPLE and NOT GROWING abstraction ?
>
> Because many people believe that the softmix in the kernel space is
> evil.  The discussion aboult this could be a long thread.

Moment .. are you want to say: there is no compact mixing abstraction 
layer in ALSA because because ALSA is developed by believers ? (not 
technicians/enginers ?)
Sorry .. be so kind and try to answer on my question using only stricte 
*technical arguments*.

> (snip)
>> In case ALSA now questions are very basic:
>>
>> - all hardware mixers are very simillar with very izomorphic interface
>>    (read this as: this can be very easy abstracted) and we have only one
>>    other case with soft mixing when this hardwware must be emulated in
>>    software .. so all this details can be rolled to one leyer on kernel
>>    level.
>>    So: why all mixing details are not in kernel space ?
>
> The problem is not the interface but the implementation.

Hmm .. if "ALSA is developed by belivers" slowny now I undestand .. all 
this :>

[..]
> Because OSS API doesn't cover many things.  For example,
>
> - PCM with non-interleaved formats
> - PCM with 3-bytes-packed 24bit formats

Not true. Download OSS from opensound. You can find in soundcard.h 
AFMT_S24_PACKED define.

> These functions are popluar on many sound devices.
>
> In addition, imagine how you would implement the following:
>
> - Combination of multiple devices
> - Split of channels to concurrent accesses
> - Handling of floating pointer samples
> - Post/pre-effects (like chorus/reverb)

Are you want say something like: architesture of OSS is so bad there is no 
civilized way for extending this ? (except: chorus/reverb are now handled 
by comercial OSS).
Correct me if I'm wrong: his not true.

> Forcing OSS API means to force to process the all things above in
> the kernel.  I guess many people would disagree with it.

Completly disagee.
And another argument: comercial OSS have ALSA emulation and ALSA have OSS 
emulation.
So .. there is no general architecture problems on implemting both varians 
(in both variants sits only some implementation bugs).

This unhides one fact: *ALSA and OSS are mostly izomorphic* (look on 
similarities ALSA and OSS device drivers architecture).

And if it is true there was/is no strong arguments for droping OSS and 
replace this by ALSA. As I sayd ALSA is only on Linux. Using OSS allow 
easier develpment soud support in user space applications for some group 
of currently used unices. This is IMO strong argument .. much stronger 
than existing or not group of belivers. For me now switching to ALSA have 
only *political groud* .. nothing more. Interesting .. how long Linux can 
survive without looking on some economic aspects ?

If you allow .. EOT

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

Re: [OT] ALSA userspace API complexity

[Takashi Iwai]

At Thu, 5 Jan 2006 21:13:25 +0100 (CET),
Tomasz Kłoczko wrote:
> 
> [..]
> >>> It means that you are saying that kernel should be bigger and bigger.
> >>> Please, see the graphics APIs. Why we have X servers in user space (and
> >>> only some supporting code is in the kernel) then? It's because if we
> >>> would move everything into kernel it will be even more bloated. The kernel
> >>> should do really the basic things like direct hardware access, DMA
> >>> transfer etc.
> >>
> >> List all neccessary feactures and abstract them. Below this layer you
> >> can plug to this all device drivers. Where is the problem ?
> >> Cureent way moves some importand details like mixing to user space
> >> library.
> >> All abstraction are NOW coded but some parts of this abstraction are on
> >> library level and you are wrong because this still ONE abstraction
> >> (not multiple/growing).
> >> Moving some patrs of this abstraction to user space level DISSALLOW secure
> >> manage because you do not have *single point of entry to this layer*. Try
> >> plug library abstraction to SELinux layer. Can you do this with ALSA way ?
> >
> > I don't understand this.  The alsa-lib doesn't skip the h/w access.
> > It still accesses the device file as usual, open/close/ioctls.  If the
> > h/w to do softmix is restricted, you can't use it, too.
> > Or, am I missing something else?
> 
> Soft mixing is performed by writing to allocated shared memory block.
> Try to use SELinux on dissalow use SHM only for mixing souds.
> In case performing ALL (possible) mixing tricks you have SINGLE point of 
> entry from any application. Using SHM with r/w permission allow one
> allicattions dump sound streams writed by other applications.

Yes, it's a known problem to be fixed.  But, it's no excuse to do
_everything_ in the kernel (which OSS requires).


> >> If you have sound device with hardware mixer(s) ALSA now work
> >> transparently.
> >> If you have sound device without this soft mixing is moved to user space
> >> .. but  applications do not need know about this even now because all
> >> neccessary details are handled on library level. Is it ?
> >> So question is: why the hell *ALL* mixing details are not moved to kernel
> >> space to SIMPLE and NOT GROWING abstraction ?
> >
> > Because many people believe that the softmix in the kernel space is
> > evil.  The discussion aboult this could be a long thread.
> 
> Moment .. are you want to say: there is no compact mixing abstraction 
> layer in ALSA because because ALSA is developed by believers ? (not 
> technicians/enginers ?)
> Sorry .. be so kind and try to answer on my question using only stricte 
> *technical arguments*.

I stated above because I know it will be a discussion without a clear
end.  From the convenence viewpoint, doing everthing in the kernel
including the software mixing is fine.  But, do you want to it -- to
do EVERTHING in the kernel with a great risk of system down and the
programming restrictions (no FP, etc)?


> > Because OSS API doesn't cover many things.  For example,
> >
> > - PCM with non-interleaved formats
> > - PCM with 3-bytes-packed 24bit formats
> 
> Not true. Download OSS from opensound. You can find in soundcard.h 
> AFMT_S24_PACKED define.

And if the application doesn't support, who and where converts it?
With OSS API, it's a job of the kernel.

> > These functions are popluar on many sound devices.
> >
> > In addition, imagine how you would implement the following:
> >
> > - Combination of multiple devices
> > - Split of channels to concurrent accesses
> > - Handling of floating pointer samples
> > - Post/pre-effects (like chorus/reverb)
> 
> Are you want say something like: architesture of OSS is so bad there is no 
> civilized way for extending this ? (except: chorus/reverb are now handled 
> by comercial OSS).
> Correct me if I'm wrong: his not true.

Could you tell me how do you handle the floating point in the kernel
code?

> This unhides one fact: *ALSA and OSS are mostly izomorphic* (look on 
> similarities ALSA and OSS device drivers architecture).
> 
> And if it is true there was/is no strong arguments for droping OSS and 
> replace this by ALSA. As I sayd ALSA is only on Linux. Using OSS allow 
> easier develpment soud support in user space applications for some group 
> of currently used unices. This is IMO strong argument .. much stronger 
> than existing or not group of belivers. For me now switching to ALSA have 
> only *political groud* .. nothing more. Interesting .. how long Linux can 
> survive without looking on some economic aspects ?

Don't get me wrong.  I, as ALSA developer, don't believe that OSS API
would disappear.  The API will remain.  But the implementation may
change.  That's all what is happening -- Adrian has asked to drop the
codes which are implemented differently (on ALSA).  No one requested
to drop the API support.


Takashi

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote:
> Yes, it's a known problem to be fixed.  But, it's no excuse to do
> _everything_ in the kernel (which OSS requires).

OSS does not require to do anything in the kernel except an entry
point.


> And if the application doesn't support, who and where converts it?
> With OSS API, it's a job of the kernel.

Once again no.  Nothing prevents the kernel to forward the data to
userland daemons depending on a userspace-uploaded configuration.

  OG.

Re: [OT] ALSA userspace API complexity

[Martin Drab]

On Sun, 8 Jan 2006, Olivier Galibert wrote:

> > And if the application doesn't support, who and where converts it?
> > With OSS API, it's a job of the kernel.
> 
> Once again no.  Nothing prevents the kernel to forward the data to
> userland daemons depending on a userspace-uploaded configuration.

I think that the point was, that switching from userspace to kernelspace 
then to userspace again and back to kernelspace in order to do something, 
that could have been done directly in the userspace, and though could save 
those two unnecessary switches, is an unnecessary overhead, which may not 
necessarily be that insignificant if it's done so often (which for 
streaming audio is the case). Why doing things complicated when there is 
no evident gain from it, or is there?

Martin

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Sun, Jan 08, 2006 at 03:26:18AM +0100, Martin Drab wrote:
> On Sun, 8 Jan 2006, Olivier Galibert wrote:
> 
> > > And if the application doesn't support, who and where converts it?
> > > With OSS API, it's a job of the kernel.
> > 
> > Once again no.  Nothing prevents the kernel to forward the data to
> > userland daemons depending on a userspace-uploaded configuration.
> 
> I think that the point was, that switching from userspace to kernelspace 
> then to userspace again and back to kernelspace in order to do something, 
> that could have been done directly in the userspace, and though could save 
> those two unnecessary switches, is an unnecessary overhead, which may not 
> necessarily be that insignificant if it's done so often (which for 
> streaming audio is the case).

You all seem to forget that dmix is in userspace in a different task
too.


> Why doing things complicated when there is no evident gain from it,
> or is there?

No evident gain?  Wow.  What about:
- stopping crippling the OSS api

- having a real kernel api for which you can make different libraries
  depending on the need of the users

- stop making a fundamentally unsecure shared library mandatory

- opening the possibility of writing plugins to people without a PhD
  in lattice QCD.

and that's just a start.

  OG.

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Sun, 8 Jan 2006, Olivier Galibert wrote:

> On Sun, Jan 08, 2006 at 03:26:18AM +0100, Martin Drab wrote:
> > On Sun, 8 Jan 2006, Olivier Galibert wrote:
> > 
> > > > And if the application doesn't support, who and where converts it?
> > > > With OSS API, it's a job of the kernel.
> > > 
> > > Once again no.  Nothing prevents the kernel to forward the data to
> > > userland daemons depending on a userspace-uploaded configuration.
> > 
> > I think that the point was, that switching from userspace to kernelspace 
> > then to userspace again and back to kernelspace in order to do something, 
> > that could have been done directly in the userspace, and though could save 
> > those two unnecessary switches, is an unnecessary overhead, which may not 
> > necessarily be that insignificant if it's done so often (which for 
> > streaming audio is the case).
> 
> You all seem to forget that dmix is in userspace in a different task
> too.

Because it is really not. The mixing is done directly to the mmaped DMA 
buffer.

> > Why doing things complicated when there is no evident gain from it,
> > or is there?
> 
> No evident gain?  Wow.  What about:
> - stopping crippling the OSS api

We're not doing that. We're just showing that OSS API and useability has 
it's own problems, too.

> - having a real kernel api for which you can make different libraries
>   depending on the need of the users
> 
> - stop making a fundamentally unsecure shared library mandatory

ALSA kernel API is real and binary compatible. If someone require to
write an own library, we will document this API, of course, too.

> - opening the possibility of writing plugins to people without a PhD
>   in lattice QCD.

Already done. We have official plugin SDK in alsa-lib to create user space 
drivers. If you have some questions or bug-reports (missing docs etc), 
please, fill a bug report.

Also, you can use very simple LADSPA plugin style, because alsa-lib can 
use LADSPA plugins directly, too.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Pavel Machek]

On Ne 08-01-06 14:32:40, Jaroslav Kysela wrote:
> ALSA kernel API is real and binary compatible. If someone require to
> write an own library, we will document this API, of course, too.

The documentation would be nice, regardless of other libraries. It is
kernel API and that really should be documented.
								Pavel

-- 
Thanks, Sharp!

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Sun, 8 Jan 2006, Jaroslav Kysela wrote:

> > - having a real kernel api for which you can make different libraries
> >   depending on the need of the users
> > 
> > - stop making a fundamentally unsecure shared library mandatory
> 
> ALSA kernel API is real and binary compatible. 
Less than an year ago you (or was it Takashi) told that the kernel API 
cannot be used or documented because it may be changed any time without 
notice.

Best regards,

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Takashi Iwai]

At Mon, 9 Jan 2006 02:33:43 +0200 (EET),
Hannu Savolainen wrote:
> 
> On Sun, 8 Jan 2006, Jaroslav Kysela wrote:
> 
> > > - having a real kernel api for which you can make different libraries
> > >   depending on the need of the users
> > > 
> > > - stop making a fundamentally unsecure shared library mandatory
> > 
> > ALSA kernel API is real and binary compatible. 
> Less than an year ago you (or was it Takashi) told that the kernel API 
> cannot be used or documented because it may be changed any time without 
> notice.

Hmm, that might be me.  I meant as a merit of a common library as the
API entry.  Of course, the kernel API will be kept as much as possible
as we have done it so.


Takashi

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Thierry Vignaud]

Olivier Galibert <galibert@pobox.com> writes:

> - stop making a fundamentally unsecure shared library mandatory

do you speak about known vulnerabilities in ALSA lib or are you
trolling^h^h^h^h^h^h^h assuming that kernel code is safer than
userspace one?

afaic I don't assume this.
I'd prefer see bad code make one app crashing than oopsing the whole
machine.

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Sun, 8 Jan 2006, Olivier Galibert wrote:

> On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote:
> > Yes, it's a known problem to be fixed.  But, it's no excuse to do
> > _everything_ in the kernel (which OSS requires).
> 
> OSS does not require to do anything in the kernel except an entry
> point.
> 
> 
> > And if the application doesn't support, who and where converts it?
> > With OSS API, it's a job of the kernel.
> 
> Once again no.  Nothing prevents the kernel to forward the data to
> userland daemons depending on a userspace-uploaded configuration.

But it's quite ineffecient. The kernel must switch tasks at least twice
or more. It's the major problem with the current OSS API.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Sun, Jan 08, 2006 at 10:42:02AM +0100, Jaroslav Kysela wrote:
> On Sun, 8 Jan 2006, Olivier Galibert wrote:
> 
> > On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote:
> > > Yes, it's a known problem to be fixed.  But, it's no excuse to do
> > > _everything_ in the kernel (which OSS requires).
> > 
> > OSS does not require to do anything in the kernel except an entry
> > point.
> > 
> > 
> > > And if the application doesn't support, who and where converts it?
> > > With OSS API, it's a job of the kernel.
> > 
> > Once again no.  Nothing prevents the kernel to forward the data to
> > userland daemons depending on a userspace-uploaded configuration.
> 
> But it's quite ineffecient. The kernel must switch tasks at least twice
> or more. It's the major problem with the current OSS API.

Once.  U->K or K->U is not task switching and accordingly has a very
low cost.  It's changing of userspace task that is costly.  And dmix
_is_ a task switch, there is no performance difference between talking
with it through shared memory and semaphores and who knows what else
and talking with it through a kernel interface.

You should count how many U-U switches and U-K syscalls communicating
with dmix represents.  Hard to do for a simple user, since the
protocol is not documented.

  OG.

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Sun, 8 Jan 2006, Olivier Galibert wrote:

> On Sun, Jan 08, 2006 at 10:42:02AM +0100, Jaroslav Kysela wrote:
> > On Sun, 8 Jan 2006, Olivier Galibert wrote:
> > 
> > > On Sat, Jan 07, 2006 at 03:32:27PM +0100, Takashi Iwai wrote:
> > > > Yes, it's a known problem to be fixed.  But, it's no excuse to do
> > > > _everything_ in the kernel (which OSS requires).
> > > 
> > > OSS does not require to do anything in the kernel except an entry
> > > point.
> > > 
> > > 
> > > > And if the application doesn't support, who and where converts it?
> > > > With OSS API, it's a job of the kernel.
> > > 
> > > Once again no.  Nothing prevents the kernel to forward the data to
> > > userland daemons depending on a userspace-uploaded configuration.
> > 
> > But it's quite ineffecient. The kernel must switch tasks at least twice
> > or more. It's the major problem with the current OSS API.
> 
> Once.  U->K or K->U is not task switching and accordingly has a very
> low cost.  It's changing of userspace task that is costly.  And dmix
> _is_ a task switch, there is no performance difference between talking
> with it through shared memory and semaphores and who knows what else
> and talking with it through a kernel interface.
> 
> You should count how many U-U switches and U-K syscalls communicating
> with dmix represents.  Hard to do for a simple user, since the
> protocol is not documented.

You're in a mistake. For x86, there are no U-K syscalls for dmix and no 
extra U-U task switches, even the latency is same as for the direct 
hardware access, because we're using a lockless technique. Also, in case 
of use of using mutexes for other architectures, there is only task switch 
when mutex is locked when the real mixing is in progress (the mixing is 
really small time windows, so it's rare to have mutex locked).

In case of a mixing daemon, you need to regulary woke up a task in a time 
period (probably with a highter time interval than application are feeding 
new samples). So you have at least one U-U task switch in the perfect 
conditions (all sound applications delivered data "in time").

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Marcin Dalecki]

On 2006-01-08, at 10:42, Jaroslav Kysela wrote:
>>
>> Once again no.  Nothing prevents the kernel to forward the data to
>> userland daemons depending on a userspace-uploaded configuration.
>
> But it's quite ineffecient. The kernel must switch tasks at least  
> twice
> or more. It's the major problem with the current OSS API.

1. It was only presented as an opportunity. Not every data has to go  
this way.
2. Aren't you the person which was showing off X11 as a good example  
to draw guidelines from?

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Sun, 8 Jan 2006, Jaroslav Kysela wrote:

> On Sun, 8 Jan 2006, Olivier Galibert wrote:
> 
> > Once again no.  Nothing prevents the kernel to forward the data to
> > userland daemons depending on a userspace-uploaded configuration.
> 
> But it's quite ineffecient. The kernel must switch tasks at least twice
> or more. 
Actually there is just one extra context switch. When the application 
using the API interface has finished it's current buffer it goes to sleep 
(sooner or later). With no OSS kernel task then the context is 
switched to the next process in the ready list. With the OSS task there is 
one extra context switch to the task before the inevitable switch to 
some other task in the system.

In CPU usage perspective this is nothing significant. This kind of 
approach makes only sense if the extra task is going to do some 
significant processing. So even if there is one context switch (and 
possibly some data copying) related with this mechanism the load caused to 
it is microscopic when compared to the actual processing. There is no real 
difference when compared to a pure library solution.

What is problem is that context switching delays make it necessary to use 
slightly larger buffers. This causes increased latencies which may or may 
not cause problems with some timing critical applications. OTOH with OSS 
API the application can disable this kind of extra stuff if it needs 
"traditional" access directly to the device.

> It's the major problem with the current OSS API.
I don't see there any problem. In particular it's in no way an API 
issue. Everything that has been found to be necessary for applications is 
included in OSS API and all it has been implemented in kernel space. 

Best regards,

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

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Thu, 5 Jan 2006, Takashi Iwai wrote:

> > If you have sound device without this soft mixing is moved to user space 
> > .. but  applications do not need know about this even now because all
> > neccessary details are handled on library level. Is it ?
> > So question is: why the hell *ALL* mixing details are not moved to kernel 
> > space to SIMPLE and NOT GROWING abstraction ?
> 
> Because many people believe that the softmix in the kernel space is
> evil.
This is the usual argument against kernel level mixing. Somebody has once 
said that all this is evil. However this is not necessarily correct.

OSS has done kernel level mixing for years. The vmix driver has been used 
as the default audio device by hundreds of thousands of customers for 
years. We have not received any single bug report that is caused 
by the concept of kernel mixing.

Kernel mixing is not rocket science. All you need to do is picking a 
sample from the output buffers of each of the applications, sum them 
together (with some volume scaling) and feed the result to the physical 
device. Ok, handling different sample formats/rates makes it much more 
difficult but that could be done in the library level.
 
> >    Why Linux can't provide only OSS API abstraction for user space
> >    application ? And/or why ALSA developers want to replace this by
> >    mostly bloated and pourly documented ALSA user space API ?
> 
> Because OSS API doesn't cover many things.  For example, 
> 
> - PCM with non-interleaved formats
There is no need to handle non-interleaved data in kernel level drivers 
because all the devices use interleaved formats. Handling 
interleaving/de-interleaving in the application/driver code can be done in 
a simple for loop. So why to make the driver/API more complicated with 
this.

> - PCM with 3-bytes-packed 24bit formats
Applications have no reasons to use for this kind of stupid format so OSS 
translates it to the usual 32 bit format on fly. In fact OSS API does 
have support for this format.

> These functions are popluar on many sound devices.
> 
> In addition, imagine how you would implement the following:
> 
> - Combination of multiple devices
> - Split of channels to concurrent accesses
Could you be more specific with the above isues?

> - Handling of floating pointer samples
This is not necessary in the kernel drivers because user land apps/libs do 
this themselves. However OSS API defines a floating point data type just 
in case some future device needs it.

> - Post/pre-effects (like chorus/reverb)
OSS already does this (part of the softoss/vmix driver).

> Forcing OSS API means to force to process the all things above in
> the kernel.  I guess many people would disagree with it.
Wrong. This is not an API issue at all. It's an implementation one. 

An alternative for doing some operations in the kernel is looping the 
audio data through an user land daemon. The application itself is still 
using the usual OSS API without knowing anything about any daemons. We 
have tested this approach and it works. There just has not been any good 
reason to use this approach instead of using kernel space approach. 
Passing data through multiple applications makes the latency issues to 
accumulate. If you do the processing in the kernel you will hit by the 
task scheduling latencies at most once.

The OSS approach is not to make everything in the kernel. Things that can 
be done easier in the applications (or in libraries) have been left 
out from the API.

Best regards,

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

Re: [OT] ALSA userspace API complexity

[Lee Revell]

On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > - PCM with 3-bytes-packed 24bit formats
> Applications have no reasons to use for this kind of stupid format so
> OSS translates it to the usual 32 bit format on fly. In fact OSS API
> does have support for this format. 

What about hardware that only understands this format?

Lee

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Thu, 5 Jan 2006, Lee Revell wrote:

> On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > > - PCM with 3-bytes-packed 24bit formats
> > Applications have no reasons to use for this kind of stupid format so
> > OSS translates it to the usual 32 bit format on fly. In fact OSS API
> > does have support for this format. 
> 
> What about hardware that only understands this format?
There is no such hardware. Or is there?

Best regards,

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

Re: [OT] ALSA userspace API complexity

[Lee Revell]

On Fri, 2006-01-06 at 01:56 +0200, Hannu Savolainen wrote:
> On Thu, 5 Jan 2006, Lee Revell wrote:
> 
> > On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > > > - PCM with 3-bytes-packed 24bit formats
> > > Applications have no reasons to use for this kind of stupid format so
> > > OSS translates it to the usual 32 bit format on fly. In fact OSS API
> > > does have support for this format. 
> > 
> > What about hardware that only understands this format?
> There is no such hardware. Or is there?
> 

Yep, the Roland SC-D70 and EDIROL UA-5 in "advanced mode", I guess it
lets them cram more channels of 24 bit audio over a slow USB pipe.  It's
no fun...

Lee

Re: [OT] ALSA userspace API complexity

[Lee Revell]

On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> We have not received any single bug report that is caused 
> by the concept of kernel mixing.
> Kernel mixing is not rocket science. All you need to do is picking a 
> sample from the output buffers of each of the applications, sum them 
> together (with some volume scaling) and feed the result to the
> physical 
> device. 

Hey, interesting, this is exactly what dmix does in userspace.  And we
have not seen any bug reports caused by the concept of userspace mixing
(just implementation bugs like any piece of software).

Lee

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Thu, 5 Jan 2006, Lee Revell wrote:

> On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > We have not received any single bug report that is caused 
> > by the concept of kernel mixing.
> > Kernel mixing is not rocket science. All you need to do is picking a 
> > sample from the output buffers of each of the applications, sum them 
> > together (with some volume scaling) and feed the result to the
> > physical 
> > device. 
> 
> Hey, interesting, this is exactly what dmix does in userspace.  And we
> have not seen any bug reports caused by the concept of userspace mixing
> (just implementation bugs like any piece of software).
Having dmix working in user space doesn't prove that kernel level mixing 
is evil. This was the original topic.

Best regards,

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

Re: [OT] ALSA userspace API complexity

[Stefan Smietanowski]

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

Hannu Savolainen wrote:
> On Thu, 5 Jan 2006, Lee Revell wrote:
> 
> 
>>On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
>>
>>>We have not received any single bug report that is caused 
>>>by the concept of kernel mixing.
>>>Kernel mixing is not rocket science. All you need to do is picking a 
>>>sample from the output buffers of each of the applications, sum them 
>>>together (with some volume scaling) and feed the result to the
>>>physical 
>>>device. 
>>
>>Hey, interesting, this is exactly what dmix does in userspace.  And we
>>have not seen any bug reports caused by the concept of userspace mixing
>>(just implementation bugs like any piece of software).
> 
> Having dmix working in user space doesn't prove that kernel level mixing 
> is evil. This was the original topic.

Wasn't there a thread a few years ago (3-5?) about sound mixing in the
kernel?

I've tried searching for it but have been unsuccessful so I could be
remembering wrong.

I can't remember if it was about OSS, ALSA or anything else but I
believe the conclusion was that sound mixing does NOT belong in the
kernel and SHOULD be done in userspace. I have a faint memory of that
being written by Alan Cox, but since it was a while ago I could very
well be mistaken there (too?).

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: [OT] ALSA userspace API complexity

[Erik Mouw]

On Fri, Jan 06, 2006 at 04:03:26PM +0100, Stefan Smietanowski wrote:
> Hannu Savolainen wrote:
> > Having dmix working in user space doesn't prove that kernel level mixing 
> > is evil. This was the original topic.
> 
> Wasn't there a thread a few years ago (3-5?) about sound mixing in the
> kernel?
> 
> I've tried searching for it but have been unsuccessful so I could be
> remembering wrong.

  "The kernel is an arbitrator of resources it is not a shit bucket for
   solving other peoples incompetence." -- Alan Cox

Here's the post:

  http://www.uwsg.indiana.edu/hypermail/linux/kernel/0105.3/0324.html


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: [OT] ALSA userspace API complexity

[Lee Revell]

On Fri, 2006-01-06 at 16:03 +0100, Stefan Smietanowski wrote:
> I can't remember if it was about OSS, ALSA or anything else but I
> believe the conclusion was that sound mixing does NOT belong in the
> kernel and SHOULD be done in userspace.

Well, sound mixing really belongs in hardware, but that seems to be a
lost cause - vendors are way too cheap these days.

I can't believe they managed to hoodwink Windows gamers into accepting a
new generation of sound devices that make the CPU do the work the
hardware used to do...

Lee

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Fri, 6 Jan 2006, Hannu Savolainen wrote:

> On Thu, 5 Jan 2006, Lee Revell wrote:
> 
> > On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
> > > We have not received any single bug report that is caused 
> > > by the concept of kernel mixing.
> > > Kernel mixing is not rocket science. All you need to do is picking a 
> > > sample from the output buffers of each of the applications, sum them 
> > > together (with some volume scaling) and feed the result to the
> > > physical 
> > > device. 
> > 
> > Hey, interesting, this is exactly what dmix does in userspace.  And we
> > have not seen any bug reports caused by the concept of userspace mixing
> > (just implementation bugs like any piece of software).
> Having dmix working in user space doesn't prove that kernel level mixing 
> is evil. This was the original topic.

Overloading interrupt handlers with extra things is evil (and I bet you're 
mixing samples in the interrupt handler). Even the network stack uses 
interrupts only for DMA management and not for any extra operations.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Tue, 10 Jan 2006, Jaroslav Kysela wrote:

> Overloading interrupt handlers with extra things is evil (and I bet you're 
> mixing samples in the interrupt handler). Even the network stack uses 
> interrupts only for DMA management and not for any extra operations.
You mean it's evil because nobody else is doing it? Then it must be  
evil or rather voodoo.

Best regards,

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

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Tue, 10 Jan 2006, Hannu Savolainen wrote:

> On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
> 
> > Overloading interrupt handlers with extra things is evil (and I bet you're 
> > mixing samples in the interrupt handler). Even the network stack uses 
> > interrupts only for DMA management and not for any extra operations.
> You mean it's evil because nobody else is doing it? Then it must be  
> evil or rather voodoo.

No, I mean that it's quite obvious bad design, because you might increase 
interrupt latencies for other drivers.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Tue, 10 Jan 2006, Jaroslav Kysela wrote:

> No, I mean that it's quite obvious bad design, because you might increase 
> interrupt latencies for other drivers.
Maybe if running with all interrupts disabled. 

The "mixing" time for one interrupt has been measured and it was smaller 
than the resolution of the measurement method (1 usec). It is indeed a 
serious risk to the system. 

Best regards,

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

Re: [OT] ALSA userspace API complexity

[Marcin Dalecki]

On 2006-01-10, at 15:08, Jaroslav Kysela wrote:

> On Tue, 10 Jan 2006, Hannu Savolainen wrote:
>
>> On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
>>
>>> Overloading interrupt handlers with extra things is evil (and I  
>>> bet you're
>>> mixing samples in the interrupt handler). Even the network stack  
>>> uses
>>> interrupts only for DMA management and not for any extra operations.
>> You mean it's evil because nobody else is doing it? Then it must be
>> evil or rather voodoo.
>
> No, I mean that it's quite obvious bad design, because you might  
> increase
> interrupt latencies for other drivers.

"Becasue you might" is a bad argument. Either you do or you don't. My  
guess is that you don't
becase the amount of data to be handled is absymally small. (Come one  
48kBaud is not much...)
And BTW. good luck trying to convince  the /dev/random gang that it  
isn't good for performance
what they are doing on the IRQ path...


Marcin Dalecki

Re: [OT] ALSA userspace API complexity

[Marcin Dalecki]

On 2006-01-06, at 00:40, Lee Revell wrote:

> On Fri, 2006-01-06 at 01:06 +0200, Hannu Savolainen wrote:
>> We have not received any single bug report that is caused
>> by the concept of kernel mixing.
>> Kernel mixing is not rocket science. All you need to do is picking a
>> sample from the output buffers of each of the applications, sum them
>> together (with some volume scaling) and feed the result to the
>> physical
>> device.
>
> Hey, interesting, this is exactly what dmix does in userspace.  And we
> have not seen any bug reports caused by the concept of userspace  
> mixing
> (just implementation bugs like any piece of software).

This attitude that every kind of software has to have bugs is
blunt idiotic tale-tale bullshit just showing off complete incompetence.

Does the acronym car-ABS and micro-controller maybe perhaps ring a  
bell for you? 

Re: [OT] ALSA userspace API complexity

[Martin Drab]

On Fri, 6 Jan 2006, Marcin Dalecki wrote:
> On 2006-01-06, at 00:40, Lee Revell wrote:
...
> > (just implementation bugs like any piece of software).
> 
> This attitude that every kind of software has to have bugs is
> blunt idiotic tale-tale bullshit just showing off complete incompetence.

Now you're dreaming, right? Because as much as we all don't like it, it is 
a realistic fact. There's just NO WAY you can responsibly say about any 
piece software, that it is completely error free. I think there's lots of 
people (especially) on this list, that may confirm that.

Martin

Re: [OT] ALSA userspace API complexity

[Marcin Dalecki]

On 2006-01-06, at 01:29, Martin Drab wrote:

> Because as much as we all don't like it, it is
> a realistic fact. There's just NO WAY you can responsibly say about  
> any
> piece software, that it is completely error free.

You would be for example surprised to see how complex the software  
controlling the breaks
of a reasonable modern car turns out to be... This is just a  
technical example running contrary
to your "wisdom". In numerical computations you can find reasonable  
amounts of software
which is precisely just that - bug free. There are mathematical  
proofs running for hundreds of pages,
which are just valid. Do you think this kind of guys doesn't ever sit  
down and write
some piece of software to help out well for example in determining  
some aerodynamics of a plane?
Are you assuming this kind of applications is trivial and by virtue  
of a natural law bug ridden?

And by the way: the zero program which has nothing to do is bug free.  
QED.

Re: [OT] ALSA userspace API complexity

[Martin Drab]

On Fri, 6 Jan 2006, Marcin Dalecki wrote:
> On 2006-01-06, at 01:29, Martin Drab wrote:
> 
> > Because as much as we all don't like it, it is
> > a realistic fact. There's just NO WAY you can responsibly say about any
> > piece software, that it is completely error free.
> 
> You would be for example surprised to see how complex the software controlling
> the breaks
> of a reasonable modern car turns out to be... This is just a technical example

No doubts it is.

> running contrary
> to your "wisdom". In numerical computations you can find reasonable amounts of
> software
> which is precisely just that - bug free. There are mathematical proofs running
> for hundreds of pages,
> which are just valid.

Yes, I know. That, however, still doesn't necesarilly mean that it has to 
be completely error free. (An error must not necessarily mean a complete 
screw-up.)

> Do you think this kind of guys doesn't ever sit down and
> write
> some piece of software to help out well for example in determining some
> aerodynamics of a plane?

I know they do. Again, it doesn't mean that that software has to be 
completely error free.

> Are you assuming this kind of applications is trivial and by virtue of a
> natural law bug ridden?

Well, I'm moving in an environment of nuclear energy, physics, and 
mathematical modelling a bit for quite some while. And I know, that you 
can never be absolutely certain that any (reasonably complex) software is 
completely error free.

Apart from that, that in those really critical cases (such as a primary 
controlling system of a nuclear reactor), you are actually forced to just 
a strict subset of a strictly defined programming languages, it is just 
that, that forces you to have tons of various sophisticated checking and 
safety mechanisms implemented in the software to prevent any possible bugs 
to do any serious harm, which in this case can no doubt be very terminal.
Overconfidence in these cases is not in place, even though these really 
are the ones that are really thotoughly checked for bugs.

> And by the way: the zero program which has nothing to do is bug free. QED.

Ah, OK, you got me on that one. :) But that's not quite what I had in 
mind.

Anyway, I guess we're quite by far OT with this. So I think we should just 
leave it at that, and let everybody draw their own conclusions to their 
own best knowledge. Sorry for bothering with this.

Martin

Re: [OT] ALSA userspace API complexity

[Zan Lynx]

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

On Fri, 2006-01-06 at 01:14 +0100, Marcin Dalecki wrote:
> On 2006-01-06, at 00:40, Lee Revell wrote:
> > Hey, interesting, this is exactly what dmix does in userspace.  And we
> > have not seen any bug reports caused by the concept of userspace  
> > mixing
> > (just implementation bugs like any piece of software).
> 
> This attitude that every kind of software has to have bugs is
> blunt idiotic tale-tale bullshit just showing off complete incompetence.
> 
> Does the acronym car-ABS and micro-controller maybe perhaps ring a  
> bell for you? 

Funny that you should mention bug-free code and ABS.

Just a few months ago, Subaru updated the ABS controller code for the
WRX.  They sent me the notice in the mail.  It was an optional upgrade,
the change was only needed to fix some very odd corner cases.  

The point being that even critical micro-controller software has bugs.

Even software that has been mathematically proofed can have bugs.  Knuth
uses it as a joke: "Beware bugs in the above code.  I have
proven it correct; I have not actually tried it."

It's so funny because it's so true.
-- 
Zan Lynx <zlynx@acm.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [OT] ALSA userspace API complexity

[Stefan Smietanowski]

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

Zan Lynx wrote:
> On Fri, 2006-01-06 at 01:14 +0100, Marcin Dalecki wrote:
> 
>>On 2006-01-06, at 00:40, Lee Revell wrote:
>>
>>>Hey, interesting, this is exactly what dmix does in userspace.  And we
>>>have not seen any bug reports caused by the concept of userspace  
>>>mixing
>>>(just implementation bugs like any piece of software).
>>
>>This attitude that every kind of software has to have bugs is
>>blunt idiotic tale-tale bullshit just showing off complete incompetence.
>>
>>Does the acronym car-ABS and micro-controller maybe perhaps ring a  
>>bell for you? 
> 
> 
> Funny that you should mention bug-free code and ABS.
> 
> Just a few months ago, Subaru updated the ABS controller code for the
> WRX.  They sent me the notice in the mail.  It was an optional upgrade,
> the change was only needed to fix some very odd corner cases.  
> 
> The point being that even critical micro-controller software has bugs.
> 
> Even software that has been mathematically proofed can have bugs.  Knuth
> uses it as a joke: "Beware bugs in the above code.  I have
> proven it correct; I have not actually tried it."
> 
> It's so funny because it's so true.

Same as when Renault introduced the keyless system in the Laguna in 2001
(some call it the Laguna II) - it's basically a card you stick into a
slot in the console which enables you to just press a button to start
the car instead of turning a key and it also contained memory about
your chair settings, mirrors and volume/sound settings of the radio.

Now, is this a highly complex piece of software running there to do
those things?

Regardless of how what someone believes - a few months later someone
was out driving and all of a sudden the car started speeding up and
since there was no key you couldn't turn the car off and the breaks
weren't strong enough to slow the car down and running at roughly
200kph he managed to YANK the card out of the slot before it could be
slowed down and the ignition turned off - the guy was lucky to be
alive.

It turns out that it was a combination of a bug in the keyless
system AND the cruise control that made this happen - two bugs
that in themselves wouldn't have triggered but at the right speed,
and when everything matched things went haywire, so no, no matter
how tight you write specifications or papers you can't get
everything bugfree, even in such a simple system as a keycard
for your car. Note that one of the bugs WAS in the keycard.

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: [OT] ALSA userspace API complexity

[jerome lacoste]

On 1/6/06, Stefan Smietanowski <stesmi@stesmi.com> wrote:
[...]

> Same as when Renault introduced the keyless system in the Laguna in 2001
> (some call it the Laguna II) - it's basically a card you stick into a
> slot in the console which enables you to just press a button to start
> the car instead of turning a key and it also contained memory about
> your chair settings, mirrors and volume/sound settings of the radio.
>
> Now, is this a highly complex piece of software running there to do
> those things?
>
> Regardless of how what someone believes - a few months later someone
> was out driving and all of a sudden the car started speeding up and
> since there was no key you couldn't turn the car off and the breaks
> weren't strong enough to slow the car down and running at roughly
> 200kph he managed to YANK the card out of the slot before it could be
> slowed down and the ignition turned off - the guy was lucky to be
> alive.

I think you are mixing 2 stories. According to my sources, the driver
of a Renault Vel Satis reported a similar issue and got stuck at
around 190kmph during an hour in October 2004. In March 2005, the
driver of a Laguna reported that he got stuck at 90 kmph for 40km.

> It turns out that it was a combination of a bug in the keyless
> system AND the cruise control that made this happen - two bugs
> that in themselves wouldn't have triggered but at the right speed,
> and when everything matched things went haywire, so no, no matter
> how tight you write specifications or papers you can't get
> everything bugfree, even in such a simple system as a keycard
> for your car. Note that one of the bugs WAS in the keycard.

To my knowledge, none of the reported issues have yet been identified
as coming from the car. I searched again before posting and found no
reference to that issue.

I would be happy to know where you found this information. At least to
know if the constructors are hidding something.

Cheers,

> // Stefan

Jerome

Re: [OT] ALSA userspace API complexity

[Stefan Smietanowski]

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

Hi.

>>Same as when Renault introduced the keyless system in the Laguna in 2001
>>(some call it the Laguna II) - it's basically a card you stick into a
>>slot in the console which enables you to just press a button to start
>>the car instead of turning a key and it also contained memory about
>>your chair settings, mirrors and volume/sound settings of the radio.
>>
>>Now, is this a highly complex piece of software running there to do
>>those things?
>>
>>Regardless of how what someone believes - a few months later someone
>>was out driving and all of a sudden the car started speeding up and
>>since there was no key you couldn't turn the car off and the breaks
>>weren't strong enough to slow the car down and running at roughly
>>200kph he managed to YANK the card out of the slot before it could be
>>slowed down and the ignition turned off - the guy was lucky to be
>>alive.
> 
> 
> I think you are mixing 2 stories. According to my sources, the driver
> of a Renault Vel Satis reported a similar issue and got stuck at
> around 190kmph during an hour in October 2004. In March 2005, the
> driver of a Laguna reported that he got stuck at 90 kmph for 40km.

Hm.

>>It turns out that it was a combination of a bug in the keyless
>>system AND the cruise control that made this happen - two bugs
>>that in themselves wouldn't have triggered but at the right speed,
>>and when everything matched things went haywire, so no, no matter
>>how tight you write specifications or papers you can't get
>>everything bugfree, even in such a simple system as a keycard
>>for your car. Note that one of the bugs WAS in the keycard.
> 
> 
> To my knowledge, none of the reported issues have yet been identified
> as coming from the car. I searched again before posting and found no
> reference to that issue.
> 
> I would be happy to know where you found this information. At least to
> know if the constructors are hidding something.

Timeframe of the Laguna incident is roughly correct to my memory. It
was reported in the Swedish newspapers. I'll try searching for it
and see what I come up with, even though it's totally OT.

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

Re: [OT] ALSA userspace API complexity

[Edgar Toernig]

Hannu Savolainen wrote:
>
> Takashi Iwai wrote:
> >
> > - Split of channels to concurrent accesses
>
> Could you be more specific with the above isues?

As I understand it: instead of providing one device with 5.1 capabilities
provide one device with 3 concurrent stereo users.  Reading the datasheet
of my AC'97 decoder (a cheap ALC650 connected to an ATIIXP) there is hard-
ware that supports this[1].

Sure, Alsa can do all of this and more in software - somehow ...

Ciao, ET.

[1] Unless the ATIIXP has some limitations - there are no docs 
    available :-(

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Fri, 6 Jan 2006, Edgar Toernig wrote:

> Hannu Savolainen wrote:
> >
> > Takashi Iwai wrote:
> > >
> > > - Split of channels to concurrent accesses
> >
> > Could you be more specific with the above isues?
> 
> As I understand it: instead of providing one device with 5.1 capabilities
> provide one device with 3 concurrent stereo users.  Reading the datasheet
> of my AC'97 decoder (a cheap ALC650 connected to an ATIIXP) there is hard-
> ware that supports this[1].
Then this is in no way an API issue. Many OSS drivers (including envy24) 
create separete device files for each input/output channel (or device pair). 
Applications can chose to open the first device file in for all the 
channels or any combination of the devices in mono/stereo/n-channel mode.

All this depends only on the driver implementation. There is nothing API 
related. Any app can open the devices as usual without paying any 
attention on the channel allocation (which is done automatically by the 
driver). xmms (or whatever else consumer app) can open the device and ask 
for stereo access. Equally well a DAB application can open the device and 
ask for full 10 output channels (or anything between 1 and 10). No special 
API features are needed for this.

Best regards,

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

Re: [OT] ALSA userspace API complexity

[Florian Schmidt]

On Fri, 6 Jan 2006 05:33:43 +0200 (EET)
Hannu Savolainen <hannu@opensound.com> wrote:

> Then this is in no way an API issue. Many OSS drivers (including envy24) 
> create separete device files for each input/output channel (or device pair). 
> Applications can chose to open the first device file in for all the 
> channels or any combination of the devices in mono/stereo/n-channel mode.
> 
> All this depends only on the driver implementation. There is nothing API 
> related. Any app can open the devices as usual without paying any 
> attention on the channel allocation (which is done automatically by the 
> driver). xmms (or whatever else consumer app) can open the device and ask 
> for stereo access. Equally well a DAB application can open the device and 
> ask for full 10 output channels (or anything between 1 and 10). No special 
> API features are needed for this.

Hi,

i would find it helpful if you always made it crystal  clear about what
version of OSS you are talking about:

- your proprietary version

- or the free one in the kernel

Mixing these isn't helping the discussion.

Flo

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

Re: [OT] ALSA userspace API complexity

[Jan Engelhardt]

>> > If you have sound device without this soft mixing is moved to user space 
>> > .. but  applications do not need know about this even now because all
>> > neccessary details are handled on library level. Is it ?
>> > So question is: why the hell *ALL* mixing details are not moved to kernel 
>> > space to SIMPLE and NOT GROWING abstraction ?
>> 
>> Because many people believe that the softmix in the kernel space is
>> evil.
>>
>This is the usual argument against kernel level mixing. Somebody has once 
>said that all this is evil. However this is not necessarily correct.
>

I'm going with "is evil". Better let userspace have a segfault than a kernel
oops. I am having quite a moody feeling when running even my own things like
http://alphagate.hopto.org/quad_dsp/

>Kernel mixing is not rocket science. All you need to do is picking a 
>sample from the output buffers of each of the applications, sum them 
>together (with some volume scaling) and feed the result to the physical 
>device. Ok, handling different sample formats/rates makes it much more 
>difficult but that could be done in the library level.



Jan Engelhardt
-- 

Re: [OT] ALSA userspace API complexity

[Takashi Iwai]

At Fri, 6 Jan 2006 01:06:27 +0200 (EET),
Hannu Savolainen wrote:
> 
> On Thu, 5 Jan 2006, Takashi Iwai wrote:
> 
> > > If you have sound device without this soft mixing is moved to user space 
> > > .. but  applications do not need know about this even now because all
> > > neccessary details are handled on library level. Is it ?
> > > So question is: why the hell *ALL* mixing details are not moved to kernel 
> > > space to SIMPLE and NOT GROWING abstraction ?
> > 
> > Because many people believe that the softmix in the kernel space is
> > evil.
> This is the usual argument against kernel level mixing. Somebody has once 
> said that all this is evil. However this is not necessarily correct.
> 
> OSS has done kernel level mixing for years. The vmix driver has been used 
> as the default audio device by hundreds of thousands of customers for 
> years. We have not received any single bug report that is caused 
> by the concept of kernel mixing.
> 
> Kernel mixing is not rocket science. All you need to do is picking a 
> sample from the output buffers of each of the applications, sum them 
> together (with some volume scaling) and feed the result to the physical 
> device. Ok, handling different sample formats/rates makes it much more 
> difficult but that could be done in the library level.

Yes, but which library?


> > >    Why Linux can't provide only OSS API abstraction for user space
> > >    application ? And/or why ALSA developers want to replace this by
> > >    mostly bloated and pourly documented ALSA user space API ?
> > 
> > Because OSS API doesn't cover many things.  For example, 
> > 
> > - PCM with non-interleaved formats
> There is no need to handle non-interleaved data in kernel level drivers 
> because all the devices use interleaved formats.

Many RME boards support only non-intereleave data.

> Handling 
> interleaving/de-interleaving in the application/driver code can be done in 
> a simple for loop. So why to make the driver/API more complicated with 
> this.
> 
> > - PCM with 3-bytes-packed 24bit formats
> Applications have no reasons to use for this kind of stupid format so OSS 
> translates it to the usual 32 bit format on fly. In fact OSS API does 
> have support for this format.

Well, this is stupid but very popular nowadays, unforunately :)


> > These functions are popluar on many sound devices.
> > 
> > In addition, imagine how you would implement the following:
> > 
> > - Combination of multiple devices
> > - Split of channels to concurrent accesses
> Could you be more specific with the above isues?

I meant to split channels of a single device to different processes
(e.g. front/rear/clfe for each).  (I know it's doable but the question
is how to implement it.)


> > - Handling of floating pointer samples
> This is not necessary in the kernel drivers because user land apps/libs do 
> this themselves. However OSS API defines a floating point data type just 
> in case some future device needs it.
> 
> > - Post/pre-effects (like chorus/reverb)
> OSS already does this (part of the softoss/vmix driver).
> 
> > Forcing OSS API means to force to process the all things above in
> > the kernel.  I guess many people would disagree with it.
> Wrong. This is not an API issue at all. It's an implementation one. 

Indeed.  But you know that almost all "OSS" applications access
directly the device files.  There is no room to put a library to solve
these things in user-space.


> An alternative for doing some operations in the kernel is looping the 
> audio data through an user land daemon. The application itself is still 
> using the usual OSS API without knowing anything about any daemons. We 
> have tested this approach and it works. There just has not been any good 
> reason to use this approach instead of using kernel space approach. 
> Passing data through multiple applications makes the latency issues to 
> accumulate. If you do the processing in the kernel you will hit by the 
> task scheduling latencies at most once.

Yes, I thought of the similar thing...  But, is it really a preferred
approach?


> The OSS approach is not to make everything in the kernel. Things that can 
> be done easier in the applications (or in libraries) have been left 
> out from the API.

Basically, it's not 100% fault of OSS, IMO.  But, looking at the
reality, apps do access directly to the kernel.  It's worse in the
case of binary-only apps like flash or skype.  To support these
things, the only "realistic" (OSS-ish) solution so far is to implement
the conversion routines in the kernel level.


Takashi

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Sun, 8 Jan 2006, Hannu Savolainen wrote:

> On Sat, 7 Jan 2006, Takashi Iwai wrote:
> 
> > > > Because OSS API doesn't cover many things.  For example, 
> > > > 
> > > > - PCM with non-interleaved formats
> > > There is no need to handle non-interleaved data in kernel level drivers 
> > > because all the devices use interleaved formats.
> > 
> > Many RME boards support only non-intereleave data.
> In such cases it's better to do interleavin/deinterleaving in the kernel 
> rather than forcing the apps to check which method they should use.

I don't think so. The library can do such conversions (and alsa-lib does) 
quite easy. If we have a possibility to remove the code from the kernel 
space without any drawbacks, then it should be removed. I don't see any 
advantage to have such conversions in the kernel.

> > Indeed.  But you know that almost all "OSS" applications access
> > directly the device files.  There is no room to put a library to solve
> > these things in user-space.
> Why should there be any need to put library code between the kernel API 
> and an application that is perfectly happy with it? It is only necessary 
> if somebody wants to emulate the OSS kernel API in library level.
> 
> A wrapper library with routines like oss_open, oss_write, etc was once 
> considered. However we didn't find any good reason to do that (in 
> particular because that conflicted with routine names already used 
> internally in some important OSS applications).

Bad decision. Again, I feel you're hidding the flexibility against
your feeling that the kernel API is the best enough for applications.
Imagine that the API redirection is or can be also flexible for your 
future development.

> What if there is some better way to handle OSS-ALSA interaction than 
> library level hooks/emulation. In the short term this may be difficult 
> because OSS is binary only and outside the kernel. But in long run OSS can 
> hopefully be open sourced which could make it possible to use solutions 
> like merging the kernel space drivers together.
> 
> Actually I have forgotten what was the reason why you wanted to get the 
> OSS API emulated in userland rather than using the previous snd-oss 
> module (which worked well other than the API version you emulated was too 
> old)?

Stream mixing. We have user space solution while you insist to put this 
code to kernel. Simply, we need to go through our library.

>From the end user perspective, don't you think that having an opportunity 
to change the API entry point from one to multiple (user space library - 
preferred, direct kernel space - last resort) is more flexible for 
developers and users? Please, consider this question without any flames 
line which API is better and what's better for audio subsystem architects 
and what's better for your commercial work.

						Jaroslav

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[René Rebe]

Hi,

On Sunday 08 January 2006 10:24, Jaroslav Kysela wrote:

> > > > > - PCM with non-interleaved formats
> > > > There is no need to handle non-interleaved data in kernel level drivers 
> > > > because all the devices use interleaved formats.
> > > 
> > > Many RME boards support only non-intereleave data.
> > In such cases it's better to do interleavin/deinterleaving in the kernel 
> > rather than forcing the apps to check which method they should use.
> 
> I don't think so. The library can do such conversions (and alsa-lib does) 
> quite easy. If we have a possibility to remove the code from the kernel 
> space without any drawbacks, then it should be removed. I don't see any 
> advantage to have such conversions in the kernel.

Also, when the data is already available as single streams in a user-space
multi track application, why should it be forced interleaved, when the hardware
could handle the format just fine?

Yours,
  Rene

-- 
ExactCODE, Berlin

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

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

On Mon, 9 Jan 2006, René Rebe wrote:

> > I don't think so. The library can do such conversions (and alsa-lib does) 
> > quite easy. If we have a possibility to remove the code from the kernel 
> > space without any drawbacks, then it should be removed. I don't see any 
> > advantage to have such conversions in the kernel.
> 
> Also, when the data is already available as single streams in a user-space
> multi track application, why should it be forced interleaved, when the hardware
> could handle the format just fine?
Because the conversion doesn't cost anything. Trying to avoid it by 
making the API more complicated (I would even say confusing) is extreme 
overkill. 

Each feature of this kind requires two additional API 
calls (one for checking in which way the hardware works and another to 
set the device to use the feature). It's also possible to implement the 
feature in a way that requires more new calls. By adding support for 
dozens of features like this it's easy to create an API that has 1500+ 
calls.

Even worse this kind of features weaken the device abstraction provided by 
the API. The applications will have to check for this and 
that and provide support for 100s of special cases that may be required by 
certain devices. 

IMHO this has already happened with ALSA. Normal 
programmers (other than few of the world class gurus) have no way to 
understand the API. I would consider myself at least moderately 
experienced sound programmer (25+ years of programming experience and more 
than half of it on sound). However even after two years of more or less 
intense learning I don't know what is the preferred way to use ALSA. I 
think this is a general problem because practically all ALSA applications use 
different ALSA API calls.

Best regards,

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[René Rebe]

Hi,

On Monday 09 January 2006 16:10, Hannu Savolainen wrote:

> > > I don't think so. The library can do such conversions (and alsa-lib does) 
> > > quite easy. If we have a possibility to remove the code from the kernel 
> > > space without any drawbacks, then it should be removed. I don't see any 
> > > advantage to have such conversions in the kernel.
> > 
> > Also, when the data is already available as single streams in a user-space
> > multi track application, why should it be forced interleaved, when the hardware
> > could handle the format just fine?
> Because the conversion doesn't cost anything. Trying to avoid it by 
> making the API more complicated (I would even say confusing) is extreme 
> overkill. 

Since when doesn't cost convesion anything? I'm able to count a lot of wasted
CPU cycles in there ...

> Even worse this kind of features weaken the device abstraction provided by 
> the API. The applications will have to check for this and 
> that and provide support for 100s of special cases that may be required by 
> certain devices. 

An lame write() only player can still open the default device and get the auto-convert
chain it deserves ...

Yours,
  Rene Rebe

-- 
ExactCODE Berlin

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[David Lang]

On Mon, 9 Jan 2006, René Rebe wrote:

> On Monday 09 January 2006 16:10, Hannu Savolainen wrote:
>
>>>> I don't think so. The library can do such conversions (and alsa-lib does)
>>>> quite easy. If we have a possibility to remove the code from the kernel
>>>> space without any drawbacks, then it should be removed. I don't see any
>>>> advantage to have such conversions in the kernel.
>>>
>>> Also, when the data is already available as single streams in a user-space
>>> multi track application, why should it be forced interleaved, when the hardware
>>> could handle the format just fine?
>> Because the conversion doesn't cost anything. Trying to avoid it by
>> making the API more complicated (I would even say confusing) is extreme
>> overkill.
>
> Since when doesn't cost convesion anything? I'm able to count a lot of wasted
> CPU cycles in there ...

if the data needed to be accessed by the CPU anyway it's free becouse 
otherwise the CPU would stall waiting for the next chunk of memory. you 
can do quite a bit of work on data in cache while you are waiting for the 
next cache line to load.

in this same way, checksumming a network packet is free if the CPU needs 
to copy the data anway, it only costs something if the data could bypass 
the CPU.

David Lang

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[John Rigg]

On Mon, Jan 09, 2006 at 01:58:00PM -0800, David Lang wrote:
> On Mon, 9 Jan 2006, René Rebe wrote:
> 
> >On Monday 09 January 2006 16:10, Hannu Savolainen wrote:
> >
> >>>>I don't think so. The library can do such conversions (and alsa-lib 
> >>>>does)
> >>>>quite easy. If we have a possibility to remove the code from the kernel
> >>>>space without any drawbacks, then it should be removed. I don't see any
> >>>>advantage to have such conversions in the kernel.
> >>>
> >>>Also, when the data is already available as single streams in a 
> >>>user-space
> >>>multi track application, why should it be forced interleaved, when the 
> >>>hardware
> >>>could handle the format just fine?
> >>Because the conversion doesn't cost anything. Trying to avoid it by
> >>making the API more complicated (I would even say confusing) is extreme
> >>overkill.
> >
> >Since when doesn't cost convesion anything? I'm able to count a lot of 
> >wasted
> >CPU cycles in there ...
> 
> if the data needed to be accessed by the CPU anyway it's free becouse 
> otherwise the CPU would stall waiting for the next chunk of memory. you 
> can do quite a bit of work on data in cache while you are waiting for the 
> next cache line to load.
> 
> in this same way, checksumming a network packet is free if the CPU needs 
> to copy the data anway, it only costs something if the data could bypass 
> the CPU.

Yes, but the CPU has plenty of other work to do. The sound cards that
would be worst affected by this are the big RME cards (non-interleaved) and
multiple ice1712 cards (non-interleaved blocks of interleaved data),
which AFAIK are the only cards capable of handling serious professional audio.
This could represent 48 or more channels of 96kHz audio, which
doesn't leave a lot of spare CPU capacity for running X, for example.

John

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[David Lang]

On Mon, 9 Jan 2006, John Rigg wrote:

> On Mon, Jan 09, 2006 at 01:58:00PM -0800, David Lang wrote:
>> On Mon, 9 Jan 2006, René Rebe wrote:
>>>>>
>>>>> Also, when the data is already available as single streams in a
>>>>> user-space
>>>>> multi track application, why should it be forced interleaved, when the
>>>>> hardware
>>>>> could handle the format just fine?
>>>> Because the conversion doesn't cost anything. Trying to avoid it by
>>>> making the API more complicated (I would even say confusing) is extreme
>>>> overkill.
>>>
>>> Since when doesn't cost convesion anything? I'm able to count a lot of
>>> wasted
>>> CPU cycles in there ...
>>
>> if the data needed to be accessed by the CPU anyway it's free becouse
>> otherwise the CPU would stall waiting for the next chunk of memory. you
>> can do quite a bit of work on data in cache while you are waiting for the
>> next cache line to load.
>>
>> in this same way, checksumming a network packet is free if the CPU needs
>> to copy the data anway, it only costs something if the data could bypass
>> the CPU.
>
> Yes, but the CPU has plenty of other work to do. The sound cards that
> would be worst affected by this are the big RME cards (non-interleaved) and
> multiple ice1712 cards (non-interleaved blocks of interleaved data),
> which AFAIK are the only cards capable of handling serious professional audio.
> This could represent 48 or more channels of 96kHz audio, which
> doesn't leave a lot of spare CPU capacity for running X, for example.

does the CPU touch the data for these, or do you DMA directly from 
userspace (i.e. "zero-copy")?

if the cpu touches this data on it's way in and out of the system then you 
are going to have a time period where you are maxing out the memory bus of 
your CPU (this may be a short time, but since the bus is either active or 
not there will be a time when it's active transfering audio data :-). 
while the memory bus is busy transfering the audio data your cpu can only 
work on data that's in the cache.

remember that as you keep reading the data from memory it will push other 
stuff out of your cache.

what magic do you pull to have the CPU busy on other things while the 
cache (and memory bus) is being occupied by the audio data transfers?

David Lang

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[John Rigg]

On Mon, Jan 09, 2006 at 03:21:21PM -0800, David Lang wrote:
> On Mon, 9 Jan 2006, John Rigg wrote:
> 
> >On Mon, Jan 09, 2006 at 01:58:00PM -0800, David Lang wrote:
> >>On Mon, 9 Jan 2006, René Rebe wrote:
> >>>>>
> >>>>>Also, when the data is already available as single streams in a
> >>>>>user-space
> >>>>>multi track application, why should it be forced interleaved, when the
> >>>>>hardware
> >>>>>could handle the format just fine?
> >>>>Because the conversion doesn't cost anything. Trying to avoid it by
> >>>>making the API more complicated (I would even say confusing) is extreme
> >>>>overkill.
> >>>
> >>>Since when doesn't cost convesion anything? I'm able to count a lot of
> >>>wasted
> >>>CPU cycles in there ...
> >>
> >>if the data needed to be accessed by the CPU anyway it's free becouse
> >>otherwise the CPU would stall waiting for the next chunk of memory. you
> >>can do quite a bit of work on data in cache while you are waiting for the
> >>next cache line to load.
> >>
> >>in this same way, checksumming a network packet is free if the CPU needs
> >>to copy the data anway, it only costs something if the data could bypass
> >>the CPU.
> >
> >Yes, but the CPU has plenty of other work to do. The sound cards that
> >would be worst affected by this are the big RME cards (non-interleaved) and
> >multiple ice1712 cards (non-interleaved blocks of interleaved data),
> >which AFAIK are the only cards capable of handling serious professional 
> >audio.
> >This could represent 48 or more channels of 96kHz audio, which
> >doesn't leave a lot of spare CPU capacity for running X, for example.
> 
> does the CPU touch the data for these, or do you DMA directly from 
> userspace (i.e. "zero-copy")?

The cards I mentioned use DMA. RME actually advertises that some of their
cards can handle 52 channels with zero CPU load. Their onboard DSPs can
also do routing and mixing, again without touching the CPU.

John

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[David Lang]

On Tue, 10 Jan 2006, John Rigg wrote:

>> does the CPU touch the data for these, or do you DMA directly from
>> userspace (i.e. "zero-copy")?
>
> The cards I mentioned use DMA. RME actually advertises that some of their
> cards can handle 52 channels with zero CPU load. Their onboard DSPs can
> also do routing and mixing, again without touching the CPU.

I was under the (apparently mistaken) impression that you couldn't DMA 
from userspace (something to do with the possibility that the userspace 
memory pages could be swapped out in the middle of the DMA)

David Lang

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Alan Cox]

On Llu, 2006-01-09 at 16:29 -0800, David Lang wrote:
> I was under the (apparently mistaken) impression that you couldn't DMA 
> from userspace (something to do with the possibility that the userspace 
> memory pages could be swapped out in the middle of the DMA)

Drivers can choose to support this two different ways. One is to have a
buffer of kernel memory mapped into user space and shared with the
hardware (this is how OSS did it), the other is to use the 2.6
get_user_pages API to get the physical address of a set of pages and
lock them down so they don't wander off during DMA.

Both have advantages for different uses.

Alan

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Lee Revell]

On Tue, 2006-01-10 at 00:44 +0000, Alan Cox wrote:
> On Llu, 2006-01-09 at 16:29 -0800, David Lang wrote:
> > I was under the (apparently mistaken) impression that you couldn't DMA 
> > from userspace (something to do with the possibility that the userspace 
> > memory pages could be swapped out in the middle of the DMA)
> 
> Drivers can choose to support this two different ways. One is to have a
> buffer of kernel memory mapped into user space and shared with the
> hardware (this is how OSS did it), the other is to use the 2.6
> get_user_pages API to get the physical address of a set of pages and
> lock them down so they don't wander off during DMA.
> 
> Both have advantages for different uses.

ALSA would appear to use the first method (get_user_pages does not
appear in the source), presumably because new ALSA versions still
support 2.4 (and 2.2, maybe even 2.0).

Lee

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[John Rigg]

On Mon, Jan 09, 2006 at 04:29:45PM -0800, David Lang wrote:
> On Tue, 10 Jan 2006, John Rigg wrote:
> 
> >>does the CPU touch the data for these, or do you DMA directly from
> >>userspace (i.e. "zero-copy")?
> >
> >The cards I mentioned use DMA. RME actually advertises that some of their
> >cards can handle 52 channels with zero CPU load. Their onboard DSPs can
> >also do routing and mixing, again without touching the CPU.
> 
> I was under the (apparently mistaken) impression that you couldn't DMA 
> from userspace (something to do with the possibility that the userspace 
> memory pages could be swapped out in the middle of the DMA)

Hmm. Maybe I've been paying too much attention to card vendors'
sales talk :)

John

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[John Rigg]

On Tue, Jan 10, 2006 at 12:16:17AM +0000, John Rigg wrote:
> On Mon, Jan 09, 2006 at 03:21:21PM -0800, David Lang wrote:
> > does the CPU touch the data for these, or do you DMA directly from 
> > userspace (i.e. "zero-copy")?
> 
> The cards I mentioned use DMA. RME actually advertises that some of their
> cards can handle 52 channels with zero CPU load. Their onboard DSPs can
> also do routing and mixing, again without touching the CPU.

Of course I should also mention that the sound cards deal with PCM audio
samples in integer format, but audio apps like jackd and its clients use
floating point, so in practice the CPU is still processing audio data much
of the time.

John

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Mon, 9 Jan 2006, John Rigg wrote:

> Yes, but the CPU has plenty of other work to do. The sound cards that
> would be worst affected by this are the big RME cards (non-interleaved) and
> multiple ice1712 cards (non-interleaved blocks of interleaved data),
ice1712 uses normal interleaving. There are no "non-interleaved blocks".

> which AFAIK are the only cards capable of handling serious professional audio.
> This could represent 48 or more channels of 96kHz audio, which
> doesn't leave a lot of spare CPU capacity for running X, for example.

This is true only if you run the system at full 100% load before the 
conversions. But in real life you cannot do this anyway. You have to use 
a CPU that has lot of spare power. Otherwise anything unpredictable will 
make things to fail.

Best regards,

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[John Rigg]

On Tue, Jan 10, 2006 at 02:48:35AM +0200, Hannu Savolainen wrote:
> On Mon, 9 Jan 2006, John Rigg wrote:
> 
> > Yes, but the CPU has plenty of other work to do. The sound cards that
> > would be worst affected by this are the big RME cards (non-interleaved) and
> > multiple ice1712 cards (non-interleaved blocks of interleaved data),
> ice1712 uses normal interleaving. There are no "non-interleaved blocks".

With two ice1712 cards I had to patch jackd for MMAP_COMPLEX
support to make them work together. My understanding was that the
individual cards use interleaved data, but when several are combined
the resulting blocks of data are not interleaved together. I realise the
usual way of dealing with this is to use the alsa route plugin with
ttable to interleave them, but I couldn't get it to work with these
cards.

John

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Tue, 10 Jan 2006, John Rigg wrote:

> On Tue, Jan 10, 2006 at 02:48:35AM +0200, Hannu Savolainen wrote:
> > On Mon, 9 Jan 2006, John Rigg wrote:
> > 
> > > Yes, but the CPU has plenty of other work to do. The sound cards that
> > > would be worst affected by this are the big RME cards (non-interleaved) and
> > > multiple ice1712 cards (non-interleaved blocks of interleaved data),
> > ice1712 uses normal interleaving. There are no "non-interleaved blocks".
> 
> With two ice1712 cards I had to patch jackd for MMAP_COMPLEX
> support to make them work together. My understanding was that the
> individual cards use interleaved data, but when several are combined
> the resulting blocks of data are not interleaved together. I realise the
> usual way of dealing with this is to use the alsa route plugin with
> ttable to interleave them, but I couldn't get it to work with these
> cards.
Right. If you use two cards then both of them have independently 
interleaved blocks. However if this kind of mapping belongs to the lowest 
level audio API or not is yet another API feature to argue about.  Higher 
level libraries like Jack could do this themselves.

Best regards,

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Mon, 9 Jan 2006, Hannu Savolainen wrote:

> > >From the end user perspective, don't you think that having an opportunity 
> > to change the API entry point from one to multiple (user space library - 
> > preferred, direct kernel space - last resort) is more flexible for 
> > developers and users? Please, consider this question without any flames 
> > line which API is better and what's better for audio subsystem architects 
> > and what's better for your commercial work.
> It's too late to discuss about this. This decision could have been made in 
> 1992-1993 before large number of applications were already written. 
> Unfortunately the whole issue was raised just recently.
> 
> There has been definitions for routines like osslib_open(), etc in 
> soundcard.h for years. Also the libOSSlib.so library contains such 
> routines. If an OSS application is compiled without -DOSSLIB then they are 
> defined as open, etc. Unfortunately this version of soundcard.h was not 
> accepted by the kernel OSS maintainers so the stock Linux version doesn't 
> have these definitions.
> 
> If you like to get OSS apps to go through this library API you can do the 
> following:
> 
> - Get the latest soundcard.h from our OSS package to be included in the 
> stock kernel.
> - Do the same for libOSSlib (sources shipped with OSS).
> - Tell all OSS developers to change all OSS system calls to use their 
> osslib_ counterparts. And to recompile against the latest soundcard.h
> with -DOSSLIB. Make sure all distributions have done the changes before 
> that.
> 
> Then you can include a libOSSlib.o library in ALSA with all the OSS 
> emulation stuf inside.

You should do the clear statement that the direct using of syscalls is not 
recommented for application developers. Unfortunately at this time, I 
admit, it would be very difficult to change the existing applications.

I can only suggest to OSS including the commercial version:

1) create a osslib package under GPL and probably also under BSD licence
2) notify developers in your documentation that every syscall has own
   function in osslib and that using syscalls directly is not recommended

In this way, your library will go to all Linux distributions and OSS app 
developers will have quite confirmed the right direction from you.

						Jaroslav

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Tue, 10 Jan 2006, Hannu Savolainen wrote:

> On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
> 
> > > 
> > > Then you can include a libOSSlib.o library in ALSA with all the OSS 
> > > emulation stuf inside.
> > 
> > You should do the clear statement that the direct using of syscalls is not 
> > recommented for application developers. Unfortunately at this time, I 
> > admit, it would be very difficult to change the existing applications.

> Sorry. That breaks backward compatibility with systems that don't have 
> libOSSlib (all current and past Linux distros, all BSD variants, 
> everything but systems with our official OSS package installed). Such 
> statement can be added in 2010 but provided that all Linux distros and 
> other environments having OSS compatible implementations add the osslib_* 
> routines within this year.

I meant that you can originate to move the OSS entry point to somewhere 
else (library) and try to persuade developers to use library than direct 
calls.

Of course, we cannot change current applications, but we can start the 
movement now. I just ask you to do it now. Nothing else. It will be a slow 
process but it should be started now.

Also, I don't think that it will break something. The application 
developers can use your code in their applications directly when the 
distribution does not have the OSS access library package.

Note that your words clearly states your attitude to change something.

						Jaroslav

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

Re: [Alsa-devel] Re: [OT] ALSA userspace API complexity

[Adam Tlałka]

Dnia 10-01-2006 o 15:17:21 Jaroslav Kysela <perex@suse.cz> napisał:

> On Tue, 10 Jan 2006, Hannu Savolainen wrote:
>
>> On Tue, 10 Jan 2006, Jaroslav Kysela wrote:
>>
>> > >
>> > > Then you can include a libOSSlib.o library in ALSA with all the OSS
>> > > emulation stuf inside.
>> >
>> > You should do the clear statement that the direct using of syscalls  
>> is not
>> > recommented for application developers. Unfortunately at this time, I
>> > admit, it would be very difficult to change the existing applications.
>
>> Sorry. That breaks backward compatibility with systems that don't have
>> libOSSlib (all current and past Linux distros, all BSD variants,
>> everything but systems with our official OSS package installed). Such
>> statement can be added in 2010 but provided that all Linux distros and
>> other environments having OSS compatible implementations add the  
>> osslib_*
>> routines within this year.
>
> I meant that you can originate to move the OSS entry point to somewhere
> else (library) and try to persuade developers to use library than direct
> calls.
>
> Of course, we cannot change current applications, but we can start the
> movement now. I just ask you to do it now. Nothing else. It will be a  
> slow
> process but it should be started now.
>
> Also, I don't think that it will break something. The application
> developers can use your code in their applications directly when the
> distribution does not have the OSS access library package.
  ger atlka@sunrise.pg.gda.pl

Doing every call through some lib even if it's only a wrapper leading
to kernel syscall doesn't look very interesting.
Some people need statically lined apps and minimum usable distro without
bloated libs. What about Unix device abstraction?
Are we going the current Windows way?

Anyway Windows is stearing to the microkernel approach (approaching Vista)
and it looks that we are going to the current Windows model while MS  
developers
are going far away. Hurd looks nice but it is not good enough now.
But the idea is good and needs more people to improve it.

So we could have Unix device approach with drivers running as separate  
processes
not in kernel space. With proper kernel scheduling and being non-swappable
we could get good security, stability and additionally enough simple
 from app point of view approach. Going through libs we are going through
all the LD_PRELOAD and LD_LIBRARY_PATH and linker security hell.

Kernel approach looks good enough for me now. But it is not so secure of  
course.
So we need some process->kernel-device->driver RT/non-swappable/correctly
scheduled process IPC so we can do it the other way. IMHO that's the future
if we don't want drivers in the kernel.

Best regards
--
Adam Tlałka      mailto:atlka@pg.gda.pl    ^v^ ^v^ ^v^
System  & Network Administration Group           ~~~~~~
Computer Center,  Gdańsk University of Technology, Poland
PGP public key:   finger atlka@sunrise.pg.gda.pl

Re: [OT] ALSA userspace API complexity

[Lee Revell]

On Thu, 2006-01-05 at 16:07 +0100, Tomasz Kłoczko wrote:
> - KNOWN FACT is OSS provides simpler API for user space for handle
>    usual cases.
>    Why Linux can't provide only OSS API abstraction for user space
>    application ? And/or why ALSA developers want to replace this by
>    mostly bloated and pourly documented ALSA user space API ?
> 

Please, stop with the documentation thing.  ALSA is perfectly well
documented.  I guess the problem is that you googled "ALSA
documentation" and this page didn't come up as the first hit (or even on
the first page):

http://www.alsa-project.org/alsa-doc/alsa-lib/index.html

This is a Google bug.  I suspect that the copius inter-document links
that Doxygen creates causes Google to think someone is trying to spam it
and penalizes the result.

Lee

Re: [OT] ALSA userspace API complexity

[Joern Nettingsmeier]

Tomasz Kłoczko wrote:
> List all neccessary feactures and abstract them. Below this layer you 
> can plug to this all device drivers. Where is the problem ?

users want to use all the bells and whistles that modern sound hardware 
has to offer. so "necessary features" roughly equals the union of all 
the "cool ideas of the week" of all soundcard vendors.

please have a look at, say, the rme hammerfall cards, compare them with 
ye olde sblive, then take a look at usb audio devices and for dessert, 
take a peek into current firewire hardware.

then push up your sleeves, design a small and elegant little abstraction 
mechanism that is maximally effective in all circumstances and makes all 
hardware features usable, wrap it up nicely and submit it to linus.

i look forward to hearing back from you, in, oh, 2015 or so?

jaroslav, takashi and the other alsa developers have been toiling with 
this for years, and i hate to see them having to take shit from people 
who don't do anything more with their sound hardware than listen to mp3s 
in stereo and can't imagine anything else.

granted, there is always room for improvement. the alsa guys are very 
receptive towards constructive criticism, when it is backed with a 
little insight. many linux audio developers have criticised the API for 
the high initial barrier, and ALSA certainly does not score that high in 
the "making simple things simple" department. but it does make 
*complicated things possible*, and all those rants of "gimme back me 
oss" usually ignore this.

modem dialup users know better than to chime in to networking core 
discussions and complain they don't need all that complexity. why do 
professional audio users always have to put up with people who only 
listen to mp3s whining about a complicate API?

i'll always grant you far better taste and insight into kernel matters 
than i will ever have, but hey: the library is in userspace. it does not 
clutter the kernel. so rrreeelaax!


-- 
jörn nettingsmeier

home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621

if you are a free (as in "free speech") software developer
and you happen to be travelling near my home, drop me a line
and come round for a free (as in "free beer") beer. :-D

Re: [OT] ALSA userspace API complexity

[Tomasz Kłoczko]

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

On Thu, 5 Jan 2006, Joern Nettingsmeier wrote:
[..]
> i look forward to hearing back from you, in, oh, 2015 or so?

Now we have 2006. Four years ALSA is in kernel tree.
2015 - 2006 = 9
4 < 9

Four years ago noone predisct some "temporary sound devices" like BT 
headests in ALSA architecture (bt-sco was developed in 2002 and still 
isn't merged in ALSA tree .. probably because module in current form can't 
provide simple usage like "just plug and play").
This is not matter of any kind prediction because on market four 
years ago was avalaible some "temporary sound devices". BT headsets 
are real and still IIRC there is no way in current ALSA architecture point 
where and how this must plugged.
Why ? Because most of soud stream routing are performed in user space 
library abstraction. For handle this in current ALSA model you must 
prepare EACH application for reciveing signals about for examaple 
changing default soud device (for perform close old and open new). In ALSA 
there is no layer where this kind of redirections can be managed outside 
ALL applications in common and easy way for non-root users

Q: why Linux can't behive as it will have allways soud device with dummy 
device plugged to /dev/null (if only soudcode is loaded) if there is no 
soud hardware in system ? Look .. if you have loaded event module you have 
virtual kbd and mouse .. but real kbd/mouse can be used only afrer load 
keyboard/mouse modules.

Instead try to manage any kind of (even future) devices it will be good if 
ALSA will be ready for manage only current "sound model devices" (like 
mono, stereo, 5.1, 7.1 with simple way for extending set of this profiles) 
but with *moved all sound routing* to kernel space with well defined 
ioctl() or netlink (like in ipfilter) API for manage all configuration 
details (for allow prepare for example cute GUI aplication for manage all 
this for joe users). In this way also will be possible prepare some kernel
level interface for plugging additional modules (or loading external DSO 
modules like in ipfilter for interract with with hardware in any other
way. Apply ipfilter way to soud subsystem can be also used for plugging
filters ..

So .. stop talking about future and start about preset problems. ALSA have 
many problems with current devices (on soud subsystem *architecture level*)

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

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Thu, Jan 05, 2006 at 11:39:43PM +0100, Joern Nettingsmeier wrote:
> modem dialup users know better than to chime in to networking core 
> discussions and complain they don't need all that complexity. why do 
> professional audio users always have to put up with people who only 
> listen to mp3s whining about a complicate API?

Funnily enough, people who added SIGIO and epoll did not remove
select nor limited its capabilities.

The ALSA api has issues, whether you want to acknowledge them or not.
The OSS api has issues too, of course.  But it is there to stay, and
it has advantages in some situations, like when simplicity or not
depending on a shared library matters.  Ignoring it is stupid.  Doing
your best to cripple it is stupid.  The OSS api is an entrypoint in
the sound system as valid and important than others.

  OG.

Re: [OT] ALSA userspace API complexity

[Joern Nettingsmeier]

Olivier Galibert wrote:
> On Thu, Jan 05, 2006 at 11:39:43PM +0100, Joern Nettingsmeier wrote:
>> modem dialup users know better than to chime in to networking core 
>> discussions and complain they don't need all that complexity. why do 
>> professional audio users always have to put up with people who only 
>> listen to mp3s whining about a complicate API?
> 
> Funnily enough, people who added SIGIO and epoll did not remove
> select nor limited its capabilities.
> 
> The ALSA api has issues, whether you want to acknowledge them or not.
> The OSS api has issues too, of course.  But it is there to stay, and
> it has advantages in some situations, like when simplicity or not
> depending on a shared library matters.  Ignoring it is stupid.  Doing
> your best to cripple it is stupid.  The OSS api is an entrypoint in
> the sound system as valid and important than others.

agreed. nobody doubts this. a long time ago, this thread was about 
removing obsolete *drivers*. that is orthogonal to the api issue.

then people starting whining about bugs in the alsa oss layer, while 
being too lazy to file bug reports. nobody wants to "cripple" this api, 
saying so is just stupid FUD and rather offensive.

then somebody started an api discussion, where *oss* was represented 
quite fairly. it does have its nice sides. but to me it looks like most 
of the people bashing *alsa* for its complexity have not understood the 
problems it tries to (and does) solve.

shuffle 16 tracks of 24bit 48k audio in and out of the machine at a 
latency where a professional drummer will not complain, with routing 
options adequate for professional work, and then let's see how simple 
your API is.
for those audio-challenged people out there: recall the tcp-offloading 
discussions in the networking layer. nobody wants to do it, and they can 
get away with it, because it does not buy you much and fucks up the api 
big time.
in audioland, you have all kinds of funky shit going on in the hardware, 
and you can't say, no we don't support that, to inelegant, because then 
your stuff just can't compete.
hardware peculiarities cannot be abstracted away without sacrificing 
efficiency, and this makes for a complicated api.

instead people keep whining and talk about headsets not working. sheesh.
tomasz, your impressive arithmetic with years is quite correct, but your 
data is wrong. there have been years of development before alsa ever 
came near the kernel. stop bitching, read up on some stuff (for 
instance, find out about how different the gizmos i mentioned actually 
are), get your facts straight. if by then you should happen to develop a 
real interest in audio matters, the linux-audio-* lists welcome your 
questions and contributions.


-- 
jörn nettingsmeier

home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621

if you are a free (as in "free speech") software developer
and you happen to be travelling near my home, drop me a line
and come round for a free (as in "free beer") beer. :-D

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Fri, Jan 06, 2006 at 01:22:48AM +0100, Joern Nettingsmeier wrote:
> agreed. nobody doubts this. a long time ago, this thread was about 
> removing obsolete *drivers*. that is orthogonal to the api issue.

Yeah, and there was way less flamage then too :-)


> then people starting whining about bugs in the alsa oss layer, while 
> being too lazy to file bug reports. nobody wants to "cripple" this api, 
> saying so is just stupid FUD and rather offensive.

You know, having the problem of device blocking between the oss api
kernel support (emulation is not a very good term in that context) and
the alsa api kernel support being meet by -EWONTFIX and "Don't use
OSS, use Alsa-lib, it's infinitely better" is somewhat offensive too.
You want me to file a bug report on that to see how far it's going to
go?


> then somebody started an api discussion, where *oss* was represented 
> quite fairly. it does have its nice sides. but to me it looks like most 
> of the people bashing *alsa* for its complexity have not understood the 
> problems it tries to (and does) solve.

The "the documentation is perfect, you just not have read it"
fanboyism after having needed 2 or 3 days using that same
documentation to write a simple dynamic sound streaming in an
application I'm doing grates a little.  Also, I notice that all my
comments about the numerous problms as seen in the windows world that
come with having a kernel api defined as a shared library have gone
beautifully ignored.


> shuffle 16 tracks of 24bit 48k audio in and out of the machine at a 
> latency where a professional drummer will not complain, with routing 
> options adequate for professional work, and then let's see how simple 
> your API is.

I've done 64-channel microphone array capture, source tracking,
beamforming, speaker id and feeding an ASR over a network of computers
with a rather low latency.  I wrote or participated in the complete
chain, from programming the capture dsp in assembly and debugging it
with a 'scope, writing the linux driver to get the data on the pci, or
writing the data transmission infrastructure.  And the API is still
simple enough that it is becoming a de facto standard for smart space
applications and the comments are of the order of "there still are
some bugs (indeed there is, no doubts about that), but it allowed us
to having things working rather easily and fast".

Is that enough audio-unchallenged for you?  Oh, it does video too.


> in audioland, you have all kinds of funky shit going on in the hardware, 
> and you can't say, no we don't support that, to inelegant, because then 
> your stuff just can't compete.

That's why you want a clean core and an extension mechanism, and add
the extensions in the core once they're general enough.  See OpenGL.


> hardware peculiarities cannot be abstracted away without sacrificing 
> efficiency, and this makes for a complicated api.

No, it doesn't.  Again, see OpenGL.  Audio hardware variability is
laughable compared to video hardware variability nowadays.

But you need to designed your API starting from what people want to
do, not from what the hardware does in detail.

  OG.

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Fri, 6 Jan 2006, Joern Nettingsmeier wrote:

> shuffle 16 tracks of 24bit 48k audio in and out of the machine at a latency
> where a professional drummer will not complain, with routing options adequate
> for professional work, and then let's see how simple your API is.
This is nonsense. This is something where the API design cannot make any 
difference.

To get (say) 10 ms latencies you have to tell the sound subsystem 
to allocate to buffer that is smaller than 10 ms. This in turn means that 
the application must be able to run it's processing loop within less than 10 
ms with 100.000...0% confidence. This is true regardless of how advanced 
or primitive the audio subsystem (API) is.

What happens if some system load peak delays the application by 20 ms? The 
result is complete failure. What is the ALSA (API) feature OSS doesn't 
have that makes it able to predict what kind of output the application 
should have fed to the device during the (about) 20 ms period of silence? 

The fact is that there is nothing the audio subsystem can do to recover 
the situation. For this very simple reason the OSS API lacks everything 
that would be necessary to cope with this kind of problems.

After all the lowest possible audio latency depends on the level of real 
time response capabilities of the underlaying OS/hardware/application 
environment. If the app doesn't get the CPU right in time it will fail 
(believe or not).

If the system can fullfill the response time requirements then any sound 
subsystem will work equally well (unless they are seriously broken).

The sound subsystem implementations may have performance 
differences of few usecs. However they don't make one better than another 
in cases when the peak latencies are in millisecond range. In addition 
same devices have FIFO/bus delays of up to few msec byt even then 
advances in the audio subsystem/API design cannot help at all.

Best regards,

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

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Fri, 6 Jan 2006, Hannu Savolainen wrote:

> What happens if some system load peak delays the application by 20 ms? The 
> result is complete failure. What is the ALSA (API) feature OSS doesn't 
> have that makes it able to predict what kind of output the application 
> should have fed to the device during the (about) 20 ms period of silence? 
> 
> The fact is that there is nothing the audio subsystem can do to recover 
> the situation. For this very simple reason the OSS API lacks everything 
> that would be necessary to cope with this kind of problems.

Applications should be notified that something is broken. If you have
a professional environment, you really need to know, if the output 
survived all scheduling peaks and the audio data are delivered from/to
I/O in time.

Also, in the standard consumer environment is good to know that the system
have some trouble to deliver data in time (motivating developers of core 
Linux kernel code or subsystems, or motivating app programers to set the 
correct scheduling parameters) to fix remaining problems.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Tue, 10 Jan 2006, Jaroslav Kysela wrote:

> On Fri, 6 Jan 2006, Hannu Savolainen wrote:
> 
> > The fact is that there is nothing the audio subsystem can do to recover 
> > the situation. For this very simple reason the OSS API lacks everything 
> > that would be necessary to cope with this kind of problems.
> 
> Applications should be notified that something is broken. If you have
> a professional environment, you really need to know, if the output 
> survived all scheduling peaks and the audio data are delivered from/to
> I/O in time.
This is exactly how OSS API works. The application can check if there were 
any errors so far. It can do it after finishing the playback or whenever 
it likes. It can then show a dialog box saying that playback/recording 
was not 100% error free. Alternatively it can show error counters on the 
status line. Or most applications just don't care.
 
Best regards,

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

Re: [OT] ALSA userspace API complexity

[Marcin Dalecki]

On 2006-01-05, at 23:39, Joern Nettingsmeier wrote:

> Tomasz Kłoczko wrote:
>> List all neccessary feactures and abstract them. Below this layer  
>> you can plug to this all device drivers. Where is the problem ?
>
> users want to use all the bells and whistles that modern sound  
> hardware has to offer. so "necessary features" roughly equals the  
> union of all the "cool ideas of the week" of all soundcard vendors.

First and fore most users want simple things like for example playing  
an mp3 file to just work.
Your concept that very many of them are interested in the high end  
"features" of hardware you assume to be modern is wrong. Did you ever  
notice that sound cards got just reduced to a simple AD/DA converter  
combination? Modern hardware is frequently actually MUCH MUCH simpler  
then old one used to be in this area.

> please have a look at, say, the rme hammerfall cards, compare them  
> with ye olde sblive, then take a look at usb audio devices and for  
> dessert, take a peek into current firewire hardware.

The existence of /dev/sound doesn't prohibit the existence of
/dev/bells_and_wistles (without any chance to work with anything else  
then the vendors specific software).
That was precisely the situation with my sam9700 card....

> then push up your sleeves, design a small and elegant little  
> abstraction mechanism that is maximally effective in all  
> circumstances and makes all hardware features usable, wrap it up  
> nicely and submit it to linus.
>
> i look forward to hearing back from you, in, oh, 2015 or so?

Your assumption about "all circumstances" is misguided. There is no  
requirement for one size fits all here.
Look most people drive cars and not space shuttles.


> jaroslav, takashi and the other alsa developers have been toiling  
> with this for years, and i hate to see them having to take shit  
> from people who don't do anything more with their sound hardware  
> than listen to mp3s in stereo and can't imagine anything else.

If hearing just the mp3 would just simply work with the alsa drivers  
without getting in to too much hassle
with AC97 sound cards, which usually don't even include hardware  
based volume controls nowadays, I'm pretty sure they wouldn't have to  
"take this shit". And you should remember the bold announcements they  
did make in first place.

> granted, there is always room for improvement. the alsa guys are  
> very receptive towards constructive criticism, when it is backed  
> with a little insight. many linux audio developers have criticised  
> the API for the high initial barrier, and ALSA certainly does not  
> score that high in the "making simple things simple" department.  
> but it does make *complicated things possible*, and all those rants  
> of "gimme back me oss" usually ignore this.
>
> modem dialup users know better than to chime in to networking core  
> discussions and complain they don't need all that complexity. why  
> do professional audio users always have to put up with people who  
> only listen to mp3s whining about a complicate API?
> i'll always grant you far better taste and insight into kernel  
> matters than i will ever have, but hey: the library is in  
> userspace. it does not clutter the kernel. so rrreeelaax!

It clutters the application programming part very successfully.

BTW. Designing a sound API toward DMA, like ALSA does, is just plain  
well beyond any hope...

Re: [OT] ALSA userspace API complexity

[Leonard Milcin Jr.]

Tomasz Kłoczko wrote in his signature:
 > -----------------------------------------------------------
 > *Ludzie nie mają problemów, tylko sobie sami je stwarzają*
 > -----------------------------------------------------------
 > Allow me translate sentence from my signature to english
 > "People do not have problems they create them themselves"
 > and ALSA case matches in 100%.

Look, kloczek, how less problems we cold have by banishing
all the technology and going back to stone age?

The complexity is sometimes unavoidable if one tries to
please as many as possible. But why not userspace library
that simplifies access to ALSA for those who don't need
all the ,,complexity''? That pleases both -- those who
need feauters, and those who only need to pass something
to speakers. Maybe there are cards that work with OSS and
not with ALSA, and that may be the reason to keep it just
for some time. But in the long run I don't think there is
a need to have two sound systems in kernel just because
one is complicated and other lacks some features.

Leonard

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

[Joern Nettingsmeier]

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

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

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

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

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

get real.


-- 
jörn nettingsmeier

home://germany/45128 essen/lortzingstr. 11/
http://spunk.dnsalias.org
phone://+49/201/491621

if you are a free (as in "free speech") software developer
and you happen to be travelling near my home, drop me a line
and come round for a free (as in "free beer") beer. :-D

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

[Andi Kleen]

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

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

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

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

-Andi

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

[Jaroslav Kysela]

On Wed, 4 Jan 2006, Andi Kleen wrote:

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

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

						Jaroslav

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

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

[Alistair John Strachan]

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

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

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

-- 
Cheers,
Alistair.

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

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

[Takashi Iwai]

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

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


Takashi

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

[Lee Revell]

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

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

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

Lee

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

[Lee Revell]

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

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

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

Lee

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

[Thomas Sailer]

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

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

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

Tom

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

[Jaroslav Kysela]

On Tue, 3 Jan 2006, Thomas Sailer wrote:

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

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

						Jaroslav

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

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

[Thomas Sailer]

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

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

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

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

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

Tom

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

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

[Jaroslav Kysela]

On Tue, 3 Jan 2006, Thomas Sailer wrote:

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

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

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

Full documentation is available at:

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

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

						Jaroslav

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

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

[Thomas Sailer]

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

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

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

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

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

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

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

Tom

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

[James Courtier-Dutton]

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

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

The zero switches off the alsa-lib resampler.

James

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

[Takashi Iwai]

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

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


Takashi

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

[Tomasz Torcz]

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

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

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

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


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

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

[Takashi Iwai]

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

Why do we need to keep the compatibility with NetBSD?


Takashi

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

[Jesper Juhl]

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

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

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

[Adrian Bunk]

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

The OSS compatibility in ALSA is only a legacy API for applications not 
yet converted to use the ALSA API.

> Jesper Juhl

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: [2.6 patch] schedule obsolete OSS drivers for removal

[Jesper Juhl]

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

Still would be nice if users of ALSA who have the OSS backwards compat
enabled would thus also get transparent software mixing for all apps
using the OSS API.
not crucial, that's not what I'm saying, just nice if it would be possible.


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

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

[Takashi Iwai]

At Tue, 3 Jan 2006 23:11:47 +0100,
Jesper Juhl wrote:
> 
> On 1/3/06, Adrian Bunk <bunk@stusta.de> wrote:
> > On Tue, Jan 03, 2006 at 09:56:20PM +0100, Jesper Juhl wrote:
> > > On 1/3/06, Takashi Iwai <tiwai@suse.de> wrote:
> > > > At Tue, 3 Jan 2006 21:37:32 +0100,
> > > > Tomasz Torcz wrote:
> > > > >
> > > > > On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> > > > > > At Tue, 3 Jan 2006 18:03:16 +0100,
> > > > > > Olivier Galibert wrote:
> > > > > > >
> > > > > > > > This is exactly why the OSS emulation option in ALSA is really a last resort
> > > > > > > > and should not be an excuse for people to ignore implementing ALSA support
> > > > > > > > directly. More so, it is very good justification for ditching "everything
> > > > > > > > OSS" as soon as possible, at least in new software.
> > > > > > >
> > > > > > > Actually the crappy state of OSS emulation is a good reason to ditch
> > > > > > > ALSA in its current implementation.  As Linus reminded not so long
> > > > > > > ago, backwards compatibility is extremely important.
> > > > > >
> > > > > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > > > > software mixing in the kernel, too :)
> > > > >
> > > > >  OSS will support software mixing. In kernel. On NetBSD.
> > > > > http://kerneltrap.org/node/4388
> > > >
> > > > Why do we need to keep the compatibility with NetBSD?
> > > >
> > > Software mixing is a really nice feature for people with soundscards
> > > that can't do hardware mixing, so if the OSS compatibility could
> > > transparently do software mixing for apps using OSS api that would be
> > > a very nice extension for a lot of people - I'd say that if NetBSD do
> > > that they've got the right idea.
> >
> > The OSS compatibility in ALSA is only a legacy API for applications not
> > yet converted to use the ALSA API.
> >
> 
> Still would be nice if users of ALSA who have the OSS backwards compat
> enabled would thus also get transparent software mixing for all apps
> using the OSS API.
> not crucial, that's not what I'm saying, just nice if it would be possible.

Technicall it's trivial to implement the soft-mixing in the kernel.
The question is whether it's the right implementation.
We have a user-space softmix for ALSA, and aoss wrapper for OSS using
it.  (I know aoss still has some problems that should be fixed,
though.)


Anyway, the softmix problem has no relation with the deprecation of
OSS drivers in Linux kernel tree.  They don't do softmix.  So,
comparing with NetBSD or claiming the unimplemented feature is
irrelevant with $SUBJECT.


Takashi

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

[Jan Engelhardt]

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



Jan Engelhardt
-- 

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

[Marcin Dalecki]

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

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

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

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

[Jan Engelhardt]

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

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



Jan Engelhardt
-- 

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

[Marcin Dalecki]

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

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

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

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

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

[Lee Revell]

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

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

Lee

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

[Marcin Dalecki]

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

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

Yeah - for you maybe...

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

[Lee Revell]

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

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

Lee

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

[Marcin Dalecki]

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

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

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

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

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

[Lee Revell]

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

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

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

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

> Glaring problems on average commodity hardware one expect the  
> developers to take
> care of without any notice.
> 

HAHA, "average commodity hardware", that's a good one.  I think you
VASTLY underestimate the difficulty of maintaining good ALSA drivers.
There are hundreds of times more sound chipset/codec combinations than
there are ALSA developers.  This is not like network or disk controller
drivers where having the datasheet is the norm - in ALSA reverse
engineered drivers are the norm and there can be dozens of variations on
a single chipset all of which the driver must handle.  It would be one
thing if the vendors helped but they don't - sound is considered desktop
stuff and they don't consider the Linux desktop market worth their time.

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

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

Lee 

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

[Marcin Dalecki]

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

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

...

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

You are aware of how self contradicting this sounds?!

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

[Lee Revell]

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

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

Lee

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

[Lee Revell]

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

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

Lee

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

[Marcin Dalecki]

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

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

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

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

[Lee Revell]

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

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

Lee

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

[Marcin Dalecki]

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

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

It's not about helping ALSA here it's about not throwing out the window
a system which has the advantage of actually working.

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

[Lee Revell]

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

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

Lee

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

[Jesper Juhl]

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

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

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

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

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

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

[Marcin Dalecki]

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

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

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

So please just keep your superstitions for yourself.

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

[Jesper Juhl]

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

welcome to my killfile


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

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

[Hannu Savolainen]

On Fri, 6 Jan 2006, Marcin Dalecki wrote:

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

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

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

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

Best regards,

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

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

[James Courtier-Dutton]

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

Hannu,

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

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

James

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

[Hannu Savolainen]

On Fri, 6 Jan 2006, James Courtier-Dutton wrote:
> Even you admit that the OSS drivers in the kernel mainline are "really
> obsolete", so you must agree with this thread that we should remove them.
I completely agree. As I said I would like to see the old OSS code to be 
removed from the kernel soon.
 
> Only if your binary blobs are released as GPL so that they can be included in
> mainline can it really be any use to discuss them.
We are planning to release OSS under some open source license (not GPL).
However it will be released and built outside the Linux kernel source tree 
(mostly because the same code has to work with several other operating 
system).

Best regards,

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

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

[Gabor Gombas]

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

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

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

Gabor

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

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

[Hannu Savolainen]

On Fri, 6 Jan 2006, Gabor Gombas wrote:

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

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

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

Best regards,

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

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

[Takashi Iwai]

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

Agreed, it's a good point.

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

> Both ways have their good and bad sides. During past years the ALSA 
> advocates have been dictating that the ALSA approach is the only available 
> way to go (all resistance is futile).

Heh, it's natural that developers think their own things work better
:)

> But after all what is the authority 
> who makes the final decision? Is it the ALSA team (who would like to think 
> in this way)? Or do the Linux/Unix users and audio application developers 
> have any word to say?

I, at least, have never thought that the OSS _API_ would die.  Since
they have existed, they will exist.  The question on LKML should be
rather the implementation (for apps it doesn't matter how the sound
system is implemented as long as it keeps API).

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


Takashi

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

[Marcin Dalecki]

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

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

A whole complex cross correlation containing a butterfly FFT core for  
example doesn't take
much more then just about 500 lines of C code. And it's FAST.  
Basically hitting DRAM speed.
Thus technically it's nowadays complete utter nonsense to offload it  
to some additional hardware or to
copy the data for processing in to user space and back.

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

[Hannu Savolainen]

On Sat, 7 Jan 2006, Takashi Iwai wrote:

> > There are two very opposite approaches to do a sound subsystem. The ALSA 
> > way is to expose every single detail of the hardware to the applications 
> > and to allow (or force) application developers to deal with them. The OSS 
> > approach is to provide maximum device abstraction in the API level (by 
> > isolating the apps from the hardware as much as practically possible).
> 
> Agreed, it's a good point.
> 
> Note that for long time, I've commented that I myself do _not_
> recommend to use ALSA API directly with apps.  Rather I've recommended
> to use other portable libraries with ALSA/other backends.  Writing an
> app with alsa-lib is just like to write a graphical program with X11
> lowlevel library without any toolkits...
Takashi, I knew you are smart enough to realize this. What is needed at 
the kernel level is a driver API that is strong enough to provide all the 
functionality needed to implement good user land libraries (including 
alsa-lib). At the same time the kernel API itself should be  suitable to 
be used in mainline applications. At this moment Jack is already used by 
most high end Linux sound apps which is good approach.
 
> > Both ways have their good and bad sides. During past years the ALSA 
> > advocates have been dictating that the ALSA approach is the only available 
> > way to go (all resistance is futile).
> 
> Heh, it's natural that developers think their own things work better
> :)
This is natural and acceptable. What is not acceptable is that 1000's of 
existing applications are forced to be converted to use some new API 
because the original one is seen as deprecated by the developers of the 
new one. Or to be forced to access the devices through some 
LD_PRELOAD hack and redundant layers of library code that provide very 
little if any added value.

> > But after all what is the authority 
> > who makes the final decision? Is it the ALSA team (who would like to think 
> > in this way)? Or do the Linux/Unix users and audio application developers 
> > have any word to say?
> 
> I, at least, have never thought that the OSS _API_ would die.  Since
> they have existed, they will exist.  The question on LKML should be
> rather the implementation (for apps it doesn't matter how the sound
> system is implemented as long as it keeps API).
This is OK as far as long as the approach taken doesn't make it impossible 
to develop the OSS API as a pure kernel API as it has been designed to be. 
Development of OSS is still continuing as a stand alone project. In the 
long term it will be open sourced and possibly given to some Xorg like 
consortium. How soon (if ever) this is going to happen is mostly a funding 
issue.

The ALSA kernel API is not documented and it's not intended to be 
used directly by the apps. If OSS is moved behind some user land wrappers 
then there is no kernel level API available for (embedded) software 
developers. Also it's very hard to believe that Linux maintainers love to 
have a kernel API that is only known to bunch of current ALSA developers 
and requires use of given library implementation (directly or indirectly).

A challenge will be finding a way how both OSS and ALSA APIs can coexist 
without disturbing each other. There are many ways (better than 
artifically forcing OSS API to be emulated in user land). I'm confident 
that something can be worked out.

> In the implementation of OSS API, there is a clear bottleneck: you
> have to implement everthing in the kernel level because of its
> definition.
I very well know this limitation. I have never claimed that everything 
can or should be done in the kernel. There is lot of stuff that can be 
done better in user land library/app code. OSS itself doesn't contain any 
library code because we think there are other developers that can do 
libraries better than we.

> Remember that the original thread started from the
> reduction of the kernel codes.  Putting more stuff which could be done
> better in user-space is a major drawback, IMO.
Completely agree. There are many things such as effect plugins that cannot 
be done in kernel space (or technically they can be done but they should 
not be done). 

However there are things like endianess conversions that can be done 
equally well in kernel space (while in an ideal world they belong to 
userland). Such simple operations don't take longer than nanoseconds to 
execute and they make implementing the user land code simplier. 

And surprise surprise there are things that can be done much better in 
kernel space than in userland. If some processing is done in the interrupt 
handler there are no scheduling latencies involved. Interrupt handlers 
fire in microseconds so the device can be programmed to interrupt after 
each sample. This in totally cannibalises the system by raising interrupt 
overhead significantly (up to 5-20%). It is known that  kernel developers 
don't like this kind of core porno at all. However if zero latency audio 
processing is the primary purpose of the system then this is the way to go.

Avoiding kernel code that can be handled in userland is the rule. But as 
you may see even this rule has some exceptions.

Best regards,

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

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

[Diego Calleja]

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

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


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

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

[Olivier Galibert]

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

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

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

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

  OG.

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

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

[Jaroslav Kysela]

On Fri, 6 Jan 2006, Olivier Galibert wrote:

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

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

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

user space <-> kernel

While your daemon requires:

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

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

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

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

It's also not very true. You can create your own ALSA library, but this 
library will not be supported with our team. The ALSA from 1.0 version is 
binary compatible (even 0.9.0rc4+ linked applications should work) and old 
ioctls are emulated.

> with no security audit that I could find with google.  A library for
> which people do not seem to care about compatibility with previous or
> future kernel versions, which means it _has_ to be shared.  And shared
> libraries are just unacceptable in some contexts, like distributing
> binaries outside of a specific linux distribution[1].

I'd like to point that this code runs with standard user priviledges. I 
think that the security things are and should be in a different place (in 
the kernel). If IPC is broken, other applications (not only using sound) 
might be broken. If administrator (root) creates wrong configuration files 
for alsa-lib - we cannot do anything. It's a human error. The same problem 
is if you have this code in kernel. It can be bad (even more than in the 
user space - you can shutdown whole system) too.

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

Please, see your words. You're simply anarchistic. You replaced 
flexibility of dynamic library with a possibility to have static binary.

ALSA library can be also compiled as static library, so it's not a 
problem. The ALSA kernel API is stable. Also, we use symbol versions for 
all exported functions, so all old binaries linked with the dynamic alsa 
library will work. Of course, the drivers might change some universal 
control names, then different configuration files for alsa-lib should be 
used, but it's a different point and we're working also on this 
compatibility to avoid these problems in future. But the standard stereo 
sound work all the time (I speak about 5.1, S/PDIF devices).

Also note, that if OSS had the API in userspace from the first days,
the emulation or redirection of this API to another API or user space 
drivers wouldn't be so much complicated nowadays. Bummer.

						Jaroslav

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

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

[Marcin Dalecki]

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

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

So there you are - all over the pill - soft real time requirements.  
Actually not that soft at all.
It always surprises me how efficient and demanding the perceptive  
system of a hunter and
gatherer is, which only just recently got the sudden idea that it may  
be nice to spend
his time in front of an engine generating animated images.

>> At least OSS, with all its flaws, is a documented kernel interface.
>> You can static link a oss-using program, whether it uses it directly
>> or through interfaces like sdl-audio, and it will just work.
>
> Please, see your words. You're simply anarchistic. You replaced
> flexibility of dynamic library with a possibility to have static  
> binary.

> Also note, that if OSS had the API in userspace from the first days,
> the emulation or redirection of this API to another API or user space
> drivers wouldn't be so much complicated nowadays. Bummer.

You simply don't get it. On unix like systems the definitive  
interface level is not
a library. It's the system call. Libraries can be helpful as a means  
to make some common
actions a tad bit easier. However even so simple things like state- 
full behavior there
is a complete no go. Get over it. Libraries are just too affine to
compiler releases particular programming languages and many other  
side conditions.
Do your homework and take a serious look at other operating systems  
to see how "fine" the
APIs defined by DLLs (ups) are. As an exercise ask yourself why on  
earth it takes
usually about 2 or 4 times longer to write a windows driver.

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

[Olivier Galibert]

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

Dmix _is_ a context switch, you know?


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

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


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

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


> > ALSA does not have a documented kernel interface nor an optional
> > library but a mandatory library.  A highly complex, ipc-using library
> 
> It's also not very true. You can create your own ALSA library,

After reverse-engineering your kernel interface.  How convenient.


> but this library will not be supported with our team.

Of course.  You won't have to though, since you claim the API is
upwards compatible.


> The ALSA from 1.0 version is 
> binary compatible (even 0.9.0rc4+ linked applications should work) and old 
> ioctls are emulated.

Good.


> I'd like to point that this code runs with standard user priviledges. I 
> think that the security things are and should be in a different place (in 
> the kernel). If IPC is broken, other applications (not only using sound) 
> might be broken.

Every application that does inter-process communication has potential
protocol-level security issues.  Current ALSA creates two shared
memory zones and one semaphore with group write permissions.  In a
setup where a number of people are in the same group (student group
for instance), are you 100% positive that another user cannot take
control of the running application by writing the right values at the
right time in these zones?  Shared memory is the most dangerous
communication vector there is when the other application is
untrustable.


> > At least OSS, with all its flaws, is a documented kernel interface.
> > You can static link a oss-using program, whether it uses it directly
> > or through interfaces like sdl-audio, and it will just work.
> 
> Please, see your words. You're simply anarchistic. You replaced 
> flexibility of dynamic library with a possibility to have static binary.

I am indeed not really interested in reproducing the dll hell of
windows in linux.  I want simple but really efficient interfaces to
kernel services which then give the possibility to build special needs
libraries over it[1].  At that point you're designing an API for a
specific class of professional audio users and essentially telling all
the other users to bugger off.  Bad karma.


> ALSA library can be also compiled as static library, so it's not a 
> problem. The ALSA kernel API is stable.

Yeah, that's the second time you're saying that.  I'm sure Dave Jones
will be really happy to know that his impressions were mistaken and
his bugzilla was just having hallucinations:
  http://marc.theaimsgroup.com/?l=linux-kernel&m=113589615627420&w=2
  http://marc.theaimsgroup.com/?l=linux-kernel&m=113225994603627&w=2


> Also, we use symbol versions for 
> all exported functions, so all old binaries linked with the dynamic alsa 
> library will work.

Like all the programs I had which segfaulted after the alsa upgrade
that changed set_rate_near.  Beautiful versioning there guys.


> Of course, the drivers might change some universal 
> control names,

Yeah, also known as "the stick which broke jwz's back".


> Also note, that if OSS had the API in userspace from the first days,
> the emulation or redirection of this API to another API or user space 
> drivers wouldn't be so much complicated nowadays. Bummer.

It would be exactly as complicated because of the static link issue.

  OG.

[1] SDL, jack and slmodem are I think good examples

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

[Hannu Savolainen]

On Thu, 5 Jan 2006, Lee Revell wrote:

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

Best regards,

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

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

[Lee Revell]

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

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

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

Lee

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

[caszonyi]

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

On Thu, 5 Jan 2006, Lee Revell wrote:

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

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

So it seems that dmix is not working by default in kernel 2.6.15
Alsa userspace tools are version 1.0.8.

config and dmesg attached

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

--

"frate, trezeste-te, aici nu-i razboiul stelelor"
 				Radu R. pe offtopic at lug.ro

[-- Attachment #2: Type: TEXT/PLAIN, Size: 10049 bytes --]

Linux version 2.6.15 (root@grinch) (gcc version 3.3.4) #1 PREEMPT Tue Jan 3 23:29:37 EET 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
 BIOS-e820: 000000000fff0000 - 000000000fff3000 (ACPI NVS)
 BIOS-e820: 000000000fff3000 - 0000000010000000 (ACPI data)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65520
  DMA zone: 4096 pages, LIFO batch:0
  DMA32 zone: 0 pages, LIFO batch:0
  Normal zone: 61424 pages, LIFO batch:15
  HighMem zone: 0 pages, LIFO batch:0
DMI not present.
ACPI: RSDP (v000 VIA694                                ) @ 0x000f7060
ACPI: RSDT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x0fff3000
ACPI: FADT (v001 VIA694 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x0fff3040
ACPI: DSDT (v001 VIA694 AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000
ACPI: PM-Timer IO Port: 0x4008
Allocating PCI resources starting at 20000000 (gap: 10000000:efff0000)
Built 1 zonelists
Kernel command line: auto BOOT_IMAGE=k2615 ro root=302
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 700.394 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 132x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 254128k/262080k available (2857k kernel code, 7400k reserved, 1562k data, 168k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1401.22 BogoMIPS (lpj=700612)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0183f9ff c1c7f9ff 00000000 00000000 00000000 00000000 00000000
CPU: After vendor identify, caps: 0183f9ff c1c7f9ff 00000000 00000000 00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 64K (64 bytes/line)
CPU: After all inits, caps: 0183f9ff c1c7f9ff 00000000 00000020 00000000 00000000 00000000
mtrr: v2.0 (20020519)
CPU: AMD Duron(tm) Processor stepping 01
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0e00)
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: Using configuration type 1
ACPI: Subsystem revision 20050902
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Disabling VIA memory write queue (PCI ID 0305, rev 02): [55] 81 & 1f -> 01
PCI quirk: region 4000-40ff claimed by vt82c586 ACPI
PCI quirk: region 6000-607f claimed by vt82c686 HW-mon
PCI quirk: region 5000-500f claimed by vt82c686 SMB
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 1 3 4 5 6 7 10 11 12 14 15) *0, disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
PnPBIOS: Disabled by ACPI PNP
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
PCI: Bridge: 0000:00:01.0
  IO window: d000-dfff
  MEM window: dc000000-ddffffff
  PREFETCH window: d0000000-d7ffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
NTFS driver 2.1.25 [Flags: R/O].
JFS: nTxBlock = 1986, nTxLock = 15893
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Processor [CPU0] (supports 2 throttling states)
isapnp: Scanning for PnP cards...
isapnp: Card 'Crystal Codec'
isapnp: 1 Plug & Play card detected total
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected VIA Twister-K/KT133x/KM133 chipset
agpgart: AGP aperture is 64M @ 0xd8000000
[drm] Initialized drm 1.0.0 20040925
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:01:00.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
[drm] Initialized radeon 1.19.0 20050911 on minor 0: 
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
00:07: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
parport_pc: VIA 686A/8231 detected
parport_pc: probing current configuration
parport_pc: Current parallel port base: 0x3BC
parport0: PC-style at 0x3bc (0x7bc), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
lp0: using parport0 (interrupt-driven).
parport_pc: VIA parallel port: io=0x3BC, irq=7
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
loop: loaded (max 8 devices)
PPP generic driver version 2.4.2
NET: Registered protocol family 24
8139too Fast Ethernet driver 0.9.27
ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
eth0: RealTek RTL8139 at 0xd0802000, 00:40:f4:72:99:b3, IRQ 11
eth0:  Identified 8139 chip type 'RTL-8100B/8139D'
Linux video capture interface: v1.00
bttv: driver version 0.9.16 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
bttv0: Bt878 (rev 2) at 0000:00:0a.0, irq: 10, latency: 32, mmio: 0xde000000
bttv0: detected: AVermedia TVCapture 98 [card=13], PCI subsystem ID is 1461:0002
bttv0: using: AVerMedia TVCapture 98 [card=13,autodetected]
bttv0: gpio: en=00000000, out=00000000 in=000477c3 [init]
bttv0: Hauppauge/Voodoo msp34xx: reset line init [11]
bttv0: Avermedia eeprom[0x4011]: tuner=5 radio:no remote control:yes
bttv0: using tuner=5
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: PLL: 28636363 => 35468950 .. ok
bttv0: add subdevice "remote0"
input: bttv IR (card=13) as /class/input/input0
tuner 0-0061: chip found @ 0xc2 (bt878 #0 [sw])
tuner 0-0061: type set to 5 (Philips PAL_BG (FI1216 and compatibles))
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:07.1
PCI: Via IRQ fixup for 0000:00:07.1, from 255 to 0
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci0000:00:07.1
    ide0: BM-DMA at 0xe000-0xe007, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xe008-0xe00f, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: WDC WD2000JB-00GVC0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: _NEC DVD_RW ND-3550A, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 1024KiB
hda: 390721968 sectors (200049 MB) w/8192KiB Cache, CHS=24321/255/63, UDMA(66)
hda: cache flushes supported
 hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 >
hdc: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
mice: PS/2 mouse device common for all mice
input: PC Speaker as /class/input/input1
i2c /dev entries driver
input: AT Translated Set 2 keyboard as /class/input/input2
Advanced Linux Sound Architecture Driver Version 1.0.10rc3 (Mon Nov 07 13:30:21 2005 UTC).
pnp: Device 01:01.00 activated.
pnp: Device 01:01.02 activated.
pnp: Device 01:01.03 activated.
ALSA device list:
  #0: CS4239 at 0x534, irq 5, dma 1&0
Netfilter messages via NETLINK v0.30.
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
GRE over IPv4 tunneling driver
ip_conntrack version 2.4 (2047 buckets, 16376 max) - 232 bytes per conntrack
ip_conntrack_pptp version 3.1 loaded
ip_nat_pptp version 3.0 loaded
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost <sfrost@snowman.net>.  http://snowman.net/projects/ipt_recent/
ClusterIP Version 0.8 loaded successfully
arp_tables: (C) 2002 David S. Miller
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI Shortcut mode
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 168k freed
input: PS/2 Generic Mouse as /class/input/input3
Adding 2104504k swap on /dev/hda3.  Priority:-1 extents:1 across:2104504k
NTFS volume version 3.0.
eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
mtrr: 0xd0000000,0x8000000 overlaps existing 0xd0000000,0x2000000
mtrr: 0xd0000000,0x8000000 overlaps existing 0xd0000000,0x2000000
mtrr: 0xd0000000,0x8000000 overlaps existing 0xd0000000,0x2000000
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V2 device at 0000:00:00.0 into 4x mode
agpgart: Putting AGP V2 device at 0000:01:00.0 into 4x mode

[-- Attachment #3: Type: TEXT/PLAIN, Size: 9105 bytes --]

CONFIG_X86_32=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y

CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32

CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_POSIX_MQUEUE=y
CONFIG_SYSCTL=y
CONFIG_HOTPLUG=y
CONFIG_KOBJECT_UEVENT=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_KALLSYMS=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_CC_ALIGN_FUNCTIONS=0
CONFIG_CC_ALIGN_LABELS=0
CONFIG_CC_ALIGN_LOOPS=0
CONFIG_CC_ALIGN_JUMPS=0
CONFIG_BASE_SMALL=0

CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_OBSOLETE_MODPARM=y
CONFIG_KMOD=y


CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
CONFIG_DEFAULT_IOSCHED="anticipatory"

CONFIG_X86_PC=y
CONFIG_MK7=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_TSC=y
CONFIG_PREEMPT=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y

CONFIG_NOHIGHMEM=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_MTRR=y
CONFIG_REGPARM=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PHYSICAL_START=0x100000

CONFIG_PM=y
CONFIG_PM_LEGACY=y

CONFIG_ACPI=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_BLACKLIST_YEAR=0
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y



CONFIG_PCI=y
CONFIG_PCI_GODIRECT=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_LEGACY_PROC=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y



CONFIG_BINFMT_ELF=y

CONFIG_NET=y

CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_NET_IPGRE=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_BIC=y

CONFIG_NETFILTER=y

CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y

CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CONNTRACK_EVENTS=y
CONFIG_IP_NF_CT_PROTO_SCTP=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_NETBIOS_NS=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_PPTP=y
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_LIMIT=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_MAC=y
CONFIG_IP_NF_MATCH_PKTTYPE=y
CONFIG_IP_NF_MATCH_MARK=y
CONFIG_IP_NF_MATCH_MULTIPORT=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH_ESP=y
CONFIG_IP_NF_MATCH_LENGTH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_TCPMSS=y
CONFIG_IP_NF_MATCH_HELPER=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_MATCH_CONNTRACK=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_REALM=y
CONFIG_IP_NF_MATCH_SCTP=y
CONFIG_IP_NF_MATCH_DCCP=y
CONFIG_IP_NF_MATCH_COMMENT=y
CONFIG_IP_NF_MATCH_CONNMARK=y
CONFIG_IP_NF_MATCH_CONNBYTES=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_MATCH_STRING=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_TARGET_NFQUEUE=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_NAT_PPTP=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_MARK=y
CONFIG_IP_NF_TARGET_CLASSIFY=y
CONFIG_IP_NF_TARGET_TTL=y
CONFIG_IP_NF_TARGET_CONNMARK=y
CONFIG_IP_NF_TARGET_CLUSTERIP=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_TARGET_NOTRACK=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y



CONFIG_NET_CLS_ROUTE=y



CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y



CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
CONFIG_PARPORT_PC_FIFO=y
CONFIG_PARPORT_1284=y

CONFIG_PNP=y

CONFIG_ISAPNP=y
CONFIG_PNPBIOS=y
CONFIG_PNPBIOS_PROC_FS=y
CONFIG_PNPACPI=y

CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_RAM_COUNT=16

CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y

CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y

CONFIG_IDE_GENERIC=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_GENERIC=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_IVB=y
CONFIG_IDEDMA_AUTO=y







CONFIG_NETDEVICES=y



CONFIG_NET_ETHERNET=y
CONFIG_MII=y

CONFIG_NET_PCI=y
CONFIG_8139TOO=y





CONFIG_PPP=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPPOE=y



CONFIG_INPUT=y

CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1280
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=1024

CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=y

CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_LIBPS2=y

CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y

CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_DETECT_IRQ=y

CONFIG_SERIAL_CORE=y
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
CONFIG_PRINTER=y


CONFIG_RTC=y

CONFIG_AGP=y
CONFIG_AGP_VIA=y
CONFIG_DRM=y
CONFIG_DRM_RADEON=y


CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y

CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=y
CONFIG_I2C_ALGOPCA=y

CONFIG_I2C_ISA=y
CONFIG_I2C_VIAPRO=y

CONFIG_SENSORS_EEPROM=y


CONFIG_HWMON=y
CONFIG_SENSORS_VIA686A=y



CONFIG_VIDEO_DEV=y


CONFIG_VIDEO_BT848=y


CONFIG_VIDEO_TUNER=y
CONFIG_VIDEO_BUF=y
CONFIG_VIDEO_BTCX=y
CONFIG_VIDEO_IR=y
CONFIG_VIDEO_TVEEPROM=y

CONFIG_VIDEO_SELECT=y

CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y

CONFIG_SOUND=y

CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_GENERIC_DRIVER=y

CONFIG_SND_MPU401_UART=y
CONFIG_SND_OPL3_LIB=y

CONFIG_SND_CS4231_LIB=y
CONFIG_SND_CS4236=y

CONFIG_SND_BT87X=y


CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y






CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_FS_MBCACHE=y
CONFIG_JFS_FS=y
CONFIG_DNOTIFY=y

CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_ZISOFS_FS=y
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y

CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y

CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y


CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SMB_FS=y
CONFIG_CIFS=y

CONFIG_PARTITION_ADVANCED=y
CONFIG_MSDOS_PARTITION=y

CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-2"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_CODEPAGE_737=y
CONFIG_NLS_CODEPAGE_775=y
CONFIG_NLS_CODEPAGE_850=y
CONFIG_NLS_CODEPAGE_852=y
CONFIG_NLS_CODEPAGE_855=y
CONFIG_NLS_CODEPAGE_857=y
CONFIG_NLS_CODEPAGE_860=y
CONFIG_NLS_CODEPAGE_861=y
CONFIG_NLS_CODEPAGE_862=y
CONFIG_NLS_CODEPAGE_863=y
CONFIG_NLS_CODEPAGE_864=y
CONFIG_NLS_CODEPAGE_865=y
CONFIG_NLS_CODEPAGE_866=y
CONFIG_NLS_CODEPAGE_869=y
CONFIG_NLS_CODEPAGE_936=y
CONFIG_NLS_CODEPAGE_950=y
CONFIG_NLS_CODEPAGE_932=y
CONFIG_NLS_CODEPAGE_949=y
CONFIG_NLS_CODEPAGE_874=y
CONFIG_NLS_ISO8859_8=y
CONFIG_NLS_CODEPAGE_1250=y
CONFIG_NLS_CODEPAGE_1251=y
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
CONFIG_NLS_ISO8859_2=y
CONFIG_NLS_ISO8859_3=y
CONFIG_NLS_ISO8859_4=y
CONFIG_NLS_ISO8859_5=y
CONFIG_NLS_ISO8859_6=y
CONFIG_NLS_ISO8859_7=y
CONFIG_NLS_ISO8859_9=y
CONFIG_NLS_ISO8859_13=y
CONFIG_NLS_ISO8859_14=y
CONFIG_NLS_ISO8859_15=y
CONFIG_NLS_KOI8_R=y
CONFIG_NLS_KOI8_U=y
CONFIG_NLS_UTF8=y


CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_EARLY_PRINTK=y




CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=y
CONFIG_TEXTSEARCH_BM=y
CONFIG_TEXTSEARCH_FSM=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y

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

[James Courtier-Dutton]

caszonyi@rdslink.ro wrote:

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

dmix happens in alsa-lib (libasound...)
So, which version of the kernel you have will not make any difference to 
dmix.
Update your alsa-lib userspace to a more up to date version, and dmix 
will then work out of the box.

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

[Lee Revell]

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

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

Lee

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

[Lee Revell]

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

Sorry disregard last message.

Upgrade alsa-lib to 1.0.9 or later (preferable 1.0.10) to get dmix
working by default.  The default PCM is defined
in /usr/share/alsa/cards/$YOUR-CARD.conf which is part of alsa-lib.

Lee

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

[Kyle Moffett]

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

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

Cheers,
Kyle Moffett

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

"Why do musicians compose symphonies and poets write poems? They do  
it because life wouldn't have any meaning for them if they didn't.  
That's why I draw cartoons. It's my life."
   -- Charles Schulz

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

[Olivier Galibert]

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

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

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

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

- AC3/DTS encoding for multichannel output on spdif.

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

- dynamic range compression.

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

I have 3 main problems with ALSA, but using userspace for flexibility
is definitively not one of them.

  OG.

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

[Tomasz Torcz]

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

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

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

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


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

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

[Adrian Bunk]

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

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

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

I know about FreeBSD and partial support in NetBSD.

Are there any other [2]?

cu
Adrian

[1] I'm not talking about a port of the commercial OSS to the operating
    system which has little value for application developers.
[2] This is not a rhetorical question, I simply don't know about any 
    other.

-- 

       "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: [2.6 patch] schedule obsolete OSS drivers for removal

[Tomasz Kłoczko]

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

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

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

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

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

[Adrian Bunk]

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

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

> kloczek

cu
Adrian

-- 

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

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

[Tomasz Kłoczko]

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

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

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

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

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

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

[Adrian Bunk]

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

The question is simple:

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

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

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

> kloczek

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: [2.6 patch] schedule obsolete OSS drivers for removal

[Tomasz Kłoczko]

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

On Wed, 4 Jan 2006, Adrian Bunk wrote:

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

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

Be compliant with OSS specyfication allow save many time on applications 
development level by consume (in good sense) time spend on this 
applications by *BSD, Solaris and other systems developers (even on not 
open source applications).
After four years ALSA development quality of sound support in Linux is IMO 
on the ~same (still bad) level as four years ago. Still to complicated 
but now more bloated and additionaly not ready for handle fancy gadgets 
like BT headsets.
On other systems (MOX, Win*, Solaris ..) on handle sound situations is now 
better than four years ago. IMO this allow form conclution: generaly 
current ALSA is step back compare to other systems and probaly Linux need 
some deeper work then simple polishing sound device drivers.

More than year Linux in many publications is described as "excelent 
system for mobile gadgets". All waits for this ..
Most of this gadgets want uses sound. Force using ALSA in this are makes 
nightmares not only for drivers developers but also for user space 
applications developers.

(IMO in comming year or two if nothing will change Linux can be visable 
marginalized/can loose current possition .. not because in this period 
Linux will be worse compare to now but because other systems like Solaris, 
MOX and also Win* can pass in this period better progress on bringing some 
valuable functionalities in usable/simpler form for joe-like users .. 
remember: sound support in Linux isn't for data centers/big-ass-machines :)

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

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

[Alan Cox]

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

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

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

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

Alan

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

[Greg Louis]

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

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

So even if sound support in Linux _is_ for "big-ass" studio work, it
would be nice if little guys didn't get abandoned along the way, IMHO.

-- 
| G r e g  L o u i s         | gpg public key: 0x400B1AA86D9E3E64 |
|  http://www.bgl.nu/~glouis |   (on my website or any keyserver) |
|  http://wecanstopspam.org in signatures helps fight junk email. |

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

[Adrian Bunk]

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

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

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

We might end up with a handful of OSS drivers for some ancient 
soundcards without ALSA support and keep them similar to the old CD-ROM 
drivers under drivers/cdrom/ (or someone might write ALSA drivers for 
such hardware), but we don't need two drivers for the same hardware.

> - ALSA can't be persuaded (not by me, anyway) to drive my VIA
>   ac97_codec onboard sound hardware -- everything works fine except
>   unmuting ;) -- bye, machine 2

Can you give me a bug number in the ALSA bug tracking system for this 
issue to track it?

> - ALSA does suport my i810_audio ac97_codec laptop, but so does OSS,
>   equally well (for my unsophisticated needs) and with a far less
>   elephantine footprint in memory. -- strike 3, ALSA out.
>...

How much RAM does your system have that this is really an issue for you?

Sure, it would be possible to make ALSA a bit slimmer, but if you are 
running something like KDE or Mozilla or OpenOffice on your Laptop the 
size of the kernel shouldn't be a real issue.

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: [2.6 patch] schedule obsolete OSS drivers for removal

[tapas]

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

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

Hi,

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

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

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

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

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

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

Drawbacks yet:

- complicated device naming scheme. There has been recent changes in
this area to build up a list from which the user can select a device.

- so so documentation: 

-- many apps still use the ALSA api wrongly due to the complex nature of
it and lacking tutorials, etc (for example: ALSA apps should always use
the "default" device if not otherwise indicated by the user. The user
must be able to enter any device identifier string, or additionally
select from the newly built ALSA provided choices list).

-- Users get frustrated often, too, because their distros fail to setup
their ALSA system correctly. Documentation does exist, but it's often of
a technical nature, which is too much for joe user. 

- a single badly behaved OSS app can kill the whole software mixing
setup, leaving the user with seemingly hanging applications. This is
IMHO completely unacceptable. ALSA devs have, more than once, stated
that it is perfectly well acceptable for them :(

- there's two reasons for above:

-- ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
software mixing. As aoss cannot provide OSS emulation to all OSS apps,
the kernel level OSS emu must be fixed. I would probably have a look at
FUSE to redirect OSS access to userspace. I suppose oss2jack could be
modified to use ALSA instead of jack.

-- ALSA's default open mode is "blocking". But the ALSA API uses the
term blocking in two meanings and throws them together into the open
mode of a pcm device. Normally on device files, blocking access means a
read()/write() returns, when there's data which has actually been
read/written to the device. nonblocking access means, read()/write()
return immediately. In ALSA blocking mode means above _plus_ that the
open call will only immediately return (in case of contention) when the
previous user of the audio device has given it up. 

The combination of the last two is deadly :) It leaves users with
nonfunctional sound plus seemingly hanging apps when their soundcard is
not hardware mixing capable. So IMHO, to fix these two issues really is
the most pressing matter of all, but like i said, sadly ALSA devs seem
to disagree (i haven't followed ALSA development that closely lately
though).

> On other systems (MOX, Win*, Solaris ..) on handle sound situations is now 
> better than four years ago. IMO this allow form conclution: generaly 
> current ALSA is step back compare to other systems and probaly Linux need 
> some deeper work then simple polishing sound device drivers.

ALSA is a definitive step forward from OSS. It even is superior to the
original windows sound system (except for ease of configuration - but
windows had no interapp midi routing (extra software needed) plus you
need another audio device driver system (ASIO) to get reliable low
latency operation, and even there it still sucks compared to
linux/ALSA/jack/-rt). MAC OS X almost got it right. Their design has
another drawback though which makes OS X always have ca. 1 period of
latency more. I.e. in terms of low latency operation for musicians with
jackd and -rt kernels, linux is ATM the _superior_ platform.

It is, when setup correctly simply a joy to work with and make music
with.

Regards,
Florian Schmidt

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

[Alistair John Strachan]

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

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

On Wednesday 04 January 2006 10:37, tapas wrote:
> On Wed, 4 Jan 2006 03:51:09 +0100 (CET)
>
> Tomasz K³oczko <kloczek@rudy.mif.pg.gda.pl> wrote:
> > After four years ALSA development quality of sound support in Linux is
> > IMO on the ~same (still bad) level as four years ago. Still to
> > complicated but now more bloated and additionaly not ready for handle
> > fancy gadgets like BT headsets.
>
> Hi,
>
> i want to chime in here in the defense of ALSA. ALSA is vastly superiour
> for musicians using linux as opposed to a mere music consumer. Right,
> for a music consumer (mp3s, cd's, etc), OSS was probably easier to setup
> and use, but there's other advantages of ALSA vs. OSS:
>
> - userspace software mixing (or better software mixing at all. OSS
> doesn't have this (the libre version in the kernel, not the closed
> source proprietary one)
>
> - userspace resampling (i.e. you have crappy AC97 card that sounds like
> shit when resampling automatically? Use the ALSA resampler. It might
> sound like shit, too, but at least it can be fixed ;)
>
> - the biggest benefit for me: MIDI routing in between any number of
> applications.
>
> - more capable (more complicated yeah but wtf :)) mixer implementation
> (the thing to control the volumes, etc)
>
> - way more flexible in handling more than one soundcard/device, etc..
>
> Drawbacks yet:
>
> - complicated device naming scheme. There has been recent changes in
> this area to build up a list from which the user can select a device.
>
> - so so documentation:
>
> -- many apps still use the ALSA api wrongly due to the complex nature of
> it and lacking tutorials, etc (for example: ALSA apps should always use
> the "default" device if not otherwise indicated by the user. The user
> must be able to enter any device identifier string, or additionally
> select from the newly built ALSA provided choices list).
>
> -- Users get frustrated often, too, because their distros fail to setup
> their ALSA system correctly. Documentation does exist, but it's often of
> a technical nature, which is too much for joe user.
>
> - a single badly behaved OSS app can kill the whole software mixing
> setup, leaving the user with seemingly hanging applications. This is
> IMHO completely unacceptable. ALSA devs have, more than once, stated
> that it is perfectly well acceptable for them :(
>
> - there's two reasons for above:
>
> -- ALSA's kernel level OSS emulation (as opposed to aoss) cannot provide
> software mixing. As aoss cannot provide OSS emulation to all OSS apps,
> the kernel level OSS emu must be fixed. I would probably have a look at
> FUSE to redirect OSS access to userspace. I suppose oss2jack could be
> modified to use ALSA instead of jack.
>
> -- ALSA's default open mode is "blocking". But the ALSA API uses the
> term blocking in two meanings and throws them together into the open
> mode of a pcm device. Normally on device files, blocking access means a
> read()/write() returns, when there's data which has actually been
> read/written to the device. nonblocking access means, read()/write()
> return immediately. In ALSA blocking mode means above _plus_ that the
> open call will only immediately return (in case of contention) when the
> previous user of the audio device has given it up.
>
> The combination of the last two is deadly :) It leaves users with
> nonfunctional sound plus seemingly hanging apps when their soundcard is
> not hardware mixing capable. So IMHO, to fix these two issues really is
> the most pressing matter of all, but like i said, sadly ALSA devs seem
> to disagree (i haven't followed ALSA development that closely lately
> though).
>
> > On other systems (MOX, Win*, Solaris ..) on handle sound situations is
> > now better than four years ago. IMO this allow form conclution: generaly
> > current ALSA is step back compare to other systems and probaly Linux need
> > some deeper work then simple polishing sound device drivers.
>
> ALSA is a definitive step forward from OSS. It even is superior to the
> original windows sound system (except for ease of configuration - but
> windows had no interapp midi routing (extra software needed) plus you
> need another audio device driver system (ASIO) to get reliable low
> latency operation, and even there it still sucks compared to
> linux/ALSA/jack/-rt). MAC OS X almost got it right. Their design has
> another drawback though which makes OS X always have ca. 1 period of
> latency more. I.e. in terms of low latency operation for musicians with
> jackd and -rt kernels, linux is ATM the _superior_ platform.
>
> It is, when setup correctly simply a joy to work with and make music
> with.
>
> Regards,
> Florian Schmidt

-- 
Cheers,
Alistair.

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

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

[Jan Engelhardt]

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

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

Jan Engelhardt
-- 

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

[Takashi Iwai]

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

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


Takashi

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

[Florian Schmidt]

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

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

Hi Takashi,

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

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

Regards,
Flo

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

[Marcin Dalecki]

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

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

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

[Florian Schmidt]

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

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

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

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

Flo

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

[Jan Engelhardt]

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

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

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


Jan Engelhardt
-- 

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

[Takashi Iwai]

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

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


Thanks,

Takashi

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

[Jim Crilly]

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

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

Jim.

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

[Lee Revell]

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

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

Lee

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

[Edgar Toernig]

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

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

Ciao, ET.

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

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

[Lee Revell]

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

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

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

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

Lee

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

[Lee Revell]

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

If you'd like to help debug this:

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

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

Lee

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

[Edgar Toernig]

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

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

   alsa-usbaudio-2.6.15-revert-008.patch

seems to fix that.  Thanks.

But now (alsa-1.0.9 userspace):

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

with 2.6.13 all 4 are ok.

Ciao, ET.

PS: Someone reported on bugzilla that his usb-audio is not always detected.
Just for the record - happens here too, usually when cold-booting.

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

[Lee Revell]

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

OK.  This is getting a bit much for LKML, can you open a new bug and set
it related to #1585?

Lee

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

[Edgar Toernig]

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

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

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

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

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

Ciao, ET.

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

[Lee Revell]

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

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

Lee

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

[Lee Revell]

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

Why not?

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

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

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

Lee

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

[Florian Schmidt]

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

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

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

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

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

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

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

- access to userspace ALSA lib which would allow it to work together
with ALSA's sw mixing for native ALSA apps.

Maybe it can be developed as a third alternative independently. People
without FUSE would have to try their luck with the other two. Plus,
there's oss2jack which can probably be modified to use ALSA instead of
jack (although i thinkg oss2jack actually uses fusd and not FUSE. Hmm,
some more hacking would be required then). Also i think a FUSE based
approach is actually less ugly than a LD_PRELOAD hack. 

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

Regards,
Flo

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

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

[Lee Revell]

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

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

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

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

Lee

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

[Ville Herva]

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

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

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

With Intel i815 integrated sound, ALSA dmix does work.


-- v -- 

v@iki.fi

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

[Lee Revell]

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

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

Lee

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

[Ville Herva]

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

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

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

I'll keep retesting the new releases.


-- v -- 

v@iki.fi

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

[Lee Revell]

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

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

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

Lee

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

[Ville Herva]

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

I will try to come up with one.

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

Yes.

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

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

So it was definetely bad research on my part. 

But I still maintain that the asoundrc required for swmixing is not as
trivial as "just works". It wasn't even with i815 audio.
 
> If vendors gave us more docs so that reverse engineering drivers was not
> the norm, the situation would improve greatly.

I understand.



-- v -- 

v@iki.fi

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

[Lee Revell]

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

Since ALSA 1.0.9 (alsa-lib and alsa-driver > 1.0.9 required) no special
configuration is required to get software mixing to work for i815 (and
other chipsets which lack hardware mixing), with a few exception like
ICE1712 and ICE1724 where a more complex configuration was required due
to hardware restrictions.

You should never have to touch an .asoundrc file to get software mixing
to work, if you do it's a bug.

Lee

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

[Ville Herva]

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

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

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



-- v -- 

v@iki.fi

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

[Lee Revell]

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

Try the latest ALSA CVS code.

Lee

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

[Lee Revell]

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

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

> Errm, i'm actually wrong about that. Kernel level OSS emu sw mixing
> cannot work together with userspace ALSA sw mixing. I completely missed
> that point.
> 
> I still think, the easiest way would be to use FUSE as it gives the best
> of both worlds:

Yep, this does sound like a promising approach.  AFAIK it's never been
seriously explored as FUSE is so new.

Lee

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

[Tomasz Torcz]

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

  Skype. Earlier Quake 3 Arena (now Q3A is open source with SDL sound,
so it had native ALSA).
  They're more widely used that musical software for which ALSA seem to
be written. People needing <1ms latency are "obscure corner cases" in
real world.

-- 
Tomasz Torcz                Only gods can safely risk perfection,
zdzichu@irc.-nie.spam-.pl     it's a dangerous thing for a man.  -- Alia

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

[Lee Revell]

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

It's not that aoss "can't work" for these, it certainly has some bugs.
But the examples you gave are both proprietary apps.  Obviously we can't
waste our time debugging them.

No one has even been able to provide a test case using an app we have
the source to.

Lee

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

[Florian Schmidt]

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

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

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

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

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

http://fort.xdas.com/~kor/oss2jack/

Btw: It has a nice list of compatible apps including skype and quake3
;)

Btw2: Heh, oss2jack already has direct ALSA support on its TODO list :)

fusd:

http://www.circlemud.org/%7Ejelson/software/fusd/

Regards,
Flo

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

[Stefan Smietanowski]

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

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

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

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

// Stefan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

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

[Tomasz Kłoczko]

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

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

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

Summarize: stop looking on sound subsystem problems as Linux specyfic and 
assume that THE SAME problems exists on other unices in so simillar form
so is possible thinking on OSS support on kernel level details in the 
same forms as on other unices. Linux case isn't so unusual in this area .. 
it is VERY typical :>
If you will take this as true you can start looking on OSS API on Linux
from correct point of view.
And start asking ALSA people: why using OSS API in other unices 
simple works and it ins't problem and on Linux "it was so big problem 
that reinventing sound support in ALSA form was neccessary" ?

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

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

[Stefan Smietanowski]

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

Tomasz Kłoczko wrote:
> On Wed, 4 Jan 2006, Stefan Smietanowski wrote:
> [..]
> 
>>> Solaris, AIX ..
>>> Full list is avalaible in "Operating System" listbox on
>>> http://www.4front-tech.com/download.cgi
>>
>>
>> Are all those Operatings Systems that include OSS per default, no
>> additional download required? Because that's what he's asking for,
>> not what you can get OSS for.
>>
>> Since that link is a _download page_ it makes me think that it's
>> an _additional download_ to get OSS support on those (or some of
>> those) operating systems.
> 
> 
> So start another "it makes me think" and imagine that in Solaris case
> using drivers not provided directly on distribution level is NORMAL
> habit. Why ? Bacause Solaris have well defined kernel API (from many
> years in some common areas it is constants which makes
> Documentation/stable_api_nonsense.txt from Linux tree piece of crap).
> This allow use device drivers prepared first for example for older
> kernels (8,9) on latest (10). I.e.: Solaris 10 inroduces stop supporting
> some older network cards (IIRC for old SMC cards). I know people which
> still uses this cards on Sol10 by using binary drivers prepared for
> older Solarises without visable problems. Also many device drivers have
> double versions (one from distribution resouurces and second provided by
> device vendor).
> 
> Summarize: stop looking on sound subsystem problems as Linux specyfic
> and assume that THE SAME problems exists on other unices in so simillar
> form
> so is possible thinking on OSS support on kernel level details in the
> same forms as on other unices. Linux case isn't so unusual in this area
> .. it is VERY typical :>
> If you will take this as true you can start looking on OSS API on Linux
> from correct point of view.
> And start asking ALSA people: why using OSS API in other unices simple
> works and it ins't problem and on Linux "it was so big problem that
> reinventing sound support in ALSA form was neccessary" ?
> 
> kloczek

So if I buy $COMMERCIAL_PROGRAM for say Solaris, AIX or anything else
it REQUIRES me to download (before: buy) $COMMERCIAL_SOUNDSYSTEM?

"In order to use this program you need to have OSS installed."

That sounds insane to say the least.

// Stefan

download $COMMERCIAL_SOUNDSYSTEM ins


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

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

[Peter Bortas]

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

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

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

--
Peter Bortas

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

[Jan Engelhardt]

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



Jan Engelhardt
-- 

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

[Lee Revell]

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

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

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

Lee

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

[Stefan Smietanowski]

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

Hi.

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

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

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

// Stefan

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 251 bytes --]

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

[Peter Bortas]

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

Correct. Rederection to $AUDIODEVICE that is a normal /dev/audio.

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

[Jan Engelhardt]

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

Oh well this does work for me.

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

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

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


Jan Engelhardt
-- 

Re: [OT] ALSA userspace API complexity

[Patrizio Bassi]

Jaroslav Kysela ha scritto:
> On Wed, 4 Jan 2006, Pete Zaitcev wrote:
> 
> 
>>On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
>>
>>
>>>>2) ALSA API is to complicated: most applications opens single sound
>>>>   stream.
>>>
>>>FUD and nonsense. []
>>>http://devzero.co.uk/~alistair/alsa/
>>
>>That's the kicker, isn't it? Once you get used to it, it's a workable
>>API, if kinky and verbose. I have a real life example, too:
>> http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
>>But arriving on the solution costed a lot of torn hair. Look at this
>>bald head here! And who is going to pay my medical bills when ALSA
>>causes me ulcers, Jaroslav?
> 
> 
> Well, the ALSA primary goal is to be the complete HAL not hidding the 
> extra hardware capabilities to applications. So API might look a bit 
> complicated for the first glance, but the ALSA interface code for simple 
> applications is not so big, isn't?
> 
> Also, note that app developers are not forced to use ALSA directly - there 
> is a lot of "portable" sound API libraries having an ALSA backend doing
> this job quite effectively. We can add a simple (like OSS) API layer 
> into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
> some support functions for the easy PCM device initialization might be
> a good idea.
> 
> 						Jaroslav
> 

considering that alsa API and drivers is pretty stable i see no problem
in OSS removal.
When writing a program adding oss compatibility seems faster, but,
creates lots of problems.
check the skype example (yes i know it's closed-source). 99% of sound
problems users have is due to OSS driver usage.

that's a big problem. Needs a radical solution. Considering aoss works
in 50% of cases i suggest aoss improvement and not OSS keeping in kernel.

A good idea could be an OSS API layer over Alsa-lib...but i personally
don't know how much can that costs, considering you should link against
alsa-lib too.

This discussion seems a no-sense.
Kernel API continues to change every -rc and noone cares that.
OSS has been deprecated for a lot, and it's as old as moon.

	Patrizio

--
Patrizio Bassi
www.patriziobassi.it

Re: [OT] ALSA userspace API complexity

[Florian Schmidt]

On Wed, 04 Jan 2006 12:56:12 +0100
Patrizio Bassi <patrizio.bassi@gmail.com> wrote:

> that's a big problem. Needs a radical solution. Considering aoss works
> in 50% of cases i suggest aoss improvement and not OSS keeping in kernel.

aoss works _much_ less often than the OSS emulation kernel modules. I'd
rather see (if not just for ease of setup), sw mixing in the OSS
emulation kernel modules. aoss should still continue to exist as it has
some advanced functionality like being able to use any alsa defined pcm
device, but for the vast majority of cases it would be the best if the
OSS emulation kernel module simply finally provided sw mixing.

It might also be worth taking a look at FUSE and stuff like oss2jack
instead, as it would be (imho) the cleaner approach for getting OSS
emulation to userspace as opposed to aoss (device file interface vs.
ugly LD_PRELOAD hack (which has its share of problems. Especially with
apps/libs that resolved the linux system call symbols at compile time -
this is where aoss/LD_PRELOAD won't work, but a FUSE based approach
would)).

Actually i suppose a FUSE based oss2alsa would probably make the old OSS
emulation modules unnecessary if implemented right :) As the relevant
code then lives in userspace it can make trivial use of stuff like ALSA
sw mixing and all other ALSA userspace goodies (which aoss can, too, but
at the cost of being an ugly LD_PRELOAD hack).

Have fun,
Flo

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

Re: [OT] ALSA userspace API complexity

[Alistair John Strachan]

On Wednesday 04 January 2006 18:07, Florian Schmidt wrote:
> On Wed, 04 Jan 2006 12:56:12 +0100
>
> Patrizio Bassi <patrizio.bassi@gmail.com> wrote:
> > that's a big problem. Needs a radical solution. Considering aoss works
> > in 50% of cases i suggest aoss improvement and not OSS keeping in kernel.
>
> aoss works _much_ less often than the OSS emulation kernel modules. I'd
> rather see (if not just for ease of setup), sw mixing in the OSS
> emulation kernel modules. aoss should still continue to exist as it has
> some advanced functionality like being able to use any alsa defined pcm
> device, but for the vast majority of cases it would be the best if the
> OSS emulation kernel module simply finally provided sw mixing.
>
> It might also be worth taking a look at FUSE and stuff like oss2jack
> instead, as it would be (imho) the cleaner approach for getting OSS
> emulation to userspace as opposed to aoss (device file interface vs.
> ugly LD_PRELOAD hack (which has its share of problems. Especially with
> apps/libs that resolved the linux system call symbols at compile time -
> this is where aoss/LD_PRELOAD won't work, but a FUSE based approach
> would)).
>
> Actually i suppose a FUSE based oss2alsa would probably make the old OSS
> emulation modules unnecessary if implemented right :) As the relevant
> code then lives in userspace it can make trivial use of stuff like ALSA
> sw mixing and all other ALSA userspace goodies (which aoss can, too, but
> at the cost of being an ugly LD_PRELOAD hack).

Not to disrespect Miklos's work, but relying on FUSE for such a fundamental 
problem is probably not a good idea. Most people probably do not compile FUSE 
into their kernel.

I do agree with other posters here that OSS compatibility a) needs to be 
improved and b) should not be limited to the features of the soundcard (i.e. 
it must software mix). As Andi has pointed out, wholly removing OSS is not in 
the spirit of Linux and will not happen for many years.

-- 
Cheers,
Alistair.

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

Re: [OT] ALSA userspace API complexity

[Lee Revell]

On Wed, 2006-01-04 at 12:56 +0100, Patrizio Bassi wrote:
> that's a big problem. Needs a radical solution. Considering aoss works
> in 50% of cases i suggest aoss improvement and not OSS keeping in
> kernel.
> 

Please rephrase your statement in the form of a USEFUL BUG REPORT.

Lee

Re: [OT] ALSA userspace API complexity

[Patrizio Bassi]

Lee Revell ha scritto:

>On Wed, 2006-01-04 at 12:56 +0100, Patrizio Bassi wrote:
>  
>
>>that's a big problem. Needs a radical solution. Considering aoss works
>>in 50% of cases i suggest aoss improvement and not OSS keeping in
>>kernel.
>>
>>    
>>
>
>Please rephrase your statement in the form of a USEFUL BUG REPORT.
>
>Lee
>
>
>  
>
i opened an aoss/skype bug, that got closed without a complete fix..
because other problems were found...but actually that's not a complete
solution

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

Re: [OT] ALSA userspace API complexity

[Lee Revell]

On Thu, 2006-01-05 at 21:06 +0100, Patrizio Bassi wrote:
> Lee Revell ha scritto:
> 
> >On Wed, 2006-01-04 at 12:56 +0100, Patrizio Bassi wrote:
> >  
> >
> >>that's a big problem. Needs a radical solution. Considering aoss works
> >>in 50% of cases i suggest aoss improvement and not OSS keeping in
> >>kernel.
> >>
> >>    
> >>
> >
> >Please rephrase your statement in the form of a USEFUL BUG REPORT.
> >
> >Lee
> >
> >
> >  
> >
> i opened an aoss/skype bug, that got closed without a complete fix..
> because other problems were found...but actually that's not a complete
> solution
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1224
> 
> 

Please see bug #1228.  I closed #1224 as it had diverged wildly from the
original bug report (which was someone asking "why ALSA doesn't do
software mixing like artsd", which it does of course).

The status is we need more information on this bug.  Some people report
that Skype works perfectly with aoss.  It seems to be hardware, ALSA
version, or Skype version dependent.

Since Skype is closed source I'm afraid you'll have to do most of the
debugging work yourself, we can't waste time debugging closed source
apps.

I have heard that kiax (open source VOIP client) has some of the same
problems with aoss as Skype so that's likely to be the most productive
approach.

Lee

Re: [OT] ALSA userspace API complexity

[Patrizio Bassi]

Lee Revell ha scritto:

>On Wed, 2006-01-04 at 12:56 +0100, Patrizio Bassi wrote:
>  
>
>>that's a big problem. Needs a radical solution. Considering aoss works
>>in 50% of cases i suggest aoss improvement and not OSS keeping in
>>kernel.
>>
>>    
>>
>
>
>  
>
yes i am the one (testing lots of voip solutions) in the bug report.

i told you that kiax has a similar problem :)

i think this sort of mail flood in kml is not productive.
As Lee asked, let's use their mantis system and leave kml free.

this is going OT...from OSS removal, to Alsa bad design, to Alsa
bugs...what else?

Patrizio

Re: [OT] ALSA userspace API complexity

[Heikki Orsila]

Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> On Tuesday 03 January 2006 23:10, Tomasz K?oczko wrote:
> 2) ALSA API is to complicated: most applications opens single sound
>    stream.

> FUD and nonsense. I've written many DSP applications and very often I can
> recycle the same code for use in them.

It's not FUD and it's very true. I've written ALSA support for many 
programs and I still can't remember the tricks that are needed to get 
even basic things working.

Just look at error handling of libao-0.8.6 for a great example how 
complicated it is to write code for ALSA. The following code is directly 
from the source:

                /* try to write the entire buffer at once */
                err = internal->writei(internal->pcm_handle, ptr, len);

                /* it's possible that no data was transferred */
                if (err == -EAGAIN) {
                        continue;
                }

                if (err < 0) {
                        /* this might be an error, or an exception */
                        err = alsa_error_recovery(internal, err);
                        if (err < 0) {
                                fprintf(stderr,"ALSA write error: %s\n",
                                                snd_strerror(err));
                                return 0;
                        }

                        /* abandon the rest of the buffer */
                        break;
                }

alsa_error_recovery() expands to 30 lines of more logic. This is pretty 
insane considering that libao _only_ writes data to device and does 
nothing else. If ALSA was done properly, the main loop would simply be:

                err = internal->writei(internal->pcm_handle, ptr, len);

                /* it's possible that no data was transferred */
                if (err == -EAGAIN || err == -EINTR) {
                        continue;
                }

		if (err < 0) {
			/* BAD BAD */
		}

When I originally ran into this signal handling brain damage of ALSA, I 
had to actually look into other programs how they handle signals because 
ALSA documentation is so bad. The core problem is of course the broken 
API, not the bad documentation.

A small note, libao can not handle EINTR properly. A patch has been 
submitted already.

I've long ago stopped using ALSA API because it is broken. But if you 
wanted to make ALSA usable by real people you might considering adding 3 
functions (there are ~300 already so not much loss):

	err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
	err = alsa_simple_writei(); /* handless signal brokeness automagically */
	alsa_simple_close();

Basically ogg123/mpg123 like applications would only need 3 alsa calls. 
Now everyone reimplementing their own buggy versions of simple mechanisms.

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Thu, 5 Jan 2006, Heikki Orsila wrote:

> Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > On Tuesday 03 January 2006 23:10, Tomasz K?oczko wrote:
> > 2) ALSA API is to complicated: most applications opens single sound
> >    stream.
> 
> > FUD and nonsense. I've written many DSP applications and very often I can
> > recycle the same code for use in them.
> 
> I've long ago stopped using ALSA API because it is broken. But if you 
> wanted to make ALSA usable by real people you might considering adding 3 
> functions (there are ~300 already so not much loss):

This sentence makes this in my mind: real people = lazy people. The error 
codes are documented well. Also, aplay in the alsa-utils package has
good error recovery code including test pcm.c utility in alsa-lib.

> 	err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
> 	err = alsa_simple_writei(); /* handless signal brokeness automagically */
> 	alsa_simple_close();

Well, it's better to create only "fast parameter setup" and "default error 
recovery" functions.

> Basically ogg123/mpg123 like applications would only need 3 alsa calls. 
> Now everyone reimplementing their own buggy versions of simple mechanisms.

While "official" examples exists for a long time. Also, we already noted 
that we are not best documentation writers, but everytime when we ask for 
help we hear nothing from other people.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Heikki Orsila]

On Thu, Jan 05, 2006 at 03:24:18PM +0100, Jaroslav Kysela wrote:
> On Thu, 5 Jan 2006, Heikki Orsila wrote:
> This sentence makes this in my mind: real people = lazy people.

Yes, but it has good reasons too. The real point of userspace libraries 
and programs rather than kernel space is saving effort. Laziness in 
programming is good so long as programs are readable and correct.

Your success must be measured according to the number of bugs with ALSA 
programs and the time used to develop ALSA support for them. Right now 
it looks very bad to me. Even libao can't handle ALSA well, and knowing 
some XMMS developers they have hard time with ALSAs complexity. KISS.

> The error codes are documented well.

That's a bad excuse for requiring buffer underruns to be handled 
specially because it's not a fatal error. Errors should be handled 
as close to the error source as possible, and the ALSA lib is the 
logical place to handle underrun by default (unless the application 
really is interested in handling underruns specially). Passing errors 
through unreasonably many layers causes more complexity for programmers.

> > 	err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
> > 	err = alsa_simple_writei(); /* handless signal brokeness automagically */
> > 	alsa_simple_close();
> 
> Well, it's better to create only "fast parameter setup" and "default error 
> recovery" functions.

As long as all applications PCM code can be written into 10-20 C lines. 
That includes: opening device, writing pcm data and closing the device. 

> > Basically ogg123/mpg123 like applications would only need 3 alsa calls. 
> > Now everyone reimplementing their own buggy versions of simple mechanisms.
> 
> While "official" examples exists for a long time.

btw. your official examples don't work on simple PCM playback didn't 
work when I last time tried. Sorry, I can't remember details because it 
is so long ago.

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Thu, 5 Jan 2006, Heikki Orsila wrote:

> > > 	err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
> > > 	err = alsa_simple_writei(); /* handless signal brokeness automagically */
> > > 	alsa_simple_close();
> > 
> > Well, it's better to create only "fast parameter setup" and "default error 
> > recovery" functions.
> 
> As long as all applications PCM code can be written into 10-20 C lines. 
> That includes: opening device, writing pcm data and closing the device. 

I've added snd_pcm_set_params() and snd_pcm_recover() functions into 
alsa-lib (they're a bit experimental and I'm still waiting for any 
feedback from others).

The "minimal example" can be reached at:

http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/test/pcm_min.c?rev=1.2&view=markup

> > > Basically ogg123/mpg123 like applications would only need 3 alsa calls. 
> > > Now everyone reimplementing their own buggy versions of simple mechanisms.
> > 
> > While "official" examples exists for a long time.
> 
> btw. your official examples don't work on simple PCM playback didn't 
> work when I last time tried. Sorry, I can't remember details because it 
> is so long ago.

Any bug report? We don't have a crystal ball to fix bugs without any 
information.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Heikki Orsila]

On Tue, Jan 10, 2006 at 10:22:40AM +0100, Jaroslav Kysela wrote:
> The "minimal example" can be reached at:
> 
> http://cvs.sourceforge.net/viewcvs.py/alsa/alsa-lib/test/pcm_min.c?rev=1.2&view=markup

Thank you. It looks good.

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: [OT] ALSA userspace API complexity

[Olivier Galibert]

On Thu, Jan 05, 2006 at 03:24:18PM +0100, Jaroslav Kysela wrote:
> This sentence makes this in my mind: real people = lazy people. The error 
> codes are documented well.

Actual alsa reference documentation:

  int snd_pcm_prepare(snd_pcm_t *pcm)   	
  	
Prepare PCM for use.

Parameters:
    pcm 	PCM handle

Returns:
    0 on success otherwise a negative error code 

[Beautifully documented error codes and causes]

snd_pcm_sframes_t snd_pcm_writei(snd_pcm_t * pcm,
		const void *buffer,
		snd_pcm_uframes_t size
	)  	
  	
Write interleaved frames to a PCM.

Parameters:
    pcm 	PCM handle
    buffer 	frames containing buffer
    size 	frames to be written

Returns:
    a positive number of frames actually written otherwise a negative error code 

Return values:
    -EBADFD 	PCM is not in the right state (SND_PCM_STATE_PREPARED or SND_PCM_STATE_RUNNING)
    -EPIPE 	an underrun occurred
    -ESTRPIPE 	a suspend event occurred (stream is suspended and waiting for an application recovery)

If the blocking behaviour is selected, then routine waits until all requested bytes are played or put to the playback ring buffer. The count of bytes can be less only if a signal or underrun occurred.

If the non-blocking behaviour is selected, then routine doesn't wait at all.

[Count of bytes less than the frame count when an underrun, which
returns -EPIPE, happened?  -EBADFD when the state is XRUN (not it
doesn't)?  Cause and handling of suspend events?]

Anybody who says the alsa documentation is good never had to use it.
At that point I know my simple playing code is incorrect and I have no
clue on how to fix it.


> Also, aplay in the alsa-utils package has
> good error recovery code including test pcm.c utility in alsa-lib.

A sleep(1) in the error recovery path?  Are you people nuts?

Incidentally:

- "A small demo which sends a simple sinusoidal wave to the speakers"
  requiring close to 900 lines is demented.  That's the size of
  glxgears.c, with 50% of that one being printer support.  A complete
  smartflow example getting a sound stream on the network and playing
  it with oss takes 160 lines, with 20 lines of copyright-ish at the
  start.  The actual sound part of that is _30_ lines.


- Error and state handling after writei changes depending on the call.
  We're supposed to guess which one is correct?


Make simple things simple, guys.

  OG.

Re: [OT] ALSA userspace API complexity

[Alexander E. Patrakov]

Olivier Galibert wrote:

> Make simple things simple, guys.

Sorry for hijacking the thread, but it is very true. ALSA is just too 
flexible so that the ALSA equivalent (if it indeed exists) of 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339951 cannot be fixed. 
OSS allows specification of device name, and one can set up udev rules 
so that e.g. /dev/dsp-creative it is always a symlink to a SB PCI sound 
card and /dev/dsp-fortemedia is for FM801. Then one can tell xine to 
play sound through /dev/dsp-fortemedia. ALSA accepts only numbers in its 
plughw:x,y,z notation, and applications are unfixable when kernel device 
numbers become random.

-- 
Alexander E. Patrakov

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Thu, 5 Jan 2006, Alexander E. Patrakov wrote:

> Olivier Galibert wrote:
> 
> > Make simple things simple, guys.
> 
> Sorry for hijacking the thread, but it is very true. ALSA is just too flexible
> so that the ALSA equivalent (if it indeed exists) of
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339951 cannot be fixed. OSS
> allows specification of device name, and one can set up udev rules so that
> e.g. /dev/dsp-creative it is always a symlink to a SB PCI sound card and
> /dev/dsp-fortemedia is for FM801. Then one can tell xine to play sound through
> /dev/dsp-fortemedia. ALSA accepts only numbers in its plughw:x,y,z notation,
> and applications are unfixable when kernel device numbers become random.

It's not true. You can also use plughw:CARDID,0 or so notation. 
Identification of cards are available via control interface or look 
to /proc/asound/cards file. The card ID string can be set via
a module option. Also you can fix the card index numbers with
a module option.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Alexander E. Patrakov]

Jaroslav Kysela wrote:

>You can also use plughw:CARDID,0 or so notation. 
>  
>
Thanks, it works here indeed.

>Identification of cards are available via control interface or look 
>to /proc/asound/cards file. The card ID string can be set via
>a module option. Also you can fix the card index numbers with
>a module option.
>  
>
The point here is that virtually every other subsystem can use udev to 
rename devices and/or create symlinks. For ALSA, an ALSA-specific 
solution has to be used. Although, I admit that udev offers nothing over 
this solution for my sound card.

-- 
Alexander E. Patrakov

Re: [OT] ALSA userspace API complexity

[Florian Schmidt]

On Thu, 05 Jan 2006 20:26:36 +0500
"Alexander E. Patrakov" <patrakov@gmail.com> wrote:

> Olivier Galibert wrote:
> 
> > Make simple things simple, guys.
> 
> Sorry for hijacking the thread, but it is very true. ALSA is just too 
> flexible so that the ALSA equivalent (if it indeed exists) of 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339951 cannot be fixed. 
> OSS allows specification of device name, and one can set up udev rules 
> so that e.g. /dev/dsp-creative it is always a symlink to a SB PCI sound 
> card and /dev/dsp-fortemedia is for FM801. Then one can tell xine to 
> play sound through /dev/dsp-fortemedia. ALSA accepts only numbers in its 
> plughw:x,y,z notation, and applications are unfixable when kernel device 
> numbers become random.

maybe i misunderstood your point, but:

a] every alsa driver can have an option "index" which tells it what card
number to grab, so either pass it as module load option or at kernel
boot time..

b] applications should actually allow the user to enter _any_ string as
a device name (well "any" is actually too much). This enables the user
to define his own pcm devices (i.e. using alsa pcm LADSPA plugin) and
use these in any native ALSA app.

There's all kind of nifty predefined pcm device definitions available,
as i.e. "surround50", "surround51", etc.. One can even indicate what
card number to use, i.e. "surround50:0" or "surround50:2" (for the first
and third card in the system respectively). The special name "!default"
can also be overridden easily to make any sane and well programmed ALSA
app use a certain pcm device of the user's choice.

If i completely missed your point -> sorry

Flo


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

Re: [OT] ALSA userspace API complexity

[Jaroslav Kysela]

On Thu, 5 Jan 2006, Olivier Galibert wrote:

> - "A small demo which sends a simple sinusoidal wave to the speakers"
>   requiring close to 900 lines is demented.  That's the size of
>   glxgears.c, with 50% of that one being printer support.  A complete
>   smartflow example getting a sound stream on the network and playing
>   it with oss takes 160 lines, with 20 lines of copyright-ish at the
>   start.  The actual sound part of that is _30_ lines.

The pcm.c file shows you 7 available methods how you can send audio data 
to alsa-lib. It's complete example. If you remove the parsing command 
line, sine generation, error handling, you'll end with few lines too.

> - Error and state handling after writei changes depending on the call.
>   We're supposed to guess which one is correct?
> 
> Make simple things simple, guys.

Yes, we should stay with simple 1.0 linux kernel. Anyway, we're taking all 
points from this discussion.

						Jaroslav

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

Re: [OT] ALSA userspace API complexity

[Marcin Dalecki]

On 2006-01-05, at 16:33, Jaroslav Kysela wrote:
>> Make simple things simple, guys.
>
> Yes, we should stay with simple 1.0 linux kernel.

This blatant attempt to defend a broken subsystem by "analogy" fails  
because last time
I checked the semantics of system calls like read/write/open/close  
didn't
change significantly between kernel version 1.0 and 2.6.15.

The number of system calls didn't change that much as well.

Yes it may be true that some aggregation of exhaustive crappy  
interfaces over time
in the kernel can be indeed observed. However the very fact which  
makes it remain
still usable are precisely those very "primitive" system calls -  
which are still
around and kicking.

Re: [OT] ALSA userspace API complexity

[Heikki Orsila]

On Thu, Jan 05, 2006 at 03:24:18PM +0100, Jaroslav Kysela wrote:
> On Thu, 5 Jan 2006, Heikki Orsila wrote:
> > 	err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate, frames_in_period /* 0 for automated default */ );
> 
> Well, it's better to create only "fast parameter setup" and "default error 
> recovery" functions.

And what would it look like? I would prefer all functions being 
alsa_simple_* because a user could read interface documentation 
alphabetically and see all the relevant functions as they are adjacent.

I would correct my earlier 'frames_in_period' to 'latency_in_frames' because
most users are not interested in period size. Latency on the other hand 
matters. 10ms latency would just be samplingrate / 100 and the ALSA lib 
would choose good approximate period/buffer sizes internally. Those who 
need something better should just use the old way.

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

Re: [OT] ALSA userspace API complexity

[Alistair John Strachan]

Firstly, trimming CCs is quite rude and makes it very difficult for others to 
address your problems.

On Thursday 05 January 2006 14:01, Heikki Orsila wrote:
> Alistair John Strachan <s0348365@sms.ed.ac.uk> wrote:
> > On Tuesday 03 January 2006 23:10, Tomasz K?oczko wrote:
> > 2) ALSA API is to complicated: most applications opens single sound
> >    stream.
> >
> > FUD and nonsense. I've written many DSP applications and very often I can
> > recycle the same code for use in them.
>
> It's not FUD and it's very true. I've written ALSA support for many
> programs and I still can't remember the tricks that are needed to get
> even basic things working.

They're not really tricks, they're allowing developers to flexibly handle 
cases that they may care about, such as momentary communication problems 
(think USB soundcards, headsets), versus unrecoverable errors. For example, 
the code I wrote handles your example below somewhat more easily:

	// try to play data
	for (i = 0; i < PLAYBACK_RETRIES; i++) {
		if ((err = snd_pcm_writei (card->playback.fd, card->buffer, card->frames)) < 
0) {
			adebug ("Had to re-init playback.\n");
			if ((err = snd_pcm_prepare (card->playback.fd)) < 0)
				return -PCM_PREPARATION_FAILED;
		}
		break;
	}

	// we couldn't reprepare
	if (i == PLAYBACK_RETRIES)
		return -PCM_WRITE_FAILED;

	return ALSA_SUCCESS;

PLAYBACK_RETRIES is arbitrary. Less robust software, or programs that were 
very sensitive to any sort of intermittent unavailability would error out 
immediately, without the for loop.

However, the documentation makes it fairly clear that in the case where a 
writei() fails, you must "re-prepare" the card for PCM IO. This can be 
attempted numerous times before giving up.

I agree that some sort of layman's wrapper might be helpful here, but please 
don't go back to the ways of a crippled OSS API by preventing us from 
handling these cases

> alsa_error_recovery() expands to 30 lines of more logic. This is pretty
> insane considering that libao _only_ writes data to device and does
> nothing else. If ALSA was done properly, the main loop would simply be:

This is ridiculous. Why bother? If libao is so simple, just break out if 
re-preparation fails.

>
>                 err = internal->writei(internal->pcm_handle, ptr, len);
>
>                 /* it's possible that no data was transferred */
>                 if (err == -EAGAIN || err == -EINTR) {
>                         continue;
>                 }
>
> 		if (err < 0) {
> 			/* BAD BAD */
> 		}

This looks suspiciously like what I have above. Clear, simple, non-broken. 
ALSA does it already.

> 	err = alsa_simple_pcm_open(nchannels, sampleformat, samplingrate,
> frames_in_period /* 0 for automated default */ ); err =
> alsa_simple_writei(); /* handless signal brokeness automagically */
> alsa_simple_close();

simple_{open,setup}() I agree with. There's no reason for that to have to be a 
whole stack of separate functions. Use return codes to indicate the type of 
failure.

simple_writei() might be okay, but it's pretty inflexible for even mildly 
complex problems requiring more than "just write data". The old mechanisms 
need to persist.

simple_close(), uhm.. snd_pcm_close (fd). Don't need it. I'm not sure why you 
think that is necessary.

-- 
Cheers,
Alistair.

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

Re: [OT] ALSA userspace API complexity

[linux]

hannu@opensound.com wrote:
> To get (say) 10 ms latencies you have to tell the sound subsystem 
> to allocate to buffer that is smaller than 10 ms. This in turn means that 
> the application must be able to run it's processing loop within less than 10 
> ms with 100.000...0% confidence. This is true regardless of how advanced 
> or primitive the audio subsystem (API) is.

Only if you need 10 ms latencies 100.000...0% of the time.  Which isn't
always the case.

The rest of the time, you can do very well by providing a way to supply
"tentative" data in advance of need, but cancel it and replace it with
better data when something happens... something explodes in a game, or
a new person speaks up in an audio conferencing application, or a new MIDI
event arrives.


Real-time DSP is a different matter, but the point I'm trying to make
is that there is a non-zero set of applications for which additional
API festures allow low average latency and guaranteed lack of total
dropouts.

Simply writing to /dev/dsp doesn't give you that, but e.g. DMA out of
user-space buffers does.

Re: [OT] ALSA userspace API complexity

[Hannu Savolainen]

On Sun, 8 Jan 2006 linux@horizon.com wrote:

> Only if you need 10 ms latencies 100.000...0% of the time.  Which isn't
> always the case.
If you are doing audio with 10 ms _buffers_ then you will need smaller 
than 10 ms latencies from the beginning to the end. This is always the 
case.

> The rest of the time, you can do very well by providing a way to supply
> "tentative" data in advance of need, but cancel it and replace it with
> better data when something happens... something explodes in a game, or
> a new person speaks up in an audio conferencing application, or a new MIDI
> event arrives.
You can't predict the future output if you are doing processing on live 
input and playing back the result immediately. In this kind of 
applications you are limited to the latencies the plattform can 
guarantee. There is nothing the audio subsystem can do to make things 
work better so for this reason any time spent on developing such features 
is complete waste of time.

Right. If you can predict what the output could be then you don't need to 
limit the the buffer to 10 ms. You can use much longer buffer and rewrite 
parts of it. 

In reality you can use surprisingly large buffers in applications like 
games and nobody will notice any lags. This is because human brain 
automatically masks them. As you know speed of sound is about 340 m/s. 
Largish delay of 0.1s=100ms equals to distance of 34 meters. This makes 
the distance to the explosion to sound like they occurred 34 meters behind
the actual place. 10 ms equals to just 3.4 meters.

Also in reality getting 10 ms "one way" latencies don't require any 
special tricking with DMA from user land or things like that. Simply using 
short enough buffer is enough. If the game itself is properly designed 
then 10-20ms will work out of box (at least with OSS). This approach has 
been used since the old sasteroids game 10-12 years ago and it's still 
used by the SDL library.

Using sophisticated algorithms that "cannot fail" may be sexy but it's 
pointless because nothing fails anyway.

Best regards,

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