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

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

[Peter Zubaj]

Hi,

I think many of sb live and emu10k1 driver will not like alsa sb live
mixer.

Peter Zubaj



___________________________________________________________________________
Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete.
http://www.wanda.sk/



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

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

[James Courtier-Dutton]

Peter Zubaj wrote:
> Hi,
> 
> I think many of sb live and emu10k1 driver will not like alsa sb live
> mixer.
> 
> Peter Zubaj
> 
> 

Do you have a specific example?



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

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

[Peter Zubaj]

>Do you have a specific example? 

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

and abstract mixer layer will not solve all problems (PCM volume
control is after Tone control - should be before).

Peter Zubaj


___________________________________________________________________________
Podte na navstevu k Wande - k najlepsej priatelke kazdej zeny na internete.
http://www.wanda.sk/



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

[2.6 patch] schedule obsolete OSS drivers for removal

[Adrian Bunk]

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


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

---

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

Please tell if any my driver selections is wrong.

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

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

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

[Thorsten Knabe]

On Tue, 26 Jul 2005, Adrian Bunk wrote:

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

Hello Adrian.

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

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

Regards
Thorsten

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

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

[Lee Revell]

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

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

Lee



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

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

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Thorsten Knabe wrote:

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

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

					Thanks,
						Jaroslav

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

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

[Adrian Bunk]

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

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

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

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

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

> 					Thanks,
> 						Jaroslav

cu
Adrian

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

-- 

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



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

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

[Thorsten Knabe]

On Fri, 29 Jul 2005, Jaroslav Kysela wrote:

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

Hello Jaroslav.

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

Regards
Thorsten

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

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

[Thorsten Knabe]

On Fri, 29 Jul 2005, Jaroslav Kysela wrote:

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

Hello Jaroslav.

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

Regards
Thorsten

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

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

[Adrian Bunk]

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

Thanks a lot!

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

> Regards
> Thorsten

TIA
Adrian

-- 

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



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

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

[Adrian Bunk]

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

Thanks a lot!

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

> Regards
> Thorsten

TIA
Adrian

-- 

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

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

[Andrew Haninger]

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

Thanks.

-Andy


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click

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

[Andrew Haninger]

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

Thanks.

-Andy

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

[Thorsten Knabe]

On Mon, 1 Aug 2005, Andrew Haninger wrote:

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

Hello.

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

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

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

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

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

Thorsten

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

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

[James Courtier-Dutton]

Thorsten Knabe wrote:

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

James



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

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

[Thorsten Knabe]

Hello.

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

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

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

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

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

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

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

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

Regards
Thorsten

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


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click

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

[Jaroslav Kysela]

On Thu, 28 Jul 2005, Thorsten Knabe wrote:

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

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

					Thanks,
						Jaroslav

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


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

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

[Alistair John Strachan]

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

I'm aware of this.

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

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

-- 
Cheers,
Alistair.

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

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

[Olivier Galibert]

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

Especially not with plugins.  Flashplayer anybody?


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

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

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

  OG.

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

[Alistair John Strachan]

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

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

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

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

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

-- 
Cheers,
Alistair.

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

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

[Olivier Galibert]

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

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

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


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

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

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

  OG.

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

[James Courtier-Dutton]

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

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

James

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


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

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

[Hannu Savolainen]

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

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

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

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

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

In OSS the application can check if an overrun/underrun has occurred and 
then make the decision to continue or abort. Most applications don't care 
about this kind of issues so all this has very limited importance.

Btw, about the subject. I would recommend quick removal of the current 
kernel OSS drivers since they are really obsolete. They are lacking all 
the development made to the OSS API during past (almost) 10 years. We are
planning to make an open source version of OSS available during this year
which will make the kernel OSS drivers unnecessary anyway.

Best regards,

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


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