[2.6 patch] schedule obsolete OSS drivers for removal
Adrian Bunk
support the same hardware) for removal.
Signed-off-by: Adrian Bunk <bu...@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 <bu...@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 <bu...@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-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Jesper Juhl
s/patch/option/ ???
--
Jesper Juhl <jespe...@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
Thomas Sailer
> This patch schedules obsolete OSS drivers (with ALSA drivers that
> support the same hardware) for removal.
>
>
> Signed-off-by: Adrian Bunk <bu...@stusta.de>
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
Lee Revell
> support the same hardware) for removal.
How many non-obsolete OSS drivers were there?
Lee
Jeff Garzik
> On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
>
>>This patch schedules obsolete OSS drivers (with ALSA drivers that
>>support the same hardware) for removal.
>
>
> How many non-obsolete OSS drivers were there?
someone needs to test the remaining PCI ID(s) that are in i810_audio but
not ALSA.
Lee Revell
> Lee Revell wrote:
> > On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
> >
> >>This patch schedules obsolete OSS drivers (with ALSA drivers that
> >>support the same hardware) for removal.
> >
> >
> > How many non-obsolete OSS drivers were there?
>
> someone needs to test the remaining PCI ID(s) that are in i810_audio but
> not ALSA.
>
Good luck finding someone with all that old hardware...
Lee
Adrian Bunk
> Adrian Bunk wrote:
> >This patch schedules obsolete OSS drivers (with ALSA drivers that
> >support the same hardware) for removal.
> >
> >
> >
> >---
> >
> >I've Cc'ed the people listed in MAINTAINERS as being responsible for one
> >or more of these drivers, and I've also Cc'ed the ALSA people.
> >
> >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(-)
>
I did (but I don't claim that I didn't miss anything).
> ACK for via82cxxx.
Thanks.
> NAK for i810_audio: ALSA doesn't have all the PCI IDs (which must be
> verified -- you cannot just add the PCI IDs for some hardware)
I though I found every single PCI ID from this driver in ALSA.
Which PCI IDs did I miss?
> Jeff
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Andrew Haninger
> 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
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
Zach Brown
> 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
Adrian Bunk
> On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
> > This patch schedules obsolete OSS drivers (with ALSA drivers that
> > support the same hardware) for removal.
>
> How many non-obsolete OSS drivers were there?
I haven't counted them, but there are still many.
> Lee
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Jeff Garzik
> This patch schedules obsolete OSS drivers (with ALSA drivers that
> support the same hardware) for removal.
>
>
> Signed-off-by: Adrian Bunk <bu...@stusta.de>
>
> ---
>
> I've Cc'ed the people listed in MAINTAINERS as being responsible for one
> or more of these drivers, and I've also Cc'ed the ALSA people.
>
> Please tell if any my driver selections is wrong.
>
> Documentation/feature-removal-schedule.txt | 7 +
> sound/oss/Kconfig | 79 ++++++++++++---------
> 2 files changed, 54 insertions(+), 32 deletions(-)
Please CHECK before doing this.
ACK for via82cxxx.
NAK for i810_audio: ALSA doesn't have all the PCI IDs (which must be
verified -- you cannot just add the PCI IDs for some hardware)
Jeff
Lee Revell
> 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
Gene Heskett
>Adrian Bunk wrote:
>> This patch schedules obsolete OSS drivers (with ALSA drivers that
>> support the same hardware) for removal.
>>
>>
>> Signed-off-by: Adrian Bunk <bu...@stusta.de>
>>
>> ---
>>
>> I've Cc'ed the people listed in MAINTAINERS as being responsible
>> for one or more of these drivers, and I've also Cc'ed the ALSA
>> people.
>>
>> Please tell if any my driver selections is wrong.
>>
>> Documentation/feature-removal-schedule.txt | 7 +
>> sound/oss/Kconfig | 79
>> ++++++++++++--------- 2 files changed, 54 insertions(+), 32
>> deletions(-)
>
>Please CHECK before doing this.
>
>ACK for via82cxxx.
I'm still running a box that needs this one. The darned thing refuses
to die. :)
>NAK for i810_audio: ALSA doesn't have all the PCI IDs (which must
> be verified -- you cannot just add the PCI IDs for some hardware)
>
> Jeff
>
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to majo...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
John W. Linville
> On Tue, 2005-07-26 at 11:48 -0400, Jeff Garzik wrote:
> > NAK for i810_audio: ALSA doesn't have all the PCI IDs (which must be
> > verified -- you cannot just add the PCI IDs for some hardware)
>
> Some of them might be in snd-hda-intel in addition to snd-intel8x0.
Hmmm...I don't think that would work. If there are IDs listed in
both i810_audio and snd-hda-intel, it is probably a mistake.
John
--
John W. Linville
linv...@tuxdriver.com
Adrian Bunk
> On Tuesday 26 July 2005 11:48, Jeff Garzik wrote:
> >Adrian Bunk wrote:
> >> This patch schedules obsolete OSS drivers (with ALSA drivers that
> >> support the same hardware) for removal.
> >>
> >>
> >> Signed-off-by: Adrian Bunk <bu...@stusta.de>
> >>
> >> ---
> >>
> >> I've Cc'ed the people listed in MAINTAINERS as being responsible
> >> for one or more of these drivers, and I've also Cc'ed the ALSA
> >> people.
> >>
> >> Please tell if any my driver selections is wrong.
> >>
> >> Documentation/feature-removal-schedule.txt | 7 +
> >> sound/oss/Kconfig | 79
> >> ++++++++++++--------- 2 files changed, 54 insertions(+), 32
> >> deletions(-)
> >
> >Please CHECK before doing this.
> >
> >ACK for via82cxxx.
>
> I'm still running a box that needs this one. The darned thing refuses
> to die. :)
Why doesn't the ALSA driver work for you?
> Cheers, Gene
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Krzysztof Halasa
> 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
Gene Heskett
>On Tue, Jul 26, 2005 at 01:03:39PM -0400, Gene Heskett wrote:
>> On Tuesday 26 July 2005 11:48, Jeff Garzik wrote:
>> >Adrian Bunk wrote:
>> >> This patch schedules obsolete OSS drivers (with ALSA drivers
>> >> that support the same hardware) for removal.
>> >ACK for via82cxxx.
>>
>> I'm still running a box that needs this one. The darned thing
>> refuses to die. :)
>>...
>
>Why doesn't the ALSA driver work for you?
Humm, I missread that it was OSS you were talking about, my bad.
I'll go quietly officer. :(
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.35% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Zoran Dzelajlija
> Adrian Bunk wrote:
> > This patch schedules obsolete OSS drivers (with ALSA drivers that
> > support the same hardware) for removal.
> > I've Cc'ed the people listed in MAINTAINERS as being responsible for one
> > or more of these drivers, and I've also Cc'ed the ALSA people.
> I haven't touched the maestro drivers in so long (for near-total lack of
> docs, etc.) that I can't be considered authoritative for approving it's
> removal. If people are relying on it I certainly don't know who they
> are. In better news, Takashi should now have the pile of maestro
> hardware that I used in the first pass to help him maintain the ALSA
> driver..
The OSS maestro driver works better on my old Armada E500 laptop. I tried
ALSA after switching to 2.6, but the computer hung with 2.6.8.1 or 2.6.10 if
I touched the volume buttons. With OSS they just work. The four separate
dsp devices also look kind of more useful.
Zoran
Kyle McMartin
> 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
Adrian Bunk
> Lee Revell wrote:
> >On Tue, 2005-07-26 at 17:08 +0200, Adrian Bunk wrote:
> >
> >>This patch schedules obsolete OSS drivers (with ALSA drivers that
> >>support the same hardware) for removal.
> >
> >
> >How many non-obsolete OSS drivers were there?
>
> someone needs to test the remaining PCI ID(s) that are in i810_audio but
> not ALSA.
I've grep'ed a second time for every single PCI ID in the OSS
i810_audio, and I still haven't found WTF you are talking about.
Once again my question:
I though I found every single PCI ID from this driver in ALSA.
Which PCI IDs did I miss?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
John W. Linville
> 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
linv...@tuxdriver.com
Jeff Garzik
> On Wed, Jul 27, 2005 at 08:24:28PM +0200, Adrian Bunk wrote:
>
>
>>I've grep'ed a second time for every single PCI ID in the OSS
>>i810_audio, and I still haven't found WTF you are talking about.
>
>
> I looked as well, and I found nothing either.
>
> Jeff, can you enlighten us?
ISTR Alan saying there was some ALi hardware that either wasn't in ALSA,
or most likely didn't work in ALSA. If Alan says I'm smoking crack,
then you all can ignore me :)
Jeff
Lee Revell
> 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
RogérioBrito
> On Wed, 2005-07-27 at 01:38 +0200, Zoran Dzelajlija wrote:
> > The OSS maestro driver works better on my old Armada E500 laptop.
> > I tried ALSA after switching to 2.6, but the computer hung with
> > 2.6.8.1 or 2.6.10 if I touched the volume buttons.
>
> Please test a newer ALSA version, like the one in 2.6.12.
I have an Armada V300 laptop that uses the maestro2 chipset (and I
wouldn't be surprised if your E500 used that very same chip) and it
works fine with the ALSA provided in kernels since the 2.6.10-mm era
(actually, I think it worked fine with even earlier kernels, but I am
not sure).
Just another datapoint, Rogério.
--
Rogério Brito : rbr...@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/
Randolph Chung
>
> 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
Takashi Iwai
Zoran Dzelajlija wrote:
>
> Zach Brown <z...@zabbo.net> wrote:
> > Adrian Bunk wrote:
> > > This patch schedules obsolete OSS drivers (with ALSA drivers that
> > > support the same hardware) for removal.
>
> > > I've Cc'ed the people listed in MAINTAINERS as being responsible for one
> > > or more of these drivers, and I've also Cc'ed the ALSA people.
>
> > I haven't touched the maestro drivers in so long (for near-total lack of
> > docs, etc.) that I can't be considered authoritative for approving it's
> > removal. If people are relying on it I certainly don't know who they
> > are. In better news, Takashi should now have the pile of maestro
> > hardware that I used in the first pass to help him maintain the ALSA
> > driver..
>
> The OSS maestro driver works better on my old Armada E500 laptop. I tried
> ALSA after switching to 2.6, but the computer hung with 2.6.8.1 or 2.6.10 if
> I touched the volume buttons. With OSS they just work. The four separate
> dsp devices also look kind of more useful.
The bug around h/w volume control should have been fixed in the recent
version of ALSA drivers. Hopefully everything will get merged into
2.6.13...
Takashi
Alan Cox
> 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
> On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
> > ISTR Alan saying there was some ALi hardware that either wasn't in ALSA,
> > or most likely didn't work in ALSA. If Alan says I'm smoking crack,
> > then you all can ignore me :)
>
> The only big thing I know that still needed OSS (and may still do so) is
> the support for AC97 wired touchscreens and the like. Has that been
> ported to ALSA ?
We're working on this issue right now.
Jaroslav
-----
Jaroslav Kysela <pe...@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
Adrian Bunk
> On Thu, 28 Jul 2005, Alan Cox wrote:
>
> > On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
> > > ISTR Alan saying there was some ALi hardware that either wasn't in ALSA,
> > > or most likely didn't work in ALSA. If Alan says I'm smoking crack,
> > > then you all can ignore me :)
> >
> > The only big thing I know that still needed OSS (and may still do so) is
> > the support for AC97 wired touchscreens and the like. Has that been
> > ported to ALSA ?
>
> We're working on this issue right now.
Does "right now" mean it will be done in a few days or a few months?
I'm asking because in the latter case I'll remove the driver from my
current "scheduled for removal" list.
> Jaroslav
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Thorsten Knabe
> 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: li...@thorsten-knabe.de
|horsten |/\nabe WWW: http://linux.thorsten-knabe.de
Adrian Bunk
> On Tue, Jul 26, 2005 at 05:08:37PM +0200, Adrian Bunk wrote:
> > This patch schedules obsolete OSS drivers (with ALSA drivers that
> > support the same hardware) for removal.
>
> oss/harmony.c can probably go, unless someone from parisc-linux
> objects. I've written a (working) replacement[1] for oss/ad1889.c
> which is in our cvs, and will go upstream shortly. oss/ad1889.c
> doesn't (and hasn't ever) worked, so it should probably be removed.
:-)
The sooner your driver goes through the ALSA people in Linus' tree, the
sooner we can schedule the OSS driver for removal.
> Cheers,
> Kyle McMartin
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Adrian Bunk
> On Tue, 26 Jul 2005, Adrian Bunk wrote:
>
> >This patch schedules obsolete OSS drivers (with ALSA drivers that
> >support the same hardware) for removal.
>
> Hello Adrian.
Hi Thorsten,
> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two
> problems of the ALSA AD1816 driver, that do not show up with the OSS
> driver:
> - According to my own experience and user reports audio is choppy with
> some VoIP Softphones like gnophone at least when used with the ALSA OSS
> emulation layer, whereas the OSS driver is crystal clear.
> - Users reported, that on some HP Kayak systems the on-board AD1816A
> was not properly detected by the ALSA driver or was detected, but
> there was no audio output. I'm not sure if the problem is still present in
> the current ALSA driver, as I do not own such a system.
>
> Maybe the OSS driver should stay in the kernel, until those problems are
> fixed in the ALSA driver.
thanks for this note, I'll drop the AD1816 driver from my list.
> Regards
> Thorsten
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Lee Revell
> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two
> problems of the ALSA AD1816 driver, that do not show up with the OSS
> driver:
> - According to my own experience and user reports audio is choppy with
> some VoIP Softphones like gnophone at least when used with the ALSA OSS
> emulation layer, whereas the OSS driver is crystal clear.
> - Users reported, that on some HP Kayak systems the on-board AD1816A
> was not properly detected by the ALSA driver or was detected, but
> there was no audio output. I'm not sure if the problem is still present in
> the current ALSA driver, as I do not own such a system.
What are the bug id #s in the ALSA BTS? If it's not in the bug tracker
it's never going to get fixed.
Lee
Jaroslav Kysela
> On Tue, 26 Jul 2005, Adrian Bunk wrote:
>
> > This patch schedules obsolete OSS drivers (with ALSA drivers that
> > support the same hardware) for removal.
>
> Hello Adrian.
>
> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two
> problems of the ALSA AD1816 driver, that do not show up with the OSS
> driver:
> - According to my own experience and user reports audio is choppy with
> some VoIP Softphones like gnophone at least when used with the ALSA
> OSS emulation layer, whereas the OSS driver is crystal clear.
> - Users reported, that on some HP Kayak systems the on-board AD1816A was
> not properly detected by the ALSA driver or was detected, but there
> was no audio output. I'm not sure if the problem is still present in
> the current ALSA driver, as I do not own such a system.
>
> Maybe the OSS driver should stay in the kernel, until those problems are
> fixed in the ALSA driver.
The problem is that nobody reported us mentioned problems. We have no
bug-report regarding the AD1816A driver. Perhaps, it would be a good idea
to add a notice to the help file and/or driver that the ALSA driver should
be tested and bugs reported to the ALSA bug-tracking-system.
Thanks,
Jaroslav
-----
Jaroslav Kysela <pe...@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
Adrian Bunk
>
> The problem is that nobody reported us mentioned problems. We have no
> bug-report regarding the AD1816A driver. Perhaps, it would be a good idea
> to add a notice to the help file and/or driver that the ALSA driver should
> be tested and bugs reported to the ALSA bug-tracking-system.
Although it wouldn't have helped with this driver, could you review the
currently 35 open ALSA bugs in the kernel Bugzilla [1]?
- Some might first require a question to the submitter whether the
problem is still present in recent kernels.
- Some might be problems in other parts of the kernel
(e.g. ACPI interrupt configuration problems).
- But some bugs might be bugs still present in recent ALSA.
The Gentoo people are using a pretty easy and nice way for forwarding
their bugs to the kernel Bugzilla, that would work the following way for
forwarding Bugs from the kernel Bugzilla to the ALSA BTS:
- open a new bug in the ALSA BTS:
- short description of the issue
- more information is at
http://bugzilla.kernel.org/show_bug.cgi?id=12345
- add a comment to the kernel Bugzilla (but leave the bug open):
this bug is now handled at the ALSA BTS at
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=23456
You could also do this the other way round if e.g. a ACPI interrupt
configuration problem was reported to the ALSA BTS.
> Thanks,
> Jaroslav
cu
Adrian
[1] http://bugzilla.kernel.org/
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Thorsten Knabe
> On Thu, 28 Jul 2005, Thorsten Knabe wrote:
>
>> On Tue, 26 Jul 2005, Adrian Bunk wrote:
>>
>>> This patch schedules obsolete OSS drivers (with ALSA drivers that
>>> support the same hardware) for removal.
>>
>> Hello Adrian.
>>
>> I'm the maintainer of the OSS AD1816 sound driver. I'm aware of two
>> problems of the ALSA AD1816 driver, that do not show up with the OSS
>> driver:
>> - According to my own experience and user reports audio is choppy with
>> some VoIP Softphones like gnophone at least when used with the ALSA
>> OSS emulation layer, whereas the OSS driver is crystal clear.
>> - Users reported, that on some HP Kayak systems the on-board AD1816A was
>> not properly detected by the ALSA driver or was detected, but there
>> was no audio output. I'm not sure if the problem is still present in
>> the current ALSA driver, as I do not own such a system.
>>
>> Maybe the OSS driver should stay in the kernel, until those problems are
>> fixed in the ALSA driver.
>
> The problem is that nobody reported us mentioned problems. We have no
> bug-report regarding the AD1816A driver. Perhaps, it would be a good idea
> to add a notice to the help file and/or driver that the ALSA driver should
> be tested and bugs reported to the ALSA bug-tracking-system.
Hello Jaroslav.
I'll do some testing during the upcoming weekend to confirm, that the
mentioned problems still exist with the current ALSA release. Last time I
checked was sometime around Linux 2.6.10. I'll file a bug report of my
findings to the ALSA bug tracking system and contact the author of the
driver. Initially I had not spent much time on those problems, because I
had an alternative working OSS driver, but since removal of the OSS seems
to get closer, it's probably time to fix these issues now.
Regards
Thorsten
--
___
| | / E-Mail: li...@thorsten-knabe.de
|horsten |/\nabe WWW: http://linux.thorsten-knabe.de
James Courtier-Dutton
> This patch schedules obsolete OSS drivers (with ALSA drivers that
> support the same hardware) for removal.
>
>
> 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
Adrian Bunk
> On 7/26/05, Adrian Bunk <bu...@stusta.de> wrote:
> > config SOUND_OPL3SA2
> > tristate "Yamaha OPL3-SA2 and SA3 based PnP cards"
> > - depends on SOUND_OSS
> > + depends on SOUND_OSS && OBSOLETE_OSS_DRIVER
> > help
> > Say Y or M if you have a card based on one of these Yamaha sound
> > chipsets or the "SAx", which is actually a SA3. Read
> Forgive me if I'm misreading this (I'm hardly a coder and no kernel
> hacker) but, as it stands, the OPL3SA2 driver provided by ALSA and the
> main kernel tree work but are not correctly detected by ALSA's
> detection routines (in alsaconf) on the 2.6 kernel. The OSS drivers
> work, as well, but (AFAIK) there are no methods of automatic
> configuration with the OSS drivers.
>
> So, for people who don't feel like configuring ALSA with their OPL3SA2
> card, the OSS modules may be easier to configure and thus should be
> left in until the ALSA/2.6 kernel problems are worked out with the
> OPL3SA2.
This is kernel bug #3117 [1] / ALSA bug #879 [2]?
> -Andy
cu
Adrian
[1] http://bugzilla.kernel.org/show_bug.cgi?id=3117
[2] https://bugtrack.alsa-project.org/alsa-bug/view.php?id=879
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Adrian Bunk
> Zach Brown <z...@zabbo.net> wrote:
> > Adrian Bunk wrote:
> > > This patch schedules obsolete OSS drivers (with ALSA drivers that
> > > support the same hardware) for removal.
>
> > > I've Cc'ed the people listed in MAINTAINERS as being responsible for one
> > > or more of these drivers, and I've also Cc'ed the ALSA people.
>
> > I haven't touched the maestro drivers in so long (for near-total lack of
> > docs, etc.) that I can't be considered authoritative for approving it's
> > removal. If people are relying on it I certainly don't know who they
> > are. In better news, Takashi should now have the pile of maestro
> > hardware that I used in the first pass to help him maintain the ALSA
> > driver..
>
> The OSS maestro driver works better on my old Armada E500 laptop. I tried
> ALSA after switching to 2.6, but the computer hung with 2.6.8.1 or 2.6.10 if
> I touched the volume buttons. With OSS they just work. The four separate
> dsp devices also look kind of more useful.
I've left it on the list of OSS drivers scheduled for removal based on
Takashi's comment that the volume button problem should be fixed now.
If this problem is still present in 2.6.13-rc4, please open a bug at the
ALSA bug tracking system [1] and tell me the bug number so that I can
track it.
> Zoran
cu
Adrian
[1] https://bugtrack.alsa-project.org/alsa-bug/
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Adrian Bunk
>
> Hello Jaroslav.
>
> I'll do some testing during the upcoming weekend to confirm, that the
> mentioned problems still exist with the current ALSA release. Last time I
> checked was sometime around Linux 2.6.10. I'll file a bug report of my
> findings to the ALSA bug tracking system and contact the author of the
> driver. Initially I had not spent much time on those problems, because I
> had an alternative working OSS driver, but since removal of the OSS seems
> to get closer, it's probably time to fix these issues now.
Thanks a lot!
Can you send me the bug numbers in the ALSA bug tracking system if you
have to send bug reports, so that I can track when these issues will be
resolved?
> Regards
> Thorsten
TIA
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Andrew Haninger
> 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?
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
Thorsten Knabe
> Thorsten: Please remember to include the list(s) when emailing those
> links/numbers. I'd like to be able to watch it, too, and add any
> information that I can, rather than entering a duplicate bug.
Hello.
I have taken a closer look at the ALSA AD1816 sound driver during the last
weekend. Here are my findings:
On vanilla Linux 2.6.12.3 and 2.6.13-rc4 modprobe hangs in D-state when
loading the snd-ad1816a module. No messages have been logged to the syslog
and the system is otherwise stable. Of course the sound card is unusable.
On Linux 2.6.8 (as shipped with current Debian Sarge), vanilla Linux
2.6.10 and Linux 2.6.11.12 the module loads fine.
I have done some tests with xmms(Debian), kphone(VoIP-Phone/Debian) and
iaxcomm(VoIP-Phone/self-made). Audio playback with xmms is always fine
using either ALSA or OSS emulation. Using OSS emulation with one of the
VoIP phones, playback and recording stop a few seconds after the call is
started. Using the ALSA interface with kphone works, but there is a
continuous clicking approximately 3 times per second. Also audio latency
is poor compared to the OSS driver. iaxcomm does not support the ALSA
audio interface, thus no problems here. :-)
The native OSS driver is fine on all kernels with all tested applications.
Also the ALSA driver does not have an equivalent for the
"ad1816_clockfreq" option of the OSS driver. The AD1816 chip requires a
33MHz reference clock, however some cards use a different (mostly
32.125MHz) clock, thus the audio sample rate has to be corrected before it
is written to the hardware registers for proper playback and recording
speed.
I have not filed any bug reports to the ALSA bug tracking system so far,
but will do so tomorrow and add the corresponding bug numbers to this
thread.
Thorsten
--
___
| | / E-Mail: li...@thorsten-knabe.de
|horsten |/\nabe WWW: http://linux.thorsten-knabe.de
Lee Revell
> Using OSS emulation with one of the
> VoIP phones
Are you referring to the in-kernel OSS emulation, or the alsa-lib
emulation ("aoss ./app")?
Lee
James Courtier-Dutton
It sounds to me that the best way to fix this is either:
a) Detect sound card subversion number and select different clock based
on that.
b) Some how auto detect the clock, much like the intel8x0 driver does.
c) Provide a manual option like the OSS driver. (We should probably have
this as well as (a) for the cases where (a) does not know about
particular soundcard X yet.
James
Thorsten Knabe
Here are the bug id's for the various issues from the ALSA bugtracking
system:
On Tue, 2 Aug 2005, Thorsten Knabe wrote:
> On vanilla Linux 2.6.12.3 and 2.6.13-rc4 modprobe hangs in D-state when
> loading the snd-ad1816a module. No messages have been logged to the syslog
> and the system is otherwise stable. Of course the sound card is unusable.
#1300: modprobe goes into D-state when inserting snd-ad1816a
> Using OSS emulation with one of the VoIP
> phones, playback and recording stop a few seconds after the call is started.
> Using the ALSA interface with kphone works, but there is a continuous
> clicking approximately 3 times per second. Also audio latency is poor
> compared to the OSS driver.
#1301: Kernel OSS emulation stops working after a few seconds when used
with VoIP softphones
#1302: Clicking noise when using kphone with the ALSA AD1816A sound driver
> Also the ALSA driver does not have an equivalent for the "ad1816_clockfreq"
> option of the OSS driver.
#1303: AD1816A sound driver has no parameter to adjust reference clock
frequency
Regards
Adrian Bunk
>
> > On Mer, 2005-07-27 at 16:43 -0400, Jeff Garzik wrote:
> > > ISTR Alan saying there was some ALi hardware that either wasn't in ALSA,
> > > or most likely didn't work in ALSA. If Alan says I'm smoking crack,
> > > then you all can ignore me :)
> >
> > The only big thing I know that still needed OSS (and may still do so) is
> > the support for AC97 wired touchscreens and the like. Has that been
> > ported to ALSA ?
>
> We're working on this issue right now.
What's the current status of this issue?
> Jaroslav
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Andi Kleen
>
> 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 <bu...@stusta.de>
I object to the ICH driver being scheduler for removal. It works
fine and is a significantly less bloated than the equivalent ALSA setup.
This means ac97_codec.c also has to stay.
-Andi
Alistair John Strachan
> Adrian Bunk <bu...@stusta.de> writes:
> > Documentation/feature-removal-schedule.txt | 7 +
> > sound/oss/Kconfig | 79 ++++++++++++---------
> > 2 files changed, 54 insertions(+), 32 deletions(-)
> >
> > ---
> > linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt.old
> >2005-07-26 16:50:05.000000000 +0200 +++
> > linux-2.6.13-rc3-mm1-full/Documentation/feature-removal-schedule.txt 2005
> >-07-26 16:51:24.000000000 +0200 @@ -44,0 +45,7 @@
> > +What: drivers depending on OBSOLETE_OSS_DRIVER
> > +When: October 2005
> > +Why: OSS drivers with ALSA replacements
> > +Who: Adrian Bunk <bu...@stusta.de>
>
> I object to the ICH driver being scheduler for removal. It works
> fine and is a significantly less bloated than the equivalent ALSA setup.
>
> This means ac97_codec.c also has to stay.
I think this is probably true for quite a few of the OSS drivers, versus their
ALSA equivalents. The fact is that OSS is obsolete, and the ALSA libraries
and utilities provide, to all soundcards, more features than the OSS API
could.
Maybe it's more bloated, but it's about time applications on Linux didn't have
to support 2-3 audio APIs just so they'd work on more than 50% of systems.
It strikes me that it's a bit of a chicken and egg problem. Vendors are still
releasing applications on Linux that support only OSS, partly due to
ignorance, but mostly because ALSA's OSS compatibility layer allows them to
lazily ignore the ALSA API and target all cards, old and new.
Additionally, we can't get rid of OSS compatibility until pretty much all
hardware has an ALSA driver, and (inferred from your comment) we can't get
rid of OSS drivers until nothing supports OSS, because the whole of the ALSA
stuff is a bit larger...
Even if Adrian's not trying to make this point (he's just removing duplicate
drivers, and opting for the newer ones), we accepted ALSA into the kernel.
It's probably about time we let OSS die properly, for sanity purposes.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Andi Kleen
> It strikes me that it's a bit of a chicken and egg problem. Vendors are still
> releasing applications on Linux that support only OSS, partly due to
> ignorance, but mostly because ALSA's OSS compatibility layer allows them to
> lazily ignore the ALSA API and target all cards, old and new.
As long as it works why is that a bad thing? OSS API works just fine
for most sound needs. If you want to do high end sound you can still
use ALSA.
> Additionally, we can't get rid of OSS compatibility until pretty much all
> hardware has an ALSA driver, and (inferred from your comment) we can't get
> rid of OSS drivers until nothing supports OSS, because the whole of the ALSA
> stuff is a bit larger...
We can never get rid of it.
Linux doesn't break widely used application interfaces.
> Even if Adrian's not trying to make this point (he's just removing duplicate
> drivers, and opting for the newer ones), we accepted ALSA into the kernel.
> It's probably about time we let OSS die properly, for sanity purposes.
Avoiding bloat is more important.
-Andi
Alistair John Strachan
> On Tuesday 03 January 2006 14:47, Alistair John Strachan wrote:
> > It strikes me that it's a bit of a chicken and egg problem. Vendors are
> > still releasing applications on Linux that support only OSS, partly due
> > to ignorance, but mostly because ALSA's OSS compatibility layer allows
> > them to lazily ignore the ALSA API and target all cards, old and new.
>
> As long as it works why is that a bad thing? OSS API works just fine
> for most sound needs. If you want to do high end sound you can still
> use ALSA.
Is multiple-source mixing really a "high end" requirement? When I last
checked, the OSS driver didn't support multiple applications claiming it at
once, thus requiring you to use "more bloat" like esound, arts, or some other
crap to access your soundcard more than once at any given time.
I think when you consider other modern sound architectures across many
operating systems have supported this fundamentally basic feature for a long
time, it's important to the majority of end users.
> > Additionally, we can't get rid of OSS compatibility until pretty much all
> > hardware has an ALSA driver, and (inferred from your comment) we can't
> > get rid of OSS drivers until nothing supports OSS, because the whole of
> > the ALSA stuff is a bit larger...
>
> We can never get rid of it.
> Linux doesn't break widely used application interfaces.
Okay, fair point.
> > Even if Adrian's not trying to make this point (he's just removing
> > duplicate drivers, and opting for the newer ones), we accepted ALSA into
> > the kernel. It's probably about time we let OSS die properly, for sanity
> > purposes.
>
> Avoiding bloat is more important.
I can't agree with that.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
David Lang
>> 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
Alistair John Strachan
> On Tue, 3 Jan 2006, Andi Kleen wrote:
> >> Even if Adrian's not trying to make this point (he's just removing
> >> duplicate drivers, and opting for the newer ones), we accepted ALSA into
> >> the kernel. It's probably about time we let OSS die properly, for sanity
> >> purposes.
> >
> > Avoiding bloat is more important.
>
> given that the ALSA drivers are not going to be removed, isn't it bloat to
> have two drivers for the same card?
Normally this isn't too big a deal in Linux; eventually one gets removed, but
not until it is substantially inferior than the other (or broken, or not
compiling, or unmaintained..).
> yes, an individual compiled kernel may be slightly smaller by continueing
> to support the OSS driver, but the source (and the maintinance) are
> significantly worse by haveing two drivers instead of just one.
If there are two separate maintainers it's probably not a lot worse. I think
the argument pretty much has to remain "ALSA drivers are technically
superior, OSS drivers have unfixable limitations", and that should be a good
enough reason to see them removed.
Perhaps Andi's concerns about ALSA bloat could also be concerned. I don't know
enough about the "high end" features of ALSA to comment on whether they could
become optional (currently there are few driver-generic options in the
Kconfig file).
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Alistair John Strachan
> On Tuesday 03 January 2006 13:58, David Lang wrote:
> > On Tue, 3 Jan 2006, Andi Kleen wrote:
> > >> Even if Adrian's not trying to make this point (he's just removing
> > >> duplicate drivers, and opting for the newer ones), we accepted ALSA
> > >> into the kernel. It's probably about time we let OSS die properly, for
> > >> sanity purposes.
> > >
> > > Avoiding bloat is more important.
> >
> > given that the ALSA drivers are not going to be removed, isn't it bloat
> > to have two drivers for the same card?
>
> Normally this isn't too big a deal in Linux; eventually one gets removed,
> but not until it is substantially inferior than the other (or broken, or
> not compiling, or unmaintained..).
>
> > yes, an individual compiled kernel may be slightly smaller by continueing
> > to support the OSS driver, but the source (and the maintinance) are
> > significantly worse by haveing two drivers instead of just one.
>
> If there are two separate maintainers it's probably not a lot worse. I
> think the argument pretty much has to remain "ALSA drivers are technically
> superior, OSS drivers have unfixable limitations", and that should be a
> good enough reason to see them removed.
>
> Perhaps Andi's concerns about ALSA bloat could also be concerned.
Jan Engelhardt
>It strikes me that it's a bit of a chicken and egg problem. Vendors are still
>releasing applications on Linux that support only OSS, partly due to
>ignorance, but mostly because ALSA's OSS compatibility layer allows them to
>lazily ignore the ALSA API and target all cards, old and new.
>
>Additionally, we can't get rid of OSS compatibility until pretty much all
>hardware has an ALSA driver, and (inferred from your comment) we can't get
>rid of OSS drivers until nothing supports OSS, because the whole of the ALSA
>stuff is a bit larger...
>
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
--
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.
Jan Engelhardt
>The problem with using OSS compatibility, at least on this machine with ALSA
>1.0.9, is that if you use it you automatically lose the software mixing
>capabilities of ALSA, so it really is less than ideal.
>
Well, I am able to open /dev/dsp multiple times here without problems.
(Is /dev/dsp soft- or hardmixing?)
Jan Engelhardt
--
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.
Tomasz Torcz
> On Tuesday 03 January 2006 14:50, Jan Engelhardt wrote:
> > >The problem with using OSS compatibility, at least on this machine with
> > > ALSA 1.0.9, is that if you use it you automatically lose the software
> > > mixing capabilities of ALSA, so it really is less than ideal.
> >
> > Well, I am able to open /dev/dsp multiple times here without problems.
> > (Is /dev/dsp soft- or hardmixing?)
>
> As far as I'm aware, it depends on your hardware. For example, software mixing
> kicks in with zero configuration on most hardware that won't mix in hardware,
> e.g. my laptop's i810 audio.
>
> [alistair] 15:18 [~] cat /proc/asound/cards
> 0 [I82801DBICH4 ]: ICH4 - Intel 82801DB-ICH4
> Intel 82801DB-ICH4 with AD1981B at 0xa0100000, irq 11
> 1 [Modem ]: ICH-MODEM - Intel 82801DB-ICH4 Modem
> Intel 82801DB-ICH4 Modem at 0x3400, irq 11
>
> I can successfully hear two mixed sources when I execute the following:
>
> ogg123 -q --device=alsa09 01\ -\ Good\ Times\ Bad\ Times.ogg
>
> And on another terminal
>
> ogg123 -q --device=alsa09 01\ -\ Good\ Times\ Bad\ Times.og
>
> This is ALSA soft mixing the two sources for me. Very nifty. However, if I
> throw an OSS into the mix (whilst these other two are playing).
>
> [alistair] 15:20 [~/Music/Led Zeppelin - I] ogg123 -q --device=oss 01\ -\
> Good\ Times\ Bad\ Times.ogg
> Error: Cannot open device oss.
Proper way (using userspace OSS emulation):
aoss ogg123 -q --device=oss [...]
--
Tomasz Torcz "Funeral in the morning, IDE hacking
zdzichu@irc.-nie.spam-.pl in the afternoon and evening." - Alan Cox
Alistair John Strachan
[snip]
> >
> > [alistair] 15:20 [~/Music/Led Zeppelin - I] ogg123 -q --device=oss 01\ -\
> > Good\ Times\ Bad\ Times.ogg
> > Error: Cannot open device oss.
>
> Proper way (using userspace OSS emulation):
> aoss ogg123 -q --device=oss [...]
I'm aware of this.
This has nothing to do with the kernel option CONFIG_SND_OSSEMUL which Jan
referred to, and to which I was responding. "aoss" is also not compatible
with every conceivable program.
This is exactly why the OSS emulation option in ALSA is really a last resort
and should not be an excuse for people to ignore implementing ALSA support
directly. More so, it is very good justification for ditching "everything
OSS" as soon as possible, at least in new software.
Olivier Galibert
> This has nothing to do with the kernel option CONFIG_SND_OSSEMUL which Jan
> referred to, and to which I was responding. "aoss" is also not compatible
> with every conceivable program.
Especially not with plugins. Flashplayer anybody?
> This is exactly why the OSS emulation option in ALSA is really a last resort
> and should not be an excuse for people to ignore implementing ALSA support
> directly. More so, it is very good justification for ditching "everything
> OSS" as soon as possible, at least in new software.
Actually the crappy state of OSS emulation is a good reason to ditch
ALSA in its current implementation. As Linus reminded not so long
ago, backwards compatibility is extremely important.
Also, not everybody wants to depend on a shared library. I find this
"the alsa lib must be kept in lockstep with the kernel version" quite
annoying. I'd rather not have the windows dll hell on linux, TYVM.
Or in other words, the public API of a kernel interface should _NEVER_
be a library only. At least OSS, with all its issues, had that right.
OG.
Jan Engelhardt
>> (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.
>
>
>Works, but then:
>
>ogg123 -q --device=oss 01\ -\ Good\ Times\ Bad\ Times.ogg
>Error: Cannot open device oss
Oh well this does work for me.
>This is all a little OT for this thread, but it's certainly the case with
>alsa-lib-1.0.10 on 2.6.15-rc7. My card isn't capable of hardware mixing,
>yours might be (SBLive!/Audigy or something).
CS46XX. According to alsamixer info, it has 31 playback and 1 record channel.
Looks like I'm in favor of hardware mixing.
But hey, you have not lost anything using the OSS emulation. With OSS, I could
not even have hardware mixing on cs46xx!
Jan Engelhardt
--
Alistair John Strachan
> On Tue, Jan 03, 2006 at 04:29:21PM +0000, Alistair John Strachan wrote:
> > This has nothing to do with the kernel option CONFIG_SND_OSSEMUL which
> > Jan referred to, and to which I was responding. "aoss" is also not
> > compatible with every conceivable program.
>
> Especially not with plugins. Flashplayer anybody?
Konqueror manages to "wrap" plugins quite happily.. complain to whoever makes
your browser.
> > This is exactly why the OSS emulation option in ALSA is really a last
> > resort and should not be an excuse for people to ignore implementing ALSA
> > support directly. More so, it is very good justification for ditching
> > "everything OSS" as soon as possible, at least in new software.
>
> Actually the crappy state of OSS emulation is a good reason to ditch
> ALSA in its current implementation. As Linus reminded not so long
> ago, backwards compatibility is extremely important.
This argument is basically watered down with devfs, udev, sysfs, etc. which
all have exactly the same issues. Should a crippled OSS API be the way
forward for Linux? I think not.
> Also, not everybody wants to depend on a shared library. I find this
> "the alsa lib must be kept in lockstep with the kernel version" quite
> annoying. I'd rather not have the windows dll hell on linux, TYVM.
> Or in other words, the public API of a kernel interface should _NEVER_
> be a library only. At least OSS, with all its issues, had that right.
Okay, I agree it's not ideal. But if you want software mixing, and it's a
genuinely useful feature, you either have to go down the road of running some
crappy daemon like arts or esound, or just link against libasound and get it
for free. I know I'd rather not have mixing routines in my kernel, thanks.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Lee Revell
> On Tuesday 03 January 2006 14:47, Alistair John Strachan wrote:
>
> > It strikes me that it's a bit of a chicken and egg problem. Vendors are still
> > releasing applications on Linux that support only OSS, partly due to
> > ignorance, but mostly because ALSA's OSS compatibility layer allows them to
> > lazily ignore the ALSA API and target all cards, old and new.
>
> As long as it works why is that a bad thing? OSS API works just fine
> for most sound needs. If you want to do high end sound you can still
> use ALSA.
OSS can't do software mixing of multiple audio streams, it requires a
sound server to do this. So IMHO the OSS approach causes more bloat on
the desktop.
Lee
Lee Revell
> On Tue, Jan 03, 2006 at 04:29:21PM +0000, Alistair John Strachan wrote:
> > This has nothing to do with the kernel option CONFIG_SND_OSSEMUL which Jan
> > referred to, and to which I was responding. "aoss" is also not compatible
> > with every conceivable program.
>
> Especially not with plugins. Flashplayer anybody?
Yes it's a known issue that the aoss emulation is not perfect, it's not
a reason to ditch ALSA, it's a reason to fix it.
Please provide a reproducible test case where an app *that we have the
source code for* works with native OSS or the in kernel /dev/dsp OSS
emulation and fails with the aoss/alsa-lib/userspace OSS emulation and
it will be fixed ASAP.
Lee
Olivier Galibert
> This argument is basically watered down with devfs, udev, sysfs, etc. which
> all have exactly the same issues. Should a crippled OSS API be the way
> forward for Linux? I think not.
And they're getting some real backlash because of that now. Hell,
Linus' message was about udev in the first place.
As for the OSS API being crippled, I'd take the 3 ioctl calls you need
to setup a simple stereo 16bits output with OSS than the 13 ALSA
library calls anyday. Especially with the impressive lack of
documentation you get about what the hell is a period, or what you can
do except aborting when you get an error.
> > Also, not everybody wants to depend on a shared library. I find this
> > "the alsa lib must be kept in lockstep with the kernel version" quite
> > annoying. I'd rather not have the windows dll hell on linux, TYVM.
> > Or in other words, the public API of a kernel interface should _NEVER_
> > be a library only. At least OSS, with all its issues, had that right.
>
> Okay, I agree it's not ideal. But if you want software mixing, and it's a
> genuinely useful feature, you either have to go down the road of running some
> crappy daemon like arts or esound, or just link against libasound and get it
> for free. I know I'd rather not have mixing routines in my kernel, thanks.
Duh, then don't put the mixing in the kernel, put the data routing
there. That's a large part of what the kernel is about, moving data
around, and Linus' new magic pipes are perfect for that kind of use.
Then at system startup and through udev you can start whatever mixers,
sequencers, virtual interfaces and stuff you want. Applications don't
need to care, and you don't have the amusing security issues around
what happens when different users want to use the sound card at the
same time.
OG.
Thomas Sailer
> 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
> On Tue, 2006-01-03 at 13:28 -0500, Lee Revell wrote:
>
> > Please provide a reproducible test case where an app *that we have the
> > source code for* works with native OSS or the in kernel /dev/dsp OSS
> > emulation and fails with the aoss/alsa-lib/userspace OSS emulation and
> > it will be fixed ASAP.
>
> I didn't know AOSS, but http://www.baycom.org/~tom/ham/soundmodem/ fails
> with ALSA's kernel OSS emulation.
Anyone reported that? Also what's the exact bug symptom?
Jaroslav
-----
Jaroslav Kysela <pe...@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
Adrian Bunk
> On Tue, Jan 03, 2006 at 05:16:13PM +0000, Alistair John Strachan wrote:
> > This argument is basically watered down with devfs, udev, sysfs, etc. which
> > all have exactly the same issues. Should a crippled OSS API be the way
> > forward for Linux? I think not.
>
> And they're getting some real backlash because of that now. Hell,
> Linus' message was about udev in the first place.
The udev breakages might not have been nice, but OSS/ALSA is a
completely different issue:
OSS has been deprecated since ALSA was merged into the Linux kernel
_four years ago_.
And I'm only talking about removing drivers _with ALSA drivers for the
same hardware available_.
> As for the OSS API being crippled, I'd take the 3 ioctl calls you need
> to setup a simple stereo 16bits output with OSS than the 13 ALSA
> library calls anyday. Especially with the impressive lack of
> documentation you get about what the hell is a period, or what you can
> do except aborting when you get an error.
>...
For a general OSS<->ALSA discussion, you are five years too late.
> OG.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Thomas Sailer
> 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
> On Tue, 2006-01-03 at 20:37 +0100, Jaroslav Kysela wrote:
>
> > Anyone reported that? Also what's the exact bug symptom?
>
> Many people reported this on various mailing lists, but I'm not aware of
> any bugzilla/whatever ticket.
>
> Problem seems to be that ALSA/OSS does not report the true HW sampling
> rate, but tries to do the sample rate conversion by itself, but
> apparently not doing it good enough for modem type applications.
The "plugin" (or rather conversion, routing and resampling) system in the
OSS emulation can be turned off using the proc interface:
echo "soundmodem 0 0 direct" > /proc/asound/card0/pcm0p/oss
echo "soundmodem 0 0 direct" > /proc/asound/card0/pcm0c/oss
Full documentation is available at:
linux/Documentation/sound/alsa/OSS-Emulation.txt
It's easy to remove the "additional" functionality, but I bet that we
find some users requesting it. Also, in time when the OSS emulation was
designed, not all OSS applications had own resapling code.
Jaroslav
-----
Jaroslav Kysela <pe...@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
Takashi Iwai
Olivier Galibert wrote:
>
> > This is exactly why the OSS emulation option in ALSA is really a last resort
> > and should not be an excuse for people to ignore implementing ALSA support
> > directly. More so, it is very good justification for ditching "everything
> > OSS" as soon as possible, at least in new software.
>
> Actually the crappy state of OSS emulation is a good reason to ditch
> ALSA in its current implementation. As Linus reminded not so long
> ago, backwards compatibility is extremely important.
Well, we keep the compatibility exactly -- OSS drivers don't support
software mixing in the kernel, too :)
Takashi
Takashi Iwai
Tomasz Torcz wrote:
>
> On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> > At Tue, 3 Jan 2006 18:03:16 +0100,
> > Olivier Galibert wrote:
> > >
> > > > This is exactly why the OSS emulation option in ALSA is really a last resort
> > > > and should not be an excuse for people to ignore implementing ALSA support
> > > > directly. More so, it is very good justification for ditching "everything
> > > > OSS" as soon as possible, at least in new software.
> > >
> > > Actually the crappy state of OSS emulation is a good reason to ditch
> > > ALSA in its current implementation. As Linus reminded not so long
> > > ago, backwards compatibility is extremely important.
> >
> > Well, we keep the compatibility exactly -- OSS drivers don't support
> > software mixing in the kernel, too :)
>
> http://kerneltrap.org/node/4388
Why do we need to keep the compatibility with NetBSD?
Jesper Juhl
> At Tue, 3 Jan 2006 21:37:32 +0100,
> Tomasz Torcz wrote:
> >
> > On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> > > At Tue, 3 Jan 2006 18:03:16 +0100,
> > > Olivier Galibert wrote:
> > > >
> > > > > This is exactly why the OSS emulation option in ALSA is really a last resort
> > > > > and should not be an excuse for people to ignore implementing ALSA support
> > > > > directly. More so, it is very good justification for ditching "everything
> > > > > OSS" as soon as possible, at least in new software.
> > > >
> > > > Actually the crappy state of OSS emulation is a good reason to ditch
> > > > ALSA in its current implementation. As Linus reminded not so long
> > > > ago, backwards compatibility is extremely important.
> > >
> > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > software mixing in the kernel, too :)
> >
> > OSS will support software mixing. In kernel. On NetBSD.
> > http://kerneltrap.org/node/4388
>
> Why do we need to keep the compatibility with NetBSD?
>
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 <jespe...@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
Olivier Galibert
> The udev breakages might not have been nice, but OSS/ALSA is a
> completely different issue:
>
> OSS has been deprecated since ALSA was merged into the Linux kernel
> _four years ago_.
OSS _drivers_ yes, OSS _api_ no.
> And I'm only talking about removing drivers _with ALSA drivers for the
> same hardware available_.
Sure, and I have no problem with that. OTOH you'll notice that this
particular subthread was specifically about the OSS api, not the
drivers.
> For a general OSS<->ALSA discussion, you are five years too late.
I couldn't predict 5 years ago that the ALSA API quality would be
somewhat lacking.
OG.
Adrian Bunk
> On 1/3/06, Takashi Iwai <ti...@suse.de> wrote:
> > At Tue, 3 Jan 2006 21:37:32 +0100,
> > Tomasz Torcz wrote:
> > >
> > > On Tue, Jan 03, 2006 at 09:22:58PM +0100, Takashi Iwai wrote:
> > > > At Tue, 3 Jan 2006 18:03:16 +0100,
> > > > Olivier Galibert wrote:
> > > > >
> > > > > > This is exactly why the OSS emulation option in ALSA is really a last resort
> > > > > > and should not be an excuse for people to ignore implementing ALSA support
> > > > > > directly. More so, it is very good justification for ditching "everything
> > > > > > OSS" as soon as possible, at least in new software.
> > > > >
> > > > > Actually the crappy state of OSS emulation is a good reason to ditch
> > > > > ALSA in its current implementation. As Linus reminded not so long
> > > > > ago, backwards compatibility is extremely important.
> > > >
> > > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > > software mixing in the kernel, too :)
> > >
> > > OSS will support software mixing. In kernel. On NetBSD.
> > > http://kerneltrap.org/node/4388
> >
> > Why do we need to keep the compatibility with NetBSD?
> >
> Software mixing is a really nice feature for people with soundscards
> that can't do hardware mixing, so if the OSS compatibility could
> transparently do software mixing for apps using OSS api that would be
> a very nice extension for a lot of people - I'd say that if NetBSD do
> that they've got the right idea.
The OSS compatibility in ALSA is only a legacy API for applications not
yet converted to use the ALSA API.
> Jesper Juhl
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Jesper Juhl
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 <jespe...@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
James Courtier-Dutton
> On Tue, 2006-01-03 at 20:37 +0100, Jaroslav Kysela wrote:
>
>
>>Anyone reported that? Also what's the exact bug symptom?
>
>
> Many people reported this on various mailing lists, but I'm not aware of
> any bugzilla/whatever ticket.
>
> Problem seems to be that ALSA/OSS does not report the true HW sampling
> rate, but tries to do the sample rate conversion by itself, but
> apparently not doing it good enough for modem type applications.
>
> Anyway I find it not a good idea of alsa to try to do sample rate
> conversion in kernel for OSS, as the native OSS drivers never did this,
> and it is useless for software (like soundmodem) that tries to find out
> the hardware rates in order to adapt to them. Kernel resampling badly
> interferes with this.
>
> Tom
>
> PS: I was too lazy to investigate this in depth, it was easier to just
> add a native ALSA driver to soundmodem.
>
You can switch off ALSA's sample rate converter with a line like the
following:
err = snd_pcm_hw_params_set_rate_resample(this->audio_fd, params, 0);
The zero switches off the alsa-lib resampler.
James
Adrian Bunk
> On Tue, Jan 03, 2006 at 10:56:54PM +0100, Adrian Bunk wrote:
> > > > > > Well, we keep the compatibility exactly -- OSS drivers don't support
> > > > > > software mixing in the kernel, too :)
> > > > >
> > > > > OSS will support software mixing. In kernel. On NetBSD.
> > > > > http://kerneltrap.org/node/4388
> > > >
> > > > Why do we need to keep the compatibility with NetBSD?
> > > >
> > > Software mixing is a really nice feature for people with soundscards
> > > that can't do hardware mixing, so if the OSS compatibility could
> > > transparently do software mixing for apps using OSS api that would be
> > > a very nice extension for a lot of people - I'd say that if NetBSD do
> > > that they've got the right idea.
> >
> > The OSS compatibility in ALSA is only a legacy API for applications not
> > yet converted to use the ALSA API.
>
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
-
Tomasz Kłoczko
> On Tue, Jan 03, 2006 at 08:24:49PM +0100, Olivier Galibert wrote:
>> On Tue, Jan 03, 2006 at 05:16:13PM +0000, Alistair John Strachan wrote:
>>> This argument is basically watered down with devfs, udev, sysfs, etc. which
>>> all have exactly the same issues. Should a crippled OSS API be the way
>>> forward for Linux? I think not.
>>
>> And they're getting some real backlash because of that now. Hell,
>> Linus' message was about udev in the first place.
>
> The udev breakages might not have been nice, but OSS/ALSA is a
> completely different issue:
>
> OSS has been deprecated since ALSA was merged into the Linux kernel
> _four years ago_.
Also more than four years exist another thing: generaly sound suport in
Linux kernel is broken by design. Points where it is broken:
1) ALSA API forces not use devices files and many things on sound managing
level are handled on user space library. This dissallow civilized
redirection sound stream in runed application without this application
interractions (try redirect sound stream on runed application for
example to headset .. simple case skype .. oh you probaly don't know: in
current ALSA infrastructure there is no civilized way for handle
gadgests like BT headsets). In current ALSA API (IIRC) you must write in
special way applications for handle this (look pint 2)).
2) ALSA API is to complicated: most applications opens single sound
stream.
All what system user expect it is plaing sound by more then one
application with simple mixing sound streams. For me ALSA is prepared
like for handle ANY sound case .. EXCEPT all most simpler.
3) ALSA kernel architecture is to complicated. This main reason why
configuring sound on Linux is SO COMPLICATED. From my system:
# lsmod | grep ^snd | wc -l
19
All this for handle ONLY ONE sound card. Why not one alsa main module
and one with hardware backend module like in comarcial OSS ?
ALSA is also requires much more bigger code size than OSS variant
(count all snd* modules size, jackd and libasound and compare this with
OSS modules and user space OSS library size). Simillar is on allocated
memory in all system sound components.
Many task switches incurred by the current ALSA architecture
add quickly up to perceivalble deleys during processing. In many cases
sound must be handled with RT piorites so all code sise must possible
small for handle this with minimal latency.
4) ALSA mixing model is UNSECURE by design because all mixing sound
streams (for example with diffrent sampling rates) are performed
in user space.
Also using jackd also "creates problems" with RTing this proccess and
much more bigger problems on configure stage (for joe user).
All this can be handled in secure and proprer RT prioprities
ONLY on kernel space (so all gaming mith jackd or so is plain waste
of time). Only on kernel level is possible correctly handle all this.
With ALSA you can't extend in esy way for example SELinux for prevent
intercept sound streem from microphone by remote user. Current OSS API
is much more better for SELinux.
Why ? because all mixing on OSS is performed on kernel level.
I can't understand why ALSA developers still do not understands this
fundamentalt facts.
5) OSS API can be used not only on Linux. ALSA API can be used ONLY on
Linux.
This was, still is and (looks like allways) will be main reason
for not spending so many time as it is required on polish sound
interractions on Linux applications.
Still I can't understand why introducing ALSA *must* break OSS user
space API in so deep way.
OSS user space API also have some weak poinst on to big complications
because it allow implemet the same cases in to many forms (for some
cases it provides more than two ways for handle some scenarios).
I do not understand why on developing Linux soud support was forgoten
"don't move .. improve" sentence :>
OSS API paralelism looks lik was "correctly" implemnted in ALSA .. so
ALSA do not improves sound handling for user space applications and
additionaly introduces other own complications (ASA API documentations
in many cases isn't clear).
Conclution: removing OSS from Linux kernel and force using ALSA in last
four years was IMO one of the main resons why Linux still can't
effectively fight on desktop area and in future will be/can be one of the
most importand weak point which can drive Linux to die at all (in longer
period).
kloczek
--
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: klo...@rudy.mif.pg.gda.pl*
Tomasz Kłoczko
[..]
>> 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
Adrian Bunk
> On Wed, 4 Jan 2006, Adrian Bunk wrote:
> [..]
> >> OSS is universal cross-unix API. ALSA is Linux-only.
> >
> >How "universal cross-unix" is the OSS API really?
> >
> >Which operating systems besides Linux have a native sound system
> >supporting the OSS API [1]?
> >
> >I know about FreeBSD and partial support in NetBSD.
> >
> >Are there any other [2]?
>
> Solaris, AIX ..
> Full list is avalaible in "Operating System" listbox on
> http://www.4front-tech.com/download.cgi
As I said in footnote 1 of my email, this has little value for
application developers since only few users on these systems use this
commercial sound system.
> kloczek
cu
Adrian
Thomas Sailer
> The "plugin" (or rather conversion, routing and resampling) system in the
> OSS emulation can be turned off using the proc interface:
Hm. IMO by including resampling and format conversion you're trying to
"unbreak" broken OSS apps in the kernel. And by having this on by
default you're rewarding writers of broken OSS apps while punishing
those that write correct apps...
But this is a sidetrack. Even though it's not optimal from the CPU usage
point of view to have two sampling rate converters in sequence, and
apart from the SNR loss by the overly simplistic linear interpolator,
soundmodem should still work with ALSA's OSS emulation. But it doesn't.
Well, it almost does: only every tenth or so bit is incorrect (which is
inacceptable for a modem, though). This leads me to suspect there's
something else wrong with the sample rate converter.
In sound/core/oss/rate.c, resample_expand, line 111:
if (src_frames1-- > 0) {
What is this test for? Similar code is also in resample_shrink.
Either it's never false, or I know why modem apps don't work with it: it
would be "inventing samples out of the blue", thereby adding lots of
jitter to the time axis...
Tom
Stefan Smietanowski
> On Wed, 4 Jan 2006, Adrian Bunk wrote:
> [..]
>
>>> OSS is universal cross-unix API. ALSA is Linux-only.
>>
>>
>> How "universal cross-unix" is the OSS API really?
>>
>> Which operating systems besides Linux have a native sound system
>> supporting the OSS API [1]?
>>
>> I know about FreeBSD and partial support in NetBSD.
>>
>> Are there any other [2]?
>
>
> Solaris, AIX ..
> Full list is avalaible in "Operating System" listbox on
> http://www.4front-tech.com/download.cgi
Are all those Operatings Systems that include OSS per default, no
additional download required? Because that's what he's asking for,
not what you can get OSS for.
Since that link is a _download page_ it makes me think that it's
an _additional download_ to get OSS support on those (or some of
those) operating systems.
// Stefan
Tomasz Kłoczko
[..]
>> 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.
Adrian Bunk
> On Wed, 4 Jan 2006, Adrian Bunk wrote:
> [..]
> >>Solaris, AIX ..
> >>Full list is avalaible in "Operating System" listbox on
> >>http://www.4front-tech.com/download.cgi
> >
> >As I said in footnote 1 of my email, this has little value for
> >application developers since only few users on these systems use this
> >commercial sound system.
>
> You are wrong using pejorative labeling "commercial sound system" for
> this. Comercial is implementation. OSS is defined by user space API.
> This is all what was neccessary on implemting this in for Linux.
The question is simple:
How many percent of the Solaris or AIX users are actually using any
sound system implementing the OSS API?
> OSS case on Linux is very simillar to Motiff case on X11.
> As same as Motiff OSS have publically avalaible and open specyfication
> avalaible on http://www.opensound.com/pguide/oss.pdf which do not touch
> kernel level implemntations details. Using this specyfication you can
> collect all neccessary details for implemt handle /dev/* interface on
> kernel side.
There are many cross-platform audio libraries available that work on
more systems than the systems implementing the OSS API (because they
have backends for many different sound APIs including OSS), and many of
them are with open specifications.
> kloczek
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
Thomas Sailer
> 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
> configuring sound on Linux is SO COMPLICATED. From my system:
Also agreed. It is IMO the hardest kernel subsystem to read. Instead of
having control passing from VFS to driver and the driver calling core
library routines, control passes from VFS to alsa core, which is 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
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" ?
Olivier Galibert
> On Wed, 2006-01-04 at 00:10 +0100, Tomasz K?oczko wrote:
>
> > 1) ALSA API forces not use devices files and many things on sound managing
> > level are handled on user space library. This dissallow civilized
>
> Huh? Why's that? Actually, I welcome that ALSA does quite a lot in
> userspace, it could even do more. The whole format conversion and
> sampling rate conversion has no business in the kernel, IMO.
Doing things in userspace does not necessarily mean doing them in a
library, especially when it is required that the library be shared,
also known as "things _will_ break".
Especially since it tends to hide the real, user-accessible kernel
interface which has very, very annoying security implications. At
that point, the ALSA kernel-userspace interface seems entirely
un-reviewed by the kernel people who have an eye for race conditions,
wandering userland pointers, information leaks, out-of-range accesses
and this kind of things (no patches from Al Viro on alsa?) and that
does not really give me a warm and fuzzy feeling. And even if it is
reviewed at time t, it looks like it may change anytime a driver
author thinks it would help. Not good at all.
OG.
Tomasz Kłoczko
> On Wed, Jan 04, 2006 at 01:46:08AM +0100, Tomasz K?oczko wrote:
>> On Wed, 4 Jan 2006, Adrian Bunk wrote:
>> [..]
>>>> Solaris, AIX ..
>>>> Full list is avalaible in "Operating System" listbox on
>>>> http://www.4front-tech.com/download.cgi
>>>
>>> As I said in footnote 1 of my email, this has little value for
>>> application developers since only few users on these systems use this
>>> commercial sound system.
>>
>> You are wrong using pejorative labeling "commercial sound system" for
>> this. Comercial is implementation. OSS is defined by user space API.
>> This is all what was neccessary on implemting this in for Linux.
>
> The question is simple:
>
> How many percent of the Solaris or AIX users are actually using any
> sound system implementing the OSS API?
First try answer on: if OSS specyfications is complet, easy to use in
applications and generaly compact why reinventing all from this level to
above on Linux ? why ?
If you answer first on this question you will see: answer
on your questions do not have sense.
Be compliant with OSS specyfication allow save many time on applications
development level by consume (in good sense) time spend on this
applications by *BSD, Solaris and other systems developers (even on not
open source applications).
After four years ALSA development quality of sound support in Linux is IMO
on the ~same (still bad) level as four years ago. Still to complicated
but now more bloated and additionaly not ready for handle fancy gadgets
like BT headsets.
On other systems (MOX, Win*, Solaris ..) on handle sound situations is now
better than four years ago. IMO this allow form conclution: generaly
current ALSA is step back compare to other systems and probaly Linux need
some deeper work then simple polishing sound device drivers.
More than year Linux in many publications is described as "excelent
system for mobile gadgets". All waits for this ..
Most of this gadgets want uses sound. Force using ALSA in this are makes
nightmares not only for drivers developers but also for user space
applications developers.
(IMO in comming year or two if nothing will change Linux can be visable
marginalized/can loose current possition .. not because in this period
Linux will be worse compare to now but because other systems like Solaris,
MOX and also Win* can pass in this period better progress on bringing some
valuable functionalities in usable/simpler form for joe-like users ..
remember: sound support in Linux isn't for data centers/big-ass-machines :)
Alan Cox
> Be compliant with OSS specyfication allow save many time on applicati
ons
> development level by consume (in good sense) time spend on this
> applications by *BSD, Solaris and other systems developers (even on n
ot
> open source applications).
Both Solaris and FreeBSD contain Linux emulation code so in that sense
they admitted 'defeat' long ago.
> valuable functionalities in usable/simpler form for joe-like users ..
> remember: sound support in Linux isn't for data centers/big-ass-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
Jan Engelhardt
> 2) ALSA API is to complicated: most applications opens single sound
> stream.
Seconded.
> 3) ALSA kernel architecture is to complicated. This main reason why
> configuring sound on Linux is SO COMPLICATED. From my system:
>
> # lsmod | grep ^snd | wc -l
> 19
>
Why would you, or the "Desktop User Joe" using Torvalds-advertised KDE,
care about how many modules are loaded?
Splitting code up to make things more modular is A Good Choice most
of the times. There is, however, one point in which you have reason:
if the overall modular structure is bigger than a mono one, then it's
indeed "complicated".
> ALSA is also requires much more bigger code size than OSS variant
> (count all snd* modules size, jackd and libasound and compare this with
> OSS modules and user space OSS library size). Simillar is on allocated
> memory in all system sound components.
>
jackd does not count - ALSA works without it.
> Many task switches incurred by the current ALSA architecture
> add quickly up to perceivalble deleys during processing. In many cases
> sound must be handled with RT piorites so all code sise must possible
> small for handle this with minimal latency.
>
> 4) ALSA mixing model is UNSECURE by design because all mixing sound
> streams (for example with diffrent sampling rates) are performed
> in user space.
>
I'd rather have libasound segfault rather than my kernel oopsing, in case
someone forgot a NULL check.
> Also using jackd also "creates problems" with RTing this proccess and
> much more bigger problems on configure stage (for joe user).
> All this can be handled in secure and proprer RT prioprities
> ONLY on kernel space (so all gaming mith jackd or so is plain waste
> of time). Only on kernel level is possible correctly handle all this.
> With ALSA you can't extend in esy way for example SELinux for prevent
> intercept sound streem from microphone by remote user. Current OSS API
> is much more better for SELinux.
> Why ? because all mixing on OSS is performed on kernel level.
>
AFAICS, OSS does not do mixing at all in its current state.
Jan Engelhardt
--
Alistair John Strachan
[snip]
>
> 2) ALSA API is to complicated: most applications opens single sound
> stream.
FUD and nonsense. I've written many DSP applications and very often I
can
recycle the same code for use in them. Here's an example, abstracted,
commented, handling errors from the subsystem, in just over 100 LOC.
http://devzero.co.uk/~alistair/alsa/
The API is really _only_ complicated because it expects you to set thin
gs OSS
either can't handle or doesn't allow you to configure. Things that very
often
an application will eventually care about. All this for the sake of 5 m
inutes
reading documentation, and each API call almost identical in design.
Personally, I found the lack of documentation for some of the setup API
annoying, but it's since been rectified and each call is humanly
understandable.
--
Cheers,
Alistair.
'No sense being pessimistic, it probably wouldn't work anyway.'
Third year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
Stefan Smietanowski
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
tapas
Tomasz Kłoczko <klo...@rudy.mif.pg.gda.pl> wrote:
> After four years ALSA development quality of sound support in Linux i
s IMO
> on the ~same (still bad) level as four years ago. Still to complicate
d
> but now more bloated and additionaly not ready for handle fancy gadge
ts
> 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:
-- 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.
- 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
FUSE to redirect OSS access to userspace. I suppose oss2jack could be
modified to use ALSA instead of jack.
-- ALSA's default open mode is "blocking". But the ALSA API uses the
term blocking in two meanings and throws them together into the open
mode of a pcm device. Normally on device files, blocking access means a
read()/write() returns, when there's data which has actually been
read/written to the device. nonblocking access means, read()/write()
return immediately. In ALSA blocking mode means above _plus_ that the
open call will only immediately return (in case of contention) when the
previous user of the audio device has given it up.
The combination of the last two is deadly :) It leaves users with
nonfunctional sound plus seemingly hanging apps when their soundcard is
not hardware mixing capable. So IMHO, to fix these two issues really is
the most pressing matter of all, but like i said, sadly ALSA devs seem
to disagree (i haven't followed ALSA development that closely lately
though).
> On other systems (MOX, Win*, Solaris ..) on handle sound situations i
s now
> better than four years ago. IMO this allow form conclution: generaly
> current ALSA is step back compare to other systems and probaly Linux
need
> some deeper work then simple polishing sound device drivers.
ALSA is a definitive step forward from OSS. It even is superior to the
original windows sound system (except for ease of configuration - but
windows had no interapp midi routing (extra software needed) plus you
need another audio device driver system (ASIO) to get reliable low
latency operation, and even there it still sucks compared to
linux/ALSA/jack/-rt). MAC OS X almost got it right. Their design has
another drawback though which makes OS X always have ca. 1 period of
latency more. I.e. in terms of low latency operation for musicians with
jackd and -rt kernels, linux is ATM the _superior_ platform.
It is, when setup correctly simply a joy to work with and make music
with.
Regards,
Florian Schmidt
Pete Zaitcev
> > 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
Pete Zaitcev
> 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.
Jaroslav Kysela
> On Tue, 3 Jan 2006 14:01:40 +0000, Alistair John Strachan <s034...@sms.ed.ac.uk> wrote:
>
> > Is multiple-source mixing really a "high end" requirement? When I last
> > checked, the OSS driver didn't support multiple applications claiming it at
> > once, thus requiring you to use "more bloat" like esound, arts, or some other
> > crap to access your soundcard more than once at any given time.
>
> If ALSA's OSS emulator does not support mixing properly, it's a bug
> in ALSA, clearly, because real OSS in 2.4 allowed for mixing, as long
> as the hardware supported it. I played Doom while listening to MP3s on
> ymfpci (which, in fact, was a copy of ALSA's ymfpci with OSS API on top).
>
> If ALSA developers wanted, they could have supported mixing in their OSS
> emulator. They intentionally chose not to, in order to create an incentive
> for developers to program in native ALSA.
You're in a mistake. ALSA supported multi-open feature for the hardware
capable devices as first before any OSS drivers and it's available for the
OSS emulation, too.
The thread is about simple hardware without this capability, so the mixing
must be processed in software.
Jaroslav
-----
Jaroslav Kysela <pe...@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
Jaroslav Kysela
> On Wed, 4 Jan 2006 09:37:55 +0000, Alistair John Strachan <s034...@sms.ed.ac.uk> wrote:
>
> > > 2) ALSA API is to complicated: most applications opens single sound
> > > stream.
> >
> > FUD and nonsense. []
> > http://devzero.co.uk/~alistair/alsa/
>
> That's the kicker, isn't it? Once you get used to it, it's a workable
> API, if kinky and verbose. I have a real life example, too:
> http://people.redhat.com/zaitcev/linux/mpg123-0.59r-p3.diff
> But arriving on the solution costed a lot of torn hair. Look at this
> bald head here! And who is going to pay my medical bills when ALSA
> causes me ulcers, Jaroslav?
Well, the ALSA primary goal is to be the complete HAL not hidding the
extra hardware capabilities to applications. So API might look a bit
complicated for the first glance, but the ALSA interface code for simple
applications is not so big, isn't?
Also, note that app developers are not forced to use ALSA directly - there
is a lot of "portable" sound API libraries having an ALSA backend doing
this job quite effectively. We can add a simple (like OSS) API layer
into alsa-lib, but I'm not sure, if it's worth to do it. Perhaps, adding
some support functions for the easy PCM device initialization might be
a good idea.
Jaroslav
-----
Jaroslav Kysela <pe...@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
Takashi Iwai
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