Discussion:
[2.6 patch] schedule obsolete OSS drivers for removal
(too old to reply)
Adrian Bunk
2005-07-26 15:08:37 UTC
Permalink
This patch schedules obsolete OSS drivers (with ALSA drivers that
support the same hardware) for removal.


Signed-off-by: Adrian 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 <***@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 <***@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"

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jesper Juhl
2005-07-26 15:41:31 UTC
Permalink
Post by Adrian Bunk
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.
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
+
+---------------------------
+
--- 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 <***@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
Adrian Bunk
2005-07-26 15:46:45 UTC
Permalink
Post by Jesper Juhl
...
Post by Adrian Bunk
+ 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
Thomas Sailer
2005-07-26 15:41:52 UTC
Permalink
Post by Adrian Bunk
This patch schedules obsolete OSS drivers (with ALSA drivers that
support the same hardware) for removal.
Acked-by: Thomas Sailer <***@ife.ee.ethz.ch>
Jeff Garzik
2005-07-26 15:48:04 UTC
Permalink
Post by Adrian Bunk
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.
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



-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2005-07-26 16:04:20 UTC
Permalink
Post by Jeff Garzik
Post by Adrian Bunk
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.
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).
Post by Jeff Garzik
ACK for via82cxxx.
Thanks.
Post by Jeff Garzik
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?
Post by Jeff Garzik
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Lee Revell
2005-07-26 16:49:46 UTC
Permalink
Post by Jeff Garzik
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
John W. Linville
2005-07-26 17:49:33 UTC
Permalink
Post by Lee Revell
Post by Jeff Garzik
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
***@tuxdriver.com
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Gene Heskett
2005-07-26 17:03:39 UTC
Permalink
Post by Jeff Garzik
Post by Adrian Bunk
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.
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. :)
Post by Jeff Garzik
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
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.
Adrian Bunk
2005-07-26 18:13:26 UTC
Permalink
Post by Gene Heskett
Post by Jeff Garzik
Post by Adrian Bunk
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.
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?
Post by Gene Heskett
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
Gene Heskett
2005-07-27 03:19:35 UTC
Permalink
Post by Adrian Bunk
Post by Gene Heskett
Post by Jeff Garzik
Post by Adrian Bunk
This patch schedules obsolete OSS drivers (with ALSA drivers
that support the same hardware) for removal.
[...]
Post by Adrian Bunk
Post by Gene Heskett
Post by Jeff Garzik
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.
Lee Revell
2005-07-26 15:51:13 UTC
Permalink
Post by Adrian Bunk
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff Garzik
2005-07-26 15:57:04 UTC
Permalink
Post by Lee Revell
Post by Adrian Bunk
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.


-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Lee Revell
2005-07-26 16:02:56 UTC
Permalink
Post by Jeff Garzik
Post by Lee Revell
Post by Adrian Bunk
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
Adrian Bunk
2005-07-27 18:24:28 UTC
Permalink
Post by Jeff Garzik
Post by Lee Revell
Post by Adrian Bunk
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
John W. Linville
2005-07-27 20:31:52 UTC
Permalink
Post by Adrian Bunk
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
***@tuxdriver.com
Jeff Garzik
2005-07-27 20:43:37 UTC
Permalink
Post by John W. Linville
Post by Adrian Bunk
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
Alan Cox
2005-07-28 14:00:08 UTC
Permalink
Post by Jeff Garzik
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 ?
Jaroslav Kysela
2005-07-28 13:43:49 UTC
Permalink
Post by Alan Cox
Post by Jeff Garzik
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 <***@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2005-07-28 14:15:21 UTC
Permalink
Post by Jaroslav Kysela
Post by Alan Cox
Post by Jeff Garzik
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.
Post by Jaroslav Kysela
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2006-01-03 13:14:06 UTC
Permalink
Post by Jaroslav Kysela
Post by Alan Cox
Post by Jeff Garzik
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?
Post by Jaroslav Kysela
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
Adrian Bunk
2005-07-26 16:30:13 UTC
Permalink
Post by Lee Revell
Post by Adrian Bunk
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.
Post by Lee Revell
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrew Haninger
2005-07-26 16:17:14 UTC
Permalink
Post by Adrian Bunk
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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2005-07-31 19:29:29 UTC
Permalink
Post by Andrew Haninger
Post by Adrian Bunk
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]?
Post by Andrew Haninger
-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
Zach Brown
2005-07-26 16:27:07 UTC
Permalink
Post by Adrian Bunk
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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Krzysztof Halasa
2005-07-26 21:41:15 UTC
Permalink
Post by Zach Brown
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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Zoran Dzelajlija
2005-07-26 23:38:37 UTC
Permalink
Post by Zach Brown
Post by Adrian Bunk
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
Lee Revell
2005-07-27 23:28:39 UTC
Permalink
Post by Zoran Dzelajlija
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Rogério Brito
2005-07-27 23:58:19 UTC
Permalink
Post by Lee Revell
Post by Zoran Dzelajlija
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.
=20
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=E9rio.

--=20
Rog=E9rio Brito : ***@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/
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Takashi Iwai
2005-07-28 08:09:19 UTC
Permalink
At Wed, 27 Jul 2005 01:38:37 +0200,
Post by Zoran Dzelajlija
Post by Zach Brown
Post by Adrian Bunk
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
Adrian Bunk
2005-07-31 19:36:54 UTC
Permalink
Post by Zoran Dzelajlija
Post by Zach Brown
Post by Adrian Bunk
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.
Post by Zoran Dzelajlija
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Kyle McMartin
2005-07-27 18:39:42 UTC
Permalink
Post by Adrian Bunk
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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Randolph Chung
2005-07-28 03:01:34 UTC
Permalink
Post by Kyle McMartin
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2005-07-28 14:14:19 UTC
Permalink
Post by Kyle McMartin
Post by Adrian Bunk
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.
Post by Kyle McMartin
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thorsten Knabe
2005-07-28 15:04:20 UTC
Permalink
Post by Adrian Bunk
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: ***@thorsten-knabe.de
|horsten |/\nabe WWW: http://linux.thorsten-knabe.de
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2005-07-28 15:46:19 UTC
Permalink
Post by Thorsten Knabe
Post by Adrian Bunk
This patch schedules obsolete OSS drivers (with ALSA drivers that
support the same hardware) for removal.
Hello Adrian.
Hi Thorsten,
Post by Thorsten Knabe
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
- 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.
Post by Thorsten Knabe
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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Lee Revell
2005-07-28 18:33:26 UTC
Permalink
Post by Thorsten Knabe
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
- 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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Jaroslav Kysela
2005-07-29 06:52:45 UTC
Permalink
Post by Thorsten Knabe
Post by Adrian Bunk
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
- 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 <***@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2005-07-29 15:16:16 UTC
Permalink
Post by Jaroslav Kysela
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.
Post by Jaroslav Kysela
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thorsten Knabe
2005-07-29 15:58:18 UTC
Permalink
Post by Jaroslav Kysela
Post by Thorsten Knabe
Post by Adrian Bunk
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
- 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: ***@thorsten-knabe.de
|horsten |/\nabe WWW: http://linux.thorsten-knabe.de
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2005-07-31 19:39:22 UTC
Permalink
Post by Thorsten Knabe
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?
Post by Thorsten Knabe
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andrew Haninger
2005-08-01 14:26:02 UTC
Permalink
Post by Adrian Bunk
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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thorsten Knabe
2005-08-02 15:55:12 UTC
Permalink
Hello.

Here are the bug id's for the various issues from the ALSA bugtracking
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: ***@thorsten-knabe.de
|horsten |/\nabe WWW: http://linux.thorsten-knabe.de


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
James Courtier-Dutton
2005-07-31 13:38:34 UTC
Permalink
Post by Adrian Bunk
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 am happy for the emu10k1 OSS driver to go.
The ALSA driver has considerably more features now.

James
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andi Kleen
2006-01-03 13:21:34 UTC
Permalink
Post by Adrian Bunk
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
I object to the ICH driver being scheduler for removal. It works
fine and is a significantly less bloated than the equivalent ALSA setup.

This means ac97_codec.c also has to stay.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alistair John Strachan
2006-01-03 13:47:19 UTC
Permalink
Post by Andi Kleen
Post by Adrian Bunk
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
+What: drivers depending on OBSOLETE_OSS_DRIVER
+When: October 2005
+Why: OSS drivers with ALSA replacements
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Andi Kleen
2006-01-03 13:52:09 UTC
Permalink
Post by Alistair John Strachan
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.
Post by Alistair John Strachan
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.
Post by Alistair John Strachan
Even if Adrian's not trying to make this point (he's just removing duplicate
drivers, and opting for the newer ones), we accepted ALSA into the kernel.
It's probably about time we let OSS die properly, for sanity purposes.
Avoiding bloat is more important.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alistair John Strachan
2006-01-03 14:01:40 UTC
Permalink
Post by Andi Kleen
Post by Alistair John Strachan
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.
Post by Andi Kleen
Post by Alistair John Strachan
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.
Post by Andi Kleen
Post by Alistair John Strachan
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Lang
2006-01-03 13:58:23 UTC
Permalink
Post by Andi Kleen
Post by Alistair John Strachan
Even if Adrian's not trying to make this point (he's just removing duplicate
drivers, and opting for the newer ones), we accepted ALSA into the kernel.
It's probably about time we let OSS die properly, for sanity purposes.
Avoiding bloat is more important.
given that the ALSA drivers are not going to be removed, isn't it bloat to
have two drivers for the same card?

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

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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alistair John Strachan
2006-01-03 14:33:03 UTC
Permalink
Post by David Lang
Post by Andi Kleen
Post by Alistair John Strachan
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..).
Post by David Lang
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alistair John Strachan
2006-01-03 14:34:54 UTC
Permalink
Post by Alistair John Strachan
Post by David Lang
Post by Andi Kleen
Post by Alistair John Strachan
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..).
Post by David Lang
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Lee Revell
2006-01-03 18:24:37 UTC
Permalink
Post by Andi Kleen
Post by Alistair John Strachan
It strikes me that it's a bit of a chicken and egg problem. Vendors are still
releasing applications on Linux that support only OSS, partly due to
ignorance, but mostly because ALSA's OSS compatibility layer allows them to
lazily ignore the ALSA API and target all cards, old and new.
As long as it works why is that a bad thing? OSS API works just fine
for most sound needs. If you want to do high end sound you can still
use ALSA.
OSS can't do software mixing of multiple audio streams, it requires a
sound server to do this. So IMHO the OSS approach causes more bloat on
the desktop.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pete Zaitcev
2006-01-04 11:13:00 UTC
Permalink
Post by Alistair John Strachan
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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jaroslav Kysela
2006-01-04 11:16:18 UTC
Permalink
Post by Pete Zaitcev
Post by Alistair John Strachan
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 <***@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jan Engelhardt
2006-01-03 14:38:09 UTC
Permalink
Post by Alistair John Strachan
It strikes me that it's a bit of a chicken and egg problem. Vendors are still
releasing applications on Linux that support only OSS, partly due to
ignorance, but mostly because ALSA's OSS compatibility layer allows them to
lazily ignore the ALSA API and target all cards, old and new.
Additionally, we can't get rid of OSS compatibility until pretty much all
hardware has an ALSA driver, and (inferred from your comment) we can't get
rid of OSS drivers until nothing supports OSS, because the whole of the ALSA
stuff is a bit larger...
By OSS compatibility, do you mean the OSS PCM emulation layer (/dev/dsp)? I
think that should be kept. That way, legacy apps keep working, especially
unmaintained binary-only things like Unreal Tournament 1.

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


Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alistair John Strachan
2006-01-03 14:41:27 UTC
Permalink
Post by Jan Engelhardt
Post by Alistair John Strachan
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jan Engelhardt
2006-01-03 14:50:12 UTC
Permalink
Post by Alistair John Strachan
The problem with using OSS compatibility, at least on this machine with ALSA
1.0.9, is that if you use it you automatically lose the software mixing
capabilities of ALSA, so it really is less than ideal.
Well, I am able to open /dev/dsp multiple times here without problems.
(Is /dev/dsp soft- or hardmixing?)



Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alistair John Strachan
2006-01-03 15:22:06 UTC
Permalink
Post by Jan Engelhardt
Post by Alistair John Strachan
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz Torcz
2006-01-03 16:05:02 UTC
Permalink
Post by Alistair John Strachan
Post by Jan Engelhardt
Post by Alistair John Strachan
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
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
***@irc.-nie.spam-.pl in the afternoon and evening." - Alan Cox
Alistair John Strachan
2006-01-03 16:29:21 UTC
Permalink
On Tuesday 03 January 2006 16:05, Tomasz Torcz wrote:
[snip]
Post by Tomasz Torcz
Post by Alistair John Strachan
[alistair] 15:20 [~/Music/Led Zeppelin - I] ogg123 -q --device=oss 01\ -\
Good\ Times\ Bad\ Times.ogg
Error: Cannot open device oss.
aoss ogg123 -q --device=oss [...]
I'm aware of this.

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

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

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Olivier Galibert
2006-01-03 17:03:16 UTC
Permalink
Post by Alistair John Strachan
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?
Post by Alistair John Strachan
This is exactly why the OSS emulation option in ALSA is really a last resort
and should not be an excuse for people to ignore implementing ALSA support
directly. More so, it is very good justification for ditching "everything
OSS" as soon as possible, at least in new software.
Actually the crappy state of OSS emulation is a good reason to ditch
ALSA in its current implementation. As Linus reminded not so long
ago, backwards compatibility is extremely important.

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

OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alistair John Strachan
2006-01-03 17:16:13 UTC
Permalink
Post by Olivier Galibert
Post by Alistair John Strachan
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.
Post by Olivier Galibert
Post by Alistair John Strachan
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.
Post by Olivier Galibert
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Olivier Galibert
2006-01-03 19:24:49 UTC
Permalink
Post by Alistair John Strachan
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.
Post by Alistair John Strachan
Post by Olivier Galibert
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2006-01-03 19:37:36 UTC
Permalink
Post by Olivier Galibert
Post by Alistair John Strachan
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_.
Post by Olivier Galibert
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.
Post by Olivier Galibert
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Olivier Galibert
2006-01-03 21:40:18 UTC
Permalink
Post by Adrian Bunk
The udev breakages might not have been nice, but OSS/ALSA is a
OSS has been deprecated since ALSA was merged into the Linux kernel
_four years ago_.
OSS _drivers_ yes, OSS _api_ no.
Post by Adrian Bunk
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.
Post by Adrian Bunk
For a general OSS<->ALSA discussion, you are five years too late.
I couldn't predict 5 years ago that the ALSA API quality would be
somewhat lacking.

OG.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz Kłoczko
2006-01-03 23:10:13 UTC
Permalink
Post by Adrian Bunk
Post by Olivier Galibert
Post by Alistair John Strachan
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
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: ***@rudy.mif.pg.gda.pl*
Thomas Sailer
2006-01-04 00:33:27 UTC
Permalink
1) ALSA API forces not use devices files and many things on sound man=
aging
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
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 callin=
g
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


-
To unsubscribe from this list: send the line "unsubscribe linux-sound" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Olivier Galibert
2006-01-04 01:48:15 UTC
Permalink
Post by Thomas Sailer
Post by Tomasz Kłoczko
1) ALSA API forces not use devices files and many things on sound managing
level are handled on user space library. This dissallow civilized
Huh? Why's that? Actually, I welcome that ALSA does quite a lot in
userspace, it could even do more. The whole format conversion and
sampling rate conversion has no business in the kernel, IMO.
Doing things in userspace does not necessarily mean doing them in a
library, especially when it is required that the library be shared,
also known as "things _will_ break".

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

OG.

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jan Engelhardt
2006-01-04 09:03:12 UTC
Permalink
Post by Tomasz Kłoczko
2) ALSA API is to complicated: most applications opens single sound
stream.
Seconded.
Post by Tomasz Kłoczko
3) ALSA kernel architecture is to complicated. This main reason why
# 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".
Post by Tomasz Kłoczko
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.
Post by Tomasz Kłoczko
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.
Post by Tomasz Kłoczko
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
--
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Alistair John Strachan
2006-01-04 09:37:55 UTC
Permalink
On Tuesday 03 January 2006 23:10, Tomasz K=C5=82oczko wrote:
[snip]
Post by Tomasz Kłoczko
2) ALSA API is to complicated: most applications opens single sound
stream.
=46UD and nonsense. I've written many DSP applications and very often I=
can=20
recycle the same code for use in them. Here's an example, abstracted,=20
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 thin=
gs OSS=20
either can't handle or doesn't allow you to configure. Things that very=
often=20
an application will eventually care about. All this for the sake of 5 m=
inutes=20
reading documentation, and each API call almost identical in design.

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

--=20
Cheers,
Alistair.

'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pete Zaitcev
2006-01-04 11:00:34 UTC
Permalink
Post by Tomasz Kłoczko
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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jaroslav Kysela
2006-01-04 11:35:25 UTC
Permalink
Post by Pete Zaitcev
Post by Tomasz Kłoczko
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
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 <***@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pete Zaitcev
2006-01-04 11:47:52 UTC
Permalink
[...] 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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Lee Revell
2006-01-03 18:28:20 UTC
Permalink
Post by Olivier Galibert
Post by Alistair John Strachan
This has nothing to do with the kernel option CONFIG_SND_OSSEMUL which Jan
referred to, and to which I was responding. "aoss" is also not compatible
with every conceivable program.
Especially not with plugins. Flashplayer anybody?
Yes it's a known issue that the aoss emulation is not perfect, it's not
a reason to ditch ALSA, it's a reason to fix it.

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

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Thomas Sailer
2006-01-03 19:30:40 UTC
Permalink
Post by Lee Revell
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
Jaroslav Kysela
2006-01-03 19:37:16 UTC
Permalink
Post by Thomas Sailer
Post by Lee Revell
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 <***@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
Thomas Sailer
2006-01-03 19:56:26 UTC
Permalink
Post by Jaroslav Kysela
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.
Jaroslav Kysela
2006-01-03 20:06:06 UTC
Permalink
Post by Thomas Sailer
Post by Jaroslav Kysela
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 <***@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
Thomas Sailer
2006-01-04 00:23:24 UTC
Permalink
Post by Jaroslav Kysela
The "plugin" (or rather conversion, routing and resampling) system in the
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
James Courtier-Dutton
2006-01-03 22:39:03 UTC
Permalink
Post by Thomas Sailer
Post by Jaroslav Kysela
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
Takashi Iwai
2006-01-03 20:22:58 UTC
Permalink
At Tue, 3 Jan 2006 18:03:16 +0100,
Post by Olivier Galibert
Post by Alistair John Strachan
This is exactly why the OSS emulation option in ALSA is really a last resort
and should not be an excuse for people to ignore implementing ALSA support
directly. More so, it is very good justification for ditching "everything
OSS" as soon as possible, at least in new software.
Actually the crappy state of OSS emulation is a good reason to ditch
ALSA in its current implementation. As Linus reminded not so long
ago, backwards compatibility is extremely important.
Well, we keep the compatibility exactly -- OSS drivers don't support
software mixing in the kernel, too :)


Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz Torcz
2006-01-03 20:37:32 UTC
Permalink
Post by Takashi Iwai
At Tue, 3 Jan 2006 18:03:16 +0100,
Post by Olivier Galibert
Post by Alistair John Strachan
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:
***@irc.-nie.spam-.pl one blends softly casual into the other.
Takashi Iwai
2006-01-03 20:44:49 UTC
Permalink
At Tue, 3 Jan 2006 21:37:32 +0100,
Post by Tomasz Torcz
Post by Takashi Iwai
At Tue, 3 Jan 2006 18:03:16 +0100,
Post by Olivier Galibert
Post by Alistair John Strachan
This is exactly why the OSS emulation option in ALSA is really a last resort
and should not be an excuse for people to ignore implementing ALSA support
directly. More so, it is very good justification for ditching "everything
OSS" as soon as possible, at least in new software.
Actually the crappy state of OSS emulation is a good reason to ditch
ALSA in its current implementation. As Linus reminded not so long
ago, backwards compatibility is extremely important.
Well, we keep the compatibility exactly -- OSS drivers don't support
software mixing in the kernel, too :)
OSS will support software mixing. In kernel. On NetBSD.
http://kerneltrap.org/node/4388
Why do we need to keep the compatibility with NetBSD?


Takashi
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jesper Juhl
2006-01-03 20:56:20 UTC
Permalink
Post by Takashi Iwai
At Tue, 3 Jan 2006 21:37:32 +0100,
Post by Tomasz Torcz
Post by Takashi Iwai
At Tue, 3 Jan 2006 18:03:16 +0100,
Post by Olivier Galibert
Post by Alistair John Strachan
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 <***@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Adrian Bunk
2006-01-03 21:56:54 UTC
Permalink
Post by Jesper Juhl
Post by Takashi Iwai
At Tue, 3 Jan 2006 21:37:32 +0100,
Post by Tomasz Torcz
Post by Takashi Iwai
At Tue, 3 Jan 2006 18:03:16 +0100,
Post by Olivier Galibert
Post by Alistair John Strachan
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.
Post by Jesper Juhl
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jesper Juhl
2006-01-03 22:11:47 UTC
Permalink
Post by Adrian Bunk
Post by Jesper Juhl
Post by Takashi Iwai
At Tue, 3 Jan 2006 21:37:32 +0100,
Post by Tomasz Torcz
Post by Takashi Iwai
At Tue, 3 Jan 2006 18:03:16 +0100,
Post by Olivier Galibert
Post by Alistair John Strachan
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 <***@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Takashi Iwai
2006-01-04 11:46:00 UTC
Permalink
At Tue, 3 Jan 2006 23:11:47 +0100,
Post by Jesper Juhl
Post by Adrian Bunk
Post by Jesper Juhl
Post by Takashi Iwai
At Tue, 3 Jan 2006 21:37:32 +0100,
Post by Tomasz Torcz
Post by Takashi Iwai
At Tue, 3 Jan 2006 18:03:16 +0100,
Post by Olivier Galibert
Post by Alistair John Strachan
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
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz Torcz
2006-01-03 22:13:14 UTC
Permalink
Post by Adrian Bunk
Post by Jesper Juhl
Post by Takashi Iwai
Post by Tomasz Torcz
Post by Takashi Iwai
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:
***@irc.-nie.spam-.pl one blends softly casual into the other.
Adrian Bunk
2006-01-03 23:10:09 UTC
Permalink
Post by Tomasz Torcz
Post by Adrian Bunk
Post by Jesper Juhl
Post by Takashi Iwai
Post by Tomasz Torcz
Post by Takashi Iwai
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz Kłoczko
2006-01-03 23:51:52 UTC
Permalink
On Wed, 4 Jan 2006, Adrian Bunk wrote:
[..]
Post by Adrian Bunk
Post by Tomasz Torcz
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: ***@rudy.mif.pg.gda.pl*
Adrian Bunk
2006-01-04 00:03:44 UTC
Permalink
Post by Tomasz Kłoczko
[..]
Post by Adrian Bunk
Post by Tomasz Torcz
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.
Post by Tomasz Kłoczko
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz Kłoczko
2006-01-04 00:46:08 UTC
Permalink
On Wed, 4 Jan 2006, Adrian Bunk wrote:
[..]
Post by Adrian Bunk
Post by Tomasz Kłoczko
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: ***@rudy.mif.pg.gda.pl*
Adrian Bunk
2006-01-04 01:01:23 UTC
Permalink
Post by Tomasz Kłoczko
[..]
Post by Adrian Bunk
Post by Tomasz Kłoczko
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?
Post by Tomasz Kłoczko
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.
Post by Tomasz Kłoczko
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

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Tomasz Kłoczko
2006-01-04 02:51:09 UTC
Permalink
Post by Adrian Bunk
Post by Tomasz Kłoczko
[..]
Post by Adrian Bunk
Post by Tomasz Kłoczko
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.
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: ***@rudy.mif.pg.gda.pl*
Alan Cox
2006-01-04 08:50:34 UTC
Permalink
Be compliant with OSS specyfication allow save many time on applicati=
ons=20
development level by consume (in good sense) time spend on this=20
applications by *BSD, Solaris and other systems developers (even on n=
ot=20
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 ..=
=20
remember: sound support in Linux isn't for data centers/big-ass-machi=
nes :)

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

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-sound" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
tapas
2006-01-04 10:37:26 UTC
Permalink
On Wed, 4 Jan 2006 03:51:09 +0100 (CET)
After four years ALSA development quality of sound support in Linux i=
s IMO=20
on the ~same (still bad) level as four years ago. Still to complicate=
d=20
but now more bloated and additionaly not ready for handle fancy gadge=
ts=20
like BT headsets.
Hi,

i want to chime in here in the defense of ALSA. ALSA is vastly superiou=
r
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 setu=
p
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:=20

-- many apps still use the ALSA api wrongly due to the complex nature o=
f
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 o=
f
a technical nature, which is too much for joe user.=20

- 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 provid=
e
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
=46USE 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.=20

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 i=
s now=20
better than four years ago. IMO this allow form conclution: generaly=20
current ALSA is step back compare to other systems and probaly Linux =
need=20
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,
=46lorian Schmidt
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" =
in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Stefan Smietanowski
2006-01-04 00:28:48 UTC
Permalink
Post by Tomasz Kłoczko
[..]
Post by Adrian Bunk
Post by Tomasz Torcz
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
Tomasz Kłoczko
2006-01-04 01:38:49 UTC
Permalink
On Wed, 4 Jan 2006, Stefan Smietanowski wrote:
[..]
Post by Stefan Smietanowski
Post by Tomasz Kłoczko
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: ***@rudy.mif.pg.gda.pl*
Stefan Smietanowski
2006-01-04 09:48:59 UTC
Permalink
Post by Tomasz Kłoczko
[..]
Post by Stefan Smietanowski
Post by Tomasz Kłoczko
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
Jan Engelhardt
2006-01-03 17:09:14 UTC
Permalink
Post by Alistair John Strachan
Post by 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
ogg123 -q --device=oss 01\ -\ Good\ Times\ Bad\ Times.ogg
Error: Cannot open device oss
Oh well this does work for me.
Post by Alistair John Strachan
This is all a little OT for this thread, but it's certainly the case with
alsa-lib-1.0.10 on 2.6.15-rc7. My card isn't capable of hardware mixing,
yours might be (SBLive!/Audigy or something).
CS46XX. According to alsamixer info, it has 31 playback and 1 record channel.
Looks like I'm in favor of hardware mixing.

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


Jan Engelhardt
--
-
To unsubscribe from this list: send the line "unsubscribe linux-sound" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Continue reading on narkive:
Loading...