RFC: OSS driver removal, a slightly different approach

RFC: OSS driver removal, a slightly different approach

[Adrian Bunk]

My proposal to remove OSS drivers where ALSA drivers for the same 
hardware exists had two reasons:

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

I'm slowly getting more and more reports for the second case.


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


My proposed timeline is:
- shortly before 2.6.16 is released:
  adjust OBSOLETE_OSS_DRIVER dependencies to match exactly the
  drivers under 1.
- from the release of 2.6.16 till the release of 2.6.17:
  approx. two months for users to report problems with the ALSA
  drivers for the same hardware
- after the release of 2.6.17 (and before 2.6.18):
  remove the subset of drivers marked at OBSOLETE_OSS_DRIVER without
  known regressions in the ALSA drivers for the same hardware


To make a long story short:

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


A small FAQ:

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

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


Please review the following list:


1. ALSA drivers for the same hardware 

SOUND_AD1889
SOUND_AD1980
SOUND_ALI5455
SOUND_AU1000
SOUND_AWE32_SYNTH
SOUND_CMPCI
SOUND_CS4232
SOUND_CS4281
SOUND_ES1370
SOUND_ES1371
SOUND_ESSSOLO1
SOUND_FORTE
SOUND_FUSION
SOUND_GUS
SOUND_HARMONY
SOUND_MAD16
SOUND_MAESTRO
SOUND_MAESTRO3
SOUND_MAUI
SOUND_OPL3SA1
SOUND_OPL3SA2
SOUND_RME96XX
SOUND_SGALAXY
SOUND_SONICVIBES
SOUND_SSCAPE
SOUND_VIA82CXXX
SOUND_WAVEFRONT
SOUND_YMFPCI


2. ALSA drivers for the same hardware with known problems

SOUND_AD1816
- ALSA #1301 (Kernel OSS emulation stops working after a few seconds
              when used with VoIP softphones)

SOUND_EMU10K1
- ALSA #1735 (OSS emulation 4-channel mode rear channels not working)

SOUND_ICH
- Alan Cox: ALSA driver lacks "support for AC97 wired touchscreens
                               and the like"

SOUND_NM256
- ALSA #328 (snd-nm256 freezes Dell Latitude LS)

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


3. no ALSA drivers for the same hardware

SOUND_ACI_MIXER
SOUND_ADLIB
SOUND_AEDSP16
SOUND_AU1550_AC97
SOUND_BCM_CS4297A
SOUND_HAL2
SOUND_IT8172
SOUND_KAHLUA
SOUND_MSNDCLAS
SOUND_MSNDPIN
SOUND_PAS
SOUND_PSS
SOUND_SB
SOUND_SH_DAC_AUDIO
SOUND_TRIX
SOUND_VIDC
SOUND_VRC5477
SOUND_VWSND
SOUND_WAVEARTIST



cu
Adrian

-- 

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

Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 18:46 +0100, Adrian Bunk wrote:
> 3. no ALSA drivers for the same hardware
> 
> SOUND_SB 

ALSA certainly does support "100% Sound Blaster compatibles (SB16/32/64,
ESS, Jazz16)", it would be a joke if it didn't...

Lee

Re: RFC: OSS driver removal, a slightly different approach

[Adrian Bunk]

On Thu, Jan 19, 2006 at 01:22:23PM -0500, Lee Revell wrote:
> On Thu, 2006-01-19 at 18:46 +0100, Adrian Bunk wrote:
> > 3. no ALSA drivers for the same hardware
> > 
> > SOUND_SB 
> 
> ALSA certainly does support "100% Sound Blaster compatibles (SB16/32/64,
> ESS, Jazz16)", it would be a joke if it didn't...

That's not the problem, I should have added an explanation:

SOUND_SB (due to SOUND_KAHLUA and SOUND_PAS)

> Lee

cu
Adrian

-- 

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

Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 19:28 +0100, Adrian Bunk wrote:
> On Thu, Jan 19, 2006 at 01:22:23PM -0500, Lee Revell wrote:
> > On Thu, 2006-01-19 at 18:46 +0100, Adrian Bunk wrote:
> > > 3. no ALSA drivers for the same hardware
> > > 
> > > SOUND_SB 
> > 
> > ALSA certainly does support "100% Sound Blaster compatibles (SB16/32/64,
> > ESS, Jazz16)", it would be a joke if it didn't...
> 
> That's not the problem, I should have added an explanation:
> 
> SOUND_SB (due to SOUND_KAHLUA and SOUND_PAS)

Are there any other cases like that?  Maybe you could indent the list to
clearly show the relationship?

Lee

Re: RFC: OSS driver removal, a slightly different approach

[Adrian Bunk]

On Thu, Jan 19, 2006 at 01:39:04PM -0500, Lee Revell wrote:
> 
> Are there any other cases like that?  Maybe you could indent the list to
> clearly show the relationship?

Updated list below.

> Lee

cu
Adrian


<--  snip  -->


1. ALSA drivers for the same hardware 

SOUND_AD1889
SOUND_AD1980
SOUND_ALI5455
SOUND_AU1000
SOUND_AWE32_SYNTH
SOUND_CMPCI
SOUND_CS4232
SOUND_CS4281
SOUND_ES1370
SOUND_ES1371
SOUND_ESSSOLO1
SOUND_FORTE
SOUND_FUSION
SOUND_GUS
SOUND_HARMONY
SOUND_MAD16
SOUND_MAESTRO
SOUND_MAESTRO3
SOUND_MAUI
SOUND_OPL3SA1
SOUND_OPL3SA2
SOUND_RME96XX
SOUND_SGALAXY
SOUND_SONICVIBES
SOUND_SSCAPE
SOUND_VIA82CXXX
SOUND_WAVEFRONT
SOUND_YMFPCI


2. ALSA drivers for the same hardware with known problems

SOUND_AD1816
- ALSA #1301 (Kernel OSS emulation stops working after a few seconds
              when used with VoIP softphones)

SOUND_EMU10K1
- ALSA #1735 (OSS emulation 4-channel mode rear channels not working)

SOUND_ICH
- Alan Cox: ALSA driver lacks "support for AC97 wired touchscreens
                               and the like"

SOUND_NM256
- ALSA #328 (snd-nm256 freezes Dell Latitude LS)

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


3. no ALSA drivers for the same hardware

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

Re: RFC: OSS driver removal, a slightly different approach

[Frédéric L. W. Meunier]

On Thu, 19 Jan 2006, Adrian Bunk wrote:

> 3. no ALSA drivers for the same hardware

Why aren't drivers like SOUND_TVMIXER listed ? That one isn't 
in ALSA, but there's a port at 
http://www.gilfillan.org/v3tv/ALSA/ . It's now the only I 
enable in OSS.

-- 
How to contact me - http://www.pervalidus.net/contact.html

Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 18:22 -0200, Frédéric L. W. Meunier wrote:
> On Thu, 19 Jan 2006, Adrian Bunk wrote:
> 
> > 3. no ALSA drivers for the same hardware
> 
> Why aren't drivers like SOUND_TVMIXER listed ? That one isn't 
> in ALSA, but there's a port at 
> http://www.gilfillan.org/v3tv/ALSA/ . It's now the only I 
> enable in OSS.
> 

Grr... why would someone bother to write a driver then not submit it or
even tell the ALSA maintainers?

Lee

Re: RFC: OSS driver removal, a slightly different approach

[Alistair John Strachan]

On Thursday 19 January 2006 20:45, Lee Revell wrote:
> On Thu, 2006-01-19 at 18:22 -0200, Frédéric L. W. Meunier wrote:
> > On Thu, 19 Jan 2006, Adrian Bunk wrote:
> > > 3. no ALSA drivers for the same hardware
> >
> > Why aren't drivers like SOUND_TVMIXER listed ? That one isn't
> > in ALSA, but there's a port at
> > http://www.gilfillan.org/v3tv/ALSA/ . It's now the only I
> > enable in OSS.
>
> Grr... why would someone bother to write a driver then not submit it or
> even tell the ALSA maintainers?

The code looks to be in pretty decent shape too. With minor changes it could 
easily get into the kernel.

Maybe somebody should contact the maintainer (added to CC).

-- 
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: RFC: OSS driver removal, a slightly different approach

[Jan Engelhardt]

>> > Why aren't drivers like SOUND_TVMIXER listed ? That one isn't
>> > in ALSA, but there's a port at
>> > http://www.gilfillan.org/v3tv/ALSA/ . It's now the only I
>> > enable in OSS.
>>
>> Grr... why would someone bother to write a driver then not submit it or
>> even tell the ALSA maintainers?

Fear of not getting it included?


Jan Engelhardt
-- 

Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Fri, 2006-01-20 at 15:19 +0100, Jan Engelhardt wrote:
> >> > Why aren't drivers like SOUND_TVMIXER listed ? That one isn't
> >> > in ALSA, but there's a port at
> >> > http://www.gilfillan.org/v3tv/ALSA/ . It's now the only I
> >> > enable in OSS.
> >>
> >> Grr... why would someone bother to write a driver then not submit it or
> >> even tell the ALSA maintainers?
> 
> Fear of not getting it included?

I doubt anyone so thin skinned would make it as far as being able to
write a working Linux driver ;-)

Anyway, what's to fear?  The worst that will happen is that the kernel
maintainers will request some changes.

Lee

Re: RFC: OSS driver removal, a slightly different approach

[Jan Engelhardt]

>> Fear of not getting it included?
>
>I doubt anyone so thin skinned would make it as far as being able to
>write a working Linux driver ;-)
>
>Anyway, what's to fear?  The worst that will happen is that the kernel
>maintainers will request some changes.

"We are the Linux developers. Lower your license and surrender
your code. We will add your code to our kernel. Your code will
be adapted to CodingStyle. Resistance is futile."


Jan Engelhardt
-- 

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 19:28 +0100, Adrian Bunk wrote:
> On Thu, Jan 19, 2006 at 01:22:23PM -0500, Lee Revell wrote:
> > On Thu, 2006-01-19 at 18:46 +0100, Adrian Bunk wrote:
> > > 3. no ALSA drivers for the same hardware
> > > 
> > > SOUND_SB 
> > 
> > ALSA certainly does support "100% Sound Blaster compatibles (SB16/32/64,
> > ESS, Jazz16)", it would be a joke if it didn't...
> 
> That's not the problem, I should have added an explanation:
> 
> SOUND_SB (due to SOUND_KAHLUA and SOUND_PAS)
> 

Hmm.  From sound/oss/kahlua.c:

/*
 *      Initialisation code for Cyrix/NatSemi VSA1 softaudio
 *
 *      (C) Copyright 2003 Red Hat Inc <alan@redhat.com>
 *

Why was a new OSS driver written and accepted at such a late date, when
OSS was already deprecated?

Lee

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Takashi Iwai]

At Thu, 19 Jan 2006 13:54:45 -0500,
Lee Revell wrote:
> 
> On Thu, 2006-01-19 at 19:28 +0100, Adrian Bunk wrote:
> > On Thu, Jan 19, 2006 at 01:22:23PM -0500, Lee Revell wrote:
> > > On Thu, 2006-01-19 at 18:46 +0100, Adrian Bunk wrote:
> > > > 3. no ALSA drivers for the same hardware
> > > > 
> > > > SOUND_SB 
> > > 
> > > ALSA certainly does support "100% Sound Blaster compatibles (SB16/32/64,
> > > ESS, Jazz16)", it would be a joke if it didn't...
> > 
> > That's not the problem, I should have added an explanation:
> > 
> > SOUND_SB (due to SOUND_KAHLUA and SOUND_PAS)
> > 
> 
> Hmm.  From sound/oss/kahlua.c:
> 
> /*
>  *      Initialisation code for Cyrix/NatSemi VSA1 softaudio
>  *
>  *      (C) Copyright 2003 Red Hat Inc <alan@redhat.com>
>  *
> 
> Why was a new OSS driver written and accepted at such a late date, when
> OSS was already deprecated?

You'll find out that it must be pretty easy to write kahlua driver for
ALSA, too, if you look at kahlua.c.  Just need a hardware to certify
if this is really demanded...


Takashi

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 20:04 +0100, Takashi Iwai wrote:
> At Thu, 19 Jan 2006 13:54:45 -0500,
> Lee Revell wrote:
> > 
> > On Thu, 2006-01-19 at 19:28 +0100, Adrian Bunk wrote:
> > > On Thu, Jan 19, 2006 at 01:22:23PM -0500, Lee Revell wrote:
> > > > On Thu, 2006-01-19 at 18:46 +0100, Adrian Bunk wrote:
> > > > > 3. no ALSA drivers for the same hardware
> > > > > 
> > > > > SOUND_SB 
> > > > 
> > > > ALSA certainly does support "100% Sound Blaster compatibles (SB16/32/64,
> > > > ESS, Jazz16)", it would be a joke if it didn't...
> > > 
> > > That's not the problem, I should have added an explanation:
> > > 
> > > SOUND_SB (due to SOUND_KAHLUA and SOUND_PAS)
> > > 
> > 
> > Hmm.  From sound/oss/kahlua.c:
> > 
> > /*
> >  *      Initialisation code for Cyrix/NatSemi VSA1 softaudio
> >  *
> >  *      (C) Copyright 2003 Red Hat Inc <alan@redhat.com>
> >  *
> > 
> > Why was a new OSS driver written and accepted at such a late date, when
> > OSS was already deprecated?
> 
> You'll find out that it must be pretty easy to write kahlua driver for
> ALSA, too, if you look at kahlua.c.  Just need a hardware to certify
> if this is really demanded...

Yes, it looks simple enough to write a driver without the hardware, as
long as someone volunteers to test it...

Lee

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Alan Cox]

On Iau, 2006-01-19 at 14:01 -0500, Lee Revell wrote:
> > > Hmm.  From sound/oss/kahlua.c:
> > > 
> > > /*
> > >  *      Initialisation code for Cyrix/NatSemi VSA1 softaudio
> > >  *
> > >  *      (C) Copyright 2003 Red Hat Inc <alan@redhat.com>
> > >  *
> > > 
> > > Why was a new OSS driver written and accepted at such a late date, when
> > > OSS was already deprecated?
> > 
> > You'll find out that it must be pretty easy to write kahlua driver for
> > ALSA, too, if you look at kahlua.c.  Just need a hardware to certify
> > if this is really demanded...
> 
> Yes, it looks simple enough to write a driver without the hardware, as
> long as someone volunteers to test it...

Most of the Kahlua logic is in the SB driver. It was a wrapper added
later to make autoconfiguration simple for end users. CS55x0 (VSA1
variants) are generic sound blaster 16 emulation via SMI traps. There
are certain things you must not do

1.	Use a 64K or 128K in 16bit ring buffer
2.	Disable/Enable DMA on the sound channel while audio is running

#1 causes the box to hang dead (firmware emulation bug)
#2 mistakenly flushes the FIFOs so breaks up the audio

Otherwise its SB16 compatible.

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Takashi Iwai]

At Thu, 19 Jan 2006 22:09:33 +0000,
Alan Cox wrote:
> 
> On Iau, 2006-01-19 at 14:01 -0500, Lee Revell wrote:
> > > > Hmm.  From sound/oss/kahlua.c:
> > > > 
> > > > /*
> > > >  *      Initialisation code for Cyrix/NatSemi VSA1 softaudio
> > > >  *
> > > >  *      (C) Copyright 2003 Red Hat Inc <alan@redhat.com>
> > > >  *
> > > > 
> > > > Why was a new OSS driver written and accepted at such a late date, when
> > > > OSS was already deprecated?
> > > 
> > > You'll find out that it must be pretty easy to write kahlua driver for
> > > ALSA, too, if you look at kahlua.c.  Just need a hardware to certify
> > > if this is really demanded...
> > 
> > Yes, it looks simple enough to write a driver without the hardware, as
> > long as someone volunteers to test it...
> 
> Most of the Kahlua logic is in the SB driver. It was a wrapper added
> later to make autoconfiguration simple for end users. CS55x0 (VSA1
> variants) are generic sound blaster 16 emulation via SMI traps. There
> are certain things you must not do
> 
> 1.	Use a 64K or 128K in 16bit ring buffer
> 2.	Disable/Enable DMA on the sound channel while audio is running
> 
> #1 causes the box to hang dead (firmware emulation bug)
> #2 mistakenly flushes the FIFOs so breaks up the audio
> 
> Otherwise its SB16 compatible.

Thanks for good hints.

BTW, I remember that there was a driver for native geode audio support
at the time of ALSA 0.5.x or earlier.  I must have the code somewhere
in my storage.  The porting would be much much harder than kaulha (sb 
emulation), though.


Takashi

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Alan Cox]

On Gwe, 2006-01-20 at 11:20 +0100, Takashi Iwai wrote:
> BTW, I remember that there was a driver for native geode audio support
> at the time of ALSA 0.5.x or earlier.  I must have the code somewhere
> in my storage.  The porting would be much much harder than kaulha (sb 
> emulation), though.

The two drivers cover different versions of the Kahlua firmware. VSA1
was the original (at least AFAIK) firmware block. It provides SB16
emulation but has no hooks for drivers to 'take over' properly as you
really want to hook into SMI. VSA2 (the next gen firmware) had various
changes and differences and Cyrix long ago released a rather icky but
working 'native' driver for that.

I have the Cyrix public and most of the earlier NDA documentation if
there are questions but I can't redistribute it.

Alan

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Takashi Iwai]

At Fri, 20 Jan 2006 13:14:58 +0000,
Alan Cox wrote:
> 
> On Gwe, 2006-01-20 at 11:20 +0100, Takashi Iwai wrote:
> > BTW, I remember that there was a driver for native geode audio support
> > at the time of ALSA 0.5.x or earlier.  I must have the code somewhere
> > in my storage.  The porting would be much much harder than kaulha (sb 
> > emulation), though.
> 
> The two drivers cover different versions of the Kahlua firmware. VSA1
> was the original (at least AFAIK) firmware block. It provides SB16
> emulation but has no hooks for drivers to 'take over' properly as you
> really want to hook into SMI. VSA2 (the next gen firmware) had various
> changes and differences and Cyrix long ago released a rather icky but
> working 'native' driver for that.
> 
> I have the Cyrix public and most of the earlier NDA documentation if
> there are questions but I can't redistribute it.

The datasheet of CS5530A can be easily found on web, but not sure
whether it contains enough details since I've not looked throught
it.


Takashi

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[David Vrabel]

Takashi Iwai wrote:
> At Thu, 19 Jan 2006 13:54:45 -0500,
> Lee Revell wrote:
> 
>>On Thu, 2006-01-19 at 19:28 +0100, Adrian Bunk wrote:
>>
>>>On Thu, Jan 19, 2006 at 01:22:23PM -0500, Lee Revell wrote:
>>>
>>>>On Thu, 2006-01-19 at 18:46 +0100, Adrian Bunk wrote:
>>>>
>>>>>3. no ALSA drivers for the same hardware
>>>>>
>>>>>SOUND_SB 
>>>>
>>>>ALSA certainly does support "100% Sound Blaster compatibles (SB16/32/64,
>>>>ESS, Jazz16)", it would be a joke if it didn't...
>>>
>>>That's not the problem, I should have added an explanation:
>>>
>>>SOUND_SB (due to SOUND_KAHLUA and SOUND_PAS)
>>>
>>
>>Hmm.  From sound/oss/kahlua.c:
>>
>>/*
>> *      Initialisation code for Cyrix/NatSemi VSA1 softaudio
>> *
>> *      (C) Copyright 2003 Red Hat Inc <alan@redhat.com>
>> *
>>
>>Why was a new OSS driver written and accepted at such a late date, when
>>OSS was already deprecated?
> 
> 
> You'll find out that it must be pretty easy to write kahlua driver for
> ALSA, too, if you look at kahlua.c.  Just need a hardware to certify
> if this is really demanded...

Is this the audio on the Cyrix MediaGX (later National Semiconductor 
Geode GXm)?  I have access to hardware with that CPUs that I can test 
with if someone wants to write an ALSA driver. Er... though I'm not sure 
what VSA version the BIOS has.

I seem to recall that the Soundblaster 16 emulation provided by the VSA 
code worked fine so perhaps this can be dropped entirely.  I've not 
touched a MediaGX based board in many years so I may be remembering 
incorrectly.  The Soundblaster 16 emulation does work fine on AMD Geode 
GX1 boards.

David Vrabel

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Alan Cox]

On Iau, 2006-01-19 at 13:54 -0500, Lee Revell wrote:
> /*
>  *      Initialisation code for Cyrix/NatSemi VSA1 softaudio
>  *
>  *      (C) Copyright 2003 Red Hat Inc <alan@redhat.com>
>  *
> 
> Why was a new OSS driver written and accepted at such a late date, when
> OSS was already deprecated?

Because
	1.	I wanted the support
	2.	It was needed for my employers systems which like everyone else were
still OSS at the time

Welcome to the *real world*

Alan

Re: RFC: OSS driver removal, a slightly different approach

[Alan Cox]

On Iau, 2006-01-19 at 19:28 +0100, Adrian Bunk wrote:
> > ALSA certainly does support "100% Sound Blaster compatibles (SB16/32/64,
> > ESS, Jazz16)", it would be a joke if it didn't...
> 
> That's not the problem, I should have added an explanation:


OSS supports several "not quite compatibles", notably Cyrix 55x0 systems
where the SB firmware blows up on 64/128K transfers. 

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Peter Zubaj]

Hi,

On Thursday 19 January 2006 18:46, Adrian Bunk wrote:
> SOUND_EMU10K1
> - ALSA #1735 (OSS emulation 4-channel mode rear channels not working)

If I understand alsa - oss emulation correctly, I think, this will be not 
fixed soon (my opinion - never). This is too much work for too little gain.

Peter Zubaj

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Jan Engelhardt]

>Hi,
>
>On Thursday 19 January 2006 18:46, Adrian Bunk wrote:
>> SOUND_EMU10K1
>> - ALSA #1735 (OSS emulation 4-channel mode rear channels not working)
>
>If I understand alsa - oss emulation correctly, I think, this will be not 
>fixed soon (my opinion - never). This is too much work for too little gain.

On that way, I'd like to inquiry something:
I have a card that works with the snd-cs46xx module.
With the OSS emulation (/dev/dsp), I can only output 2 channels, and the 
other two must be sent to /dev/adsp. Is this intended? Would not it be 
easier to make /dev/dsp allow receiving an ioctl setting 4 channels?


Jan Engelhardt
-- 

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Takashi Iwai]

At Fri, 20 Jan 2006 15:25:54 +0100 (MET),
Jan Engelhardt wrote:
> 
> >Hi,
> >
> >On Thursday 19 January 2006 18:46, Adrian Bunk wrote:
> >> SOUND_EMU10K1
> >> - ALSA #1735 (OSS emulation 4-channel mode rear channels not working)
> >
> >If I understand alsa - oss emulation correctly, I think, this will be not 
> >fixed soon (my opinion - never). This is too much work for too little gain.
> 
> On that way, I'd like to inquiry something:
> I have a card that works with the snd-cs46xx module.
> With the OSS emulation (/dev/dsp), I can only output 2 channels, and the 
> other two must be sent to /dev/adsp. Is this intended? Would not it be 
> easier to make /dev/dsp allow receiving an ioctl setting 4 channels?

This is exactly like the case of emu10k1.  The chip supports only
2-channel stereo streams.  If you need a 4-channel interleaved stream,
you have to merge the data in two individual streams to a single
4-channel stream on software.  Currently, this isn't handled in ALSA
kernel-space OSS emulation.


Takashi

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Jan Engelhardt]

>> >If I understand alsa - oss emulation correctly, I think, this will be not 
>> >fixed soon (my opinion - never). This is too much work for too little gain.
>> 
>> On that way, I'd like to inquiry something:
>> I have a card that works with the snd-cs46xx module.
>> With the OSS emulation (/dev/dsp), I can only output 2 channels, and the 
>> other two must be sent to /dev/adsp. Is this intended? Would not it be 
>> easier to make /dev/dsp allow receiving an ioctl setting 4 channels?
>
>This is exactly like the case of emu10k1.  The chip supports only
>2-channel stereo streams.  If you need a 4-channel interleaved stream,
>you have to merge the data in two individual streams to a single
>4-channel stream on software.  Currently, this isn't handled in ALSA
>kernel-space OSS emulation.

Ah, so http://alphagate.hopto.org/quad_dsp/ which I had created
is The Right Thing?


Jan Engelhardt
-- 

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Peter Zubaj]

On Friday 20 January 2006 17:30, Jan Engelhardt wrote:
> >> >If I understand alsa - oss emulation correctly, I think, this will be
> >> > not fixed soon (my opinion - never). This is too much work for too
> >> > little gain.
> >>
> >> On that way, I'd like to inquiry something:
> >> I have a card that works with the snd-cs46xx module.
> >> With the OSS emulation (/dev/dsp), I can only output 2 channels, and the
> >> other two must be sent to /dev/adsp. Is this intended? Would not it be
> >> easier to make /dev/dsp allow receiving an ioctl setting 4 channels?
> >
> >This is exactly like the case of emu10k1.  The chip supports only
> >2-channel stereo streams.  If you need a 4-channel interleaved stream,
> >you have to merge the data in two individual streams to a single
> >4-channel stream on software.  Currently, this isn't handled in ALSA
> >kernel-space OSS emulation.
>
> Ah, so http://alphagate.hopto.org/quad_dsp/ which I had created
> is The Right Thing?

This will work for your card, but not for emu10k1.

Peter Zubaj

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Jan Engelhardt]

>> Ah, so http://alphagate.hopto.org/quad_dsp/ which I had created
>> is The Right Thing?
>
>This will work for your card, but not for emu10k1.

Does emu10k1 provide no adsp, how does it work?


Jan Engelhardt
-- 

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Jaroslav Kysela]

On Sat, 21 Jan 2006, Jan Engelhardt wrote:

> >> Ah, so http://alphagate.hopto.org/quad_dsp/ which I had created
> >> is The Right Thing?
> >
> >This will work for your card, but not for emu10k1.
> 
> Does emu10k1 provide no adsp, how does it work?

It supports multi-open and then the application can set channel routing 
specific per file descriptor (alsa-lib does this setup for user offering 
only abstract device names like front, rear, center_lfe, surround40, 
surround51 etc.).

						Jaroslav

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

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Fri, 2006-01-20 at 15:25 +0100, Jan Engelhardt wrote:
> >Hi,
> >
> >On Thursday 19 January 2006 18:46, Adrian Bunk wrote:
> >> SOUND_EMU10K1
> >> - ALSA #1735 (OSS emulation 4-channel mode rear channels not working)
> >
> >If I understand alsa - oss emulation correctly, I think, this will be not 
> >fixed soon (my opinion - never). This is too much work for too little gain.
> 
> On that way, I'd like to inquiry something:
> I have a card that works with the snd-cs46xx module.
> With the OSS emulation (/dev/dsp), I can only output 2 channels, and the 
> other two must be sent to /dev/adsp. Is this intended? Would not it be 
> easier to make /dev/dsp allow receiving an ioctl setting 4 channels?
> 

Why can't you just use aoss?

Lee

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Jan Engelhardt]

>> I have a card that works with the snd-cs46xx module.
>> With the OSS emulation (/dev/dsp), I can only output 2 channels, and the 
>> other two must be sent to /dev/adsp. Is this intended? Would not it be 
>> easier to make /dev/dsp allow receiving an ioctl setting 4 channels?
>
>Why can't you just use aoss?

Did not know it before.


Jan Engelhardt
-- 

Re: RFC: OSS driver removal, a slightly different approach

[Krzysztof Halasa]

Adrian Bunk <bunk@stusta.de> writes:

> 1. ALSA drivers for the same hardware 

[ a list of relatively modern cards, mostly PCI-based ]

> 2. ALSA drivers for the same hardware with known problems

[ same here ]


> 3. no ALSA drivers for the same hardware
>
> SOUND_ACI_MIXER

Never heard

> SOUND_ADLIB

IIRC 8-bit sound, ISA. GUS on DOS used to emulate it

> SOUND_AEDSP16

Never heard

> SOUND_AU1550_AC97

Never heard but ac97 suggests it's not that old

> SOUND_BCM_CS4297A
> SOUND_HAL2
> SOUND_IT8172
> SOUND_KAHLUA

Kahlua is a liquor in Mexico named after some ancient (Mayan or Aztec)
deity :-)

> SOUND_MSNDCLAS
> SOUND_MSNDPIN

Turtle Beach, I think it's newer than (at least the original) GUS.

> SOUND_PAS

Pro Audio Spectrum. Earlier than GUS? 8-bit I think

> SOUND_PSS
> SOUND_SB

The original one (8-bit)? Not sure about relation to Kahlua and PAS

> SOUND_SH_DAC_AUDIO
> SOUND_TRIX
> SOUND_VIDC
> SOUND_VRC5477
> SOUND_VWSND
> SOUND_WAVEARTIST

Look strange.


Don't you all think a large part (if not most) of the "ALSA-unsupported"
cards is no longed in any (Linux-related) use? I wouldn't be surprised
if they just don't exist anymore. Who is to write drivers for them and -
more importantly - who can test them?

The oldest card I currently have is (the original) GUS, it has 16-bit
DACs (and 8-bit ADC) and it's long dead (never bothered to fix it but
I think it could be easy). And I see it would be supported.

My oldest working (or at least installed) card is SB64 ISA, and it's
supported too. Yes, I have few junk-grade machines here.
-- 
Krzysztof Halasa

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 21:24 +0100, Krzysztof Halasa wrote:
> Don't you all think a large part (if not most) of the
> "ALSA-unsupported"
> cards is no longed in any (Linux-related) use? I wouldn't be surprised
> if they just don't exist anymore. Who is to write drivers for them and
> -
> more importantly - who can test them? 

Yes, it would require a collector of ancient sound hardware... do you
know anyone like that?

Even the NeoMagic 256 which is a Pentium II era device and was in
widespread use we cannot find a tester for.

Lee

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Bill Nottingham]

Lee Revell (rlrevell@joe-job.com) said: 
> Yes, it would require a collector of ancient sound hardware... do you
> know anyone like that?

If someone desparately wants a AdLib or PAS16 I might be able to
scrounge one up. However, are there really users out there
insisting that their Linux experience is suffering because they
don't have support for their 8-bit ISA FM synth card?

Bill

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Adrian Bunk]

On Thu, Jan 19, 2006 at 04:50:08PM -0500, Bill Nottingham wrote:
> Lee Revell (rlrevell@joe-job.com) said: 
> > Yes, it would require a collector of ancient sound hardware... do you
> > know anyone like that?
> 
> If someone desparately wants a AdLib or PAS16 I might be able to
> scrounge one up. However, are there really users out there
> insisting that their Linux experience is suffering because they
> don't have support for their 8-bit ISA FM synth card?

Half of the cards without ALSA drivers are ancient PC hardware and the 
other half are drivers for !i386 platforms.

Me scheduling other OSS drivers for removal brought me indirectly in
contact with two users of SOUND_TRIX and one user of SOUND_VIDC - and 
I'd assume that most of such hardware has some users somewhere.

I don't consider it a big problem if a handful OSS drivers for obscure 
hardware will stay forever (although getting ALSA drivers for all 
hardware would be the superior solution).

We are already able to both remove a serious amount of code and getting 
many bug reports against the ALSA drivers without removing support for a 
single piece of hardware.

> Bill

cu
Adrian

-- 

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

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Alan Cox]

On Iau, 2006-01-19 at 15:43 -0500, Lee Revell wrote:
> Even the NeoMagic 256 which is a Pentium II era device and was in
> widespread use we cannot find a tester for.

There are plenty of neomagic audio users around, I've seen bug reports
about neomagic + ALSA hangs that have been filed.

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 22:18 +0000, Alan Cox wrote:
> On Iau, 2006-01-19 at 15:43 -0500, Lee Revell wrote:
> > Even the NeoMagic 256 which is a Pentium II era device and was in
> > widespread use we cannot find a tester for.
> 
> There are plenty of neomagic audio users around, I've seen bug reports
> about neomagic + ALSA hangs that have been filed.
> 

I should have been more specific - we need a tester who is skilled
enough to help us track down the bug.

Lee

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Dave Jones]

On Thu, Jan 19, 2006 at 10:18:55PM +0000, Alan Cox wrote:
 > On Iau, 2006-01-19 at 15:43 -0500, Lee Revell wrote:
 > > Even the NeoMagic 256 which is a Pentium II era device and was in
 > > widespread use we cannot find a tester for.
 > 
 > There are plenty of neomagic audio users around, I've seen bug reports
 > about neomagic + ALSA hangs that have been filed.

They should be pretty easy to track down. Search for bug reports
with "Dell Latitude hangs" :-)

Here's three from Fedora bugzilla to start with..
http://tinyurl.com/dcy3e

(The bug is long-since fixed, but the reporters may still have the
 hardware and be willing to provide feedback to ALSA developers)

		Dave

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 17:42 -0500, Dave Jones wrote:
> 
> (The bug is long-since fixed, but the reporters may still have the
>  hardware and be willing to provide feedback to ALSA developers)
> 

The status is we need someone who has the hardware who can add printk's
to the driver to identify what triggers the hang.  It should not be
hard, the OSS driver reportedly works.

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

The bug has been in FEEDBACK state for a long time.

Lee

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Alan Cox]

On Iau, 2006-01-19 at 17:51 -0500, Lee Revell wrote:
> The status is we need someone who has the hardware who can add printk's
> to the driver to identify what triggers the hang.  It should not be
> hard, the OSS driver reportedly works.
> 
> https://bugtrack.alsa-project.org/alsa-bug/view.php?id=328
> 
> The bug has been in FEEDBACK state for a long time.

99.9% of users don't ever look in ALSA bugzilla. 

A dig shows

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157371
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171221

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Dave Jones]

On Fri, Jan 20, 2006 at 01:13:47AM +0000, Alan Cox wrote:
 > On Iau, 2006-01-19 at 17:51 -0500, Lee Revell wrote:
 > > The status is we need someone who has the hardware who can add printk's
 > > to the driver to identify what triggers the hang.  It should not be
 > > hard, the OSS driver reportedly works.
 > > 
 > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=328
 > > 
 > > The bug has been in FEEDBACK state for a long time.
 > 
 > 99.9% of users don't ever look in ALSA bugzilla. 
 > 
 > A dig shows
 > 
 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157371
 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171221

Lee, if you can point me at a patch with debugging printk's I'm
happy to throw that into the next Fedora test update for the
users in the latter bug to test. (The first one seemed to go AWOL)

		Dave

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Takashi Iwai]

At Thu, 19 Jan 2006 20:34:02 -0500,
Dave Jones wrote:
> 
> On Fri, Jan 20, 2006 at 01:13:47AM +0000, Alan Cox wrote:
>  > On Iau, 2006-01-19 at 17:51 -0500, Lee Revell wrote:
>  > > The status is we need someone who has the hardware who can add printk's
>  > > to the driver to identify what triggers the hang.  It should not be
>  > > hard, the OSS driver reportedly works.
>  > > 
>  > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=328
>  > > 
>  > > The bug has been in FEEDBACK state for a long time.
>  > 
>  > 99.9% of users don't ever look in ALSA bugzilla. 
>  > 
>  > A dig shows
>  > 
>  > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157371
>  > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171221
> 
> Lee, if you can point me at a patch with debugging printk's I'm
> happy to throw that into the next Fedora test update for the
> users in the latter bug to test. (The first one seemed to go AWOL)

The bug for Latitude CSx should have been fixed by the following
commit:

	commit 47530cf44cb5f3945ed04a5ae65d06bf423cd97b
	Author: John W. Linville <linville@tuxdriver.com>
	Date:   Wed Oct 19 16:03:10 2005 +0200

	    [ALSA] nm256: reset workaround for Latitude CSx

This might not conver all Dell models.  In such a case, try
reset_workaround2=1.  See the section of nm256 in
ALSA-Configuration.txt for details.


Takashi

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Fri, 2006-01-20 at 12:20 +0100, Takashi Iwai wrote:
> At Thu, 19 Jan 2006 20:34:02 -0500,
> Dave Jones wrote:
> > 
> > On Fri, Jan 20, 2006 at 01:13:47AM +0000, Alan Cox wrote:
> >  > On Iau, 2006-01-19 at 17:51 -0500, Lee Revell wrote:
> >  > > The status is we need someone who has the hardware who can add printk's
> >  > > to the driver to identify what triggers the hang.  It should not be
> >  > > hard, the OSS driver reportedly works.
> >  > > 
> >  > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=328
> >  > > 
> >  > > The bug has been in FEEDBACK state for a long time.
> >  > 
> >  > 99.9% of users don't ever look in ALSA bugzilla. 
> >  > 
> >  > A dig shows
> >  > 
> >  > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157371
> >  > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171221
> > 
> > Lee, if you can point me at a patch with debugging printk's I'm
> > happy to throw that into the next Fedora test update for the
> > users in the latter bug to test. (The first one seemed to go AWOL)
> 
> The bug for Latitude CSx should have been fixed by the following
> commit:
> 
> 	commit 47530cf44cb5f3945ed04a5ae65d06bf423cd97b
> 	Author: John W. Linville <linville@tuxdriver.com>
> 	Date:   Wed Oct 19 16:03:10 2005 +0200
> 
> 	    [ALSA] nm256: reset workaround for Latitude CSx
> 
> This might not conver all Dell models.  In such a case, try
> reset_workaround2=1.  See the section of nm256 in
> ALSA-Configuration.txt for details.

OK I will update the ALSA bug report with this info.  IIRC at least one
user already reported that the above commit does not fix the hangs.

Lee

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Adrian Bunk]

On Fri, Jan 20, 2006 at 07:29:09PM -0500, Lee Revell wrote:
> On Fri, 2006-01-20 at 12:20 +0100, Takashi Iwai wrote:
> > At Thu, 19 Jan 2006 20:34:02 -0500,
> > Dave Jones wrote:
> > > 
> > > On Fri, Jan 20, 2006 at 01:13:47AM +0000, Alan Cox wrote:
> > >  > On Iau, 2006-01-19 at 17:51 -0500, Lee Revell wrote:
> > >  > > The status is we need someone who has the hardware who can add printk's
> > >  > > to the driver to identify what triggers the hang.  It should not be
> > >  > > hard, the OSS driver reportedly works.
> > >  > > 
> > >  > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=328
> > >  > > 
> > >  > > The bug has been in FEEDBACK state for a long time.
> > >  > 
> > >  > 99.9% of users don't ever look in ALSA bugzilla. 
> > >  > 
> > >  > A dig shows
> > >  > 
> > >  > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157371
> > >  > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171221
> > > 
> > > Lee, if you can point me at a patch with debugging printk's I'm
> > > happy to throw that into the next Fedora test update for the
> > > users in the latter bug to test. (The first one seemed to go AWOL)
> > 
> > The bug for Latitude CSx should have been fixed by the following
> > commit:
> > 
> > 	commit 47530cf44cb5f3945ed04a5ae65d06bf423cd97b
> > 	Author: John W. Linville <linville@tuxdriver.com>
> > 	Date:   Wed Oct 19 16:03:10 2005 +0200
> > 
> > 	    [ALSA] nm256: reset workaround for Latitude CSx
> > 
> > This might not conver all Dell models.  In such a case, try
> > reset_workaround2=1.  See the section of nm256 in
> > ALSA-Configuration.txt for details.
> 
> OK I will update the ALSA bug report with this info.  IIRC at least one
> user already reported that the above commit does not fix the hangs.

The bug reporter reported this in the last comment of the bug (1.0.10rc3 
already included the mentioned fix).

> Lee

cu
Adrian

-- 

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

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Sat, 2006-01-21 at 01:57 +0100, Adrian Bunk wrote:
> On Fri, Jan 20, 2006 at 07:29:09PM -0500, Lee Revell wrote:
> > On Fri, 2006-01-20 at 12:20 +0100, Takashi Iwai wrote:
> > > At Thu, 19 Jan 2006 20:34:02 -0500,
> > > Dave Jones wrote:
> > > > 
> > > > On Fri, Jan 20, 2006 at 01:13:47AM +0000, Alan Cox wrote:
> > > >  > On Iau, 2006-01-19 at 17:51 -0500, Lee Revell wrote:
> > > >  > > The status is we need someone who has the hardware who can add printk's
> > > >  > > to the driver to identify what triggers the hang.  It should not be
> > > >  > > hard, the OSS driver reportedly works.
> > > >  > > 
> > > >  > > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=328
> > > >  > > 
> > > >  > > The bug has been in FEEDBACK state for a long time.
> > > >  > 
> > > >  > 99.9% of users don't ever look in ALSA bugzilla. 
> > > >  > 
> > > >  > A dig shows
> > > >  > 
> > > >  > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157371
> > > >  > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171221
> > > > 
> > > > Lee, if you can point me at a patch with debugging printk's I'm
> > > > happy to throw that into the next Fedora test update for the
> > > > users in the latter bug to test. (The first one seemed to go AWOL)
> > > 
> > > The bug for Latitude CSx should have been fixed by the following
> > > commit:
> > > 
> > > 	commit 47530cf44cb5f3945ed04a5ae65d06bf423cd97b
> > > 	Author: John W. Linville <linville@tuxdriver.com>
> > > 	Date:   Wed Oct 19 16:03:10 2005 +0200
> > > 
> > > 	    [ALSA] nm256: reset workaround for Latitude CSx
> > > 
> > > This might not conver all Dell models.  In such a case, try
> > > reset_workaround2=1.  See the section of nm256 in
> > > ALSA-Configuration.txt for details.
> > 
> > OK I will update the ALSA bug report with this info.  IIRC at least one
> > user already reported that the above commit does not fix the hangs.
> 
> The bug reporter reported this in the last comment of the bug (1.0.10rc3 
> already included the mentioned fix).

They did not try "reset_workaround".  I have updated the bug report with
this advice.

Lee

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Fri, 2006-01-20 at 01:13 +0000, Alan Cox wrote:
> On Iau, 2006-01-19 at 17:51 -0500, Lee Revell wrote:
> > The status is we need someone who has the hardware who can add printk's
> > to the driver to identify what triggers the hang.  It should not be
> > hard, the OSS driver reportedly works.
> > 
> > https://bugtrack.alsa-project.org/alsa-bug/view.php?id=328
> > 
> > The bug has been in FEEDBACK state for a long time.
> 
> 99.9% of users don't ever look in ALSA bugzilla. 
> 
> A dig shows
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157371
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171221
> 

I know, we don't expect users to look in it.  But you can't expect a
handful of developers, only two of whom are paid to work on ALSA, to
track every distro's bugzilla either.  It's hard enough to keep up with
the ALSA bug tracker.

The best solution is for the distros to make sure to refer users with
ALSA problems to the ALSA bug tracker, and for the maintainers of the
distro bugzillas to properly forward bugs upstream, like Debian does.

Lee

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Dag Nygren]

> On Thu, 2006-01-19 at 21:24 +0100, Krzysztof Halasa wrote:
> > Don't you all think a large part (if not most) of the
> > "ALSA-unsupported"
> > cards is no longed in any (Linux-related) use? I wouldn't be surprised
> > if they just don't exist anymore. Who is to write drivers for them and
> > -
> > more importantly - who can test them? 
> 
> Yes, it would require a collector of ancient sound hardware... do you
> know anyone like that?
> 
> Even the NeoMagic 256 which is a Pentium II era device and was in
> widespread use we cannot find a tester for.

I could do that, my boy is still playing tuxpaint and other stuff on my old 
laptop
with such a chip.

BRGDS
Dag

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Fri, 2006-01-20 at 10:21 +0200, Dag Nygren wrote:
> > On Thu, 2006-01-19 at 21:24 +0100, Krzysztof Halasa wrote:
> > > Don't you all think a large part (if not most) of the
> > > "ALSA-unsupported"
> > > cards is no longed in any (Linux-related) use? I wouldn't be surprised
> > > if they just don't exist anymore. Who is to write drivers for them and
> > > -
> > > more importantly - who can test them? 
> > 
> > Yes, it would require a collector of ancient sound hardware... do you
> > know anyone like that?
> > 
> > Even the NeoMagic 256 which is a Pentium II era device and was in
> > widespread use we cannot find a tester for.
> 
> I could do that, my boy is still playing tuxpaint and other stuff on my old 
> laptop
> with such a chip.

Thanks!

Basically just see if you can produce a hang by repeatedly loading and
unloading snd-nm256, preferably at a console, so you can see any Oops.
If you do see the hang, try the reset_workaround options described in
ALSA-Configuration.txt.

If you can reproduce a hang add printks in the module __init code and
try to narrow down where it dies.

Lee

Re: RFC: OSS driver removal, a slightly different approach

[Alan Cox]

On Iau, 2006-01-19 at 21:24 +0100, Krzysztof Halasa wrote:
> > SOUND_ADLIB
> 
> IIRC 8-bit sound, ISA. GUS on DOS used to emulate it

Very early ISA

> > SOUND_AU1550_AC97
> 
> Never heard but ac97 suggests it's not that old

Embedded platform

> > SOUND_BCM_CS4297A
Ditto

> > SOUND_IT8172
Ditto

> > SOUND_KAHLUA
> 
> Kahlua is a liquor in Mexico named after some ancient (Mayan or Aztec)
> deity :-)
Code name for Cyrix CS5530

> Pro Audio Spectrum. Earlier than GUS? 8-bit I think
PAS16 is the 16bit system, both are prehistoric

> > SOUND_SH_DAC_AUDIO

Embedded

> > SOUND_TRIX
Old sound card

> > SOUND_VIDC
ARM

> > SOUND_VRC5477
Embedded

> > SOUND_VWSND

SGI workstation

> > SOUND_WAVEARTIST

Not sure

Re: RFC: OSS driver removal, a slightly different approach

[Adrian Bunk]

On Thu, Jan 19, 2006 at 10:21:47PM +0000, Alan Cox wrote:
> On Iau, 2006-01-19 at 21:24 +0100, Krzysztof Halasa wrote:
>...
> > > SOUND_WAVEARTIST
> 
> Not sure

config SOUND_WAVEARTIST
        tristate "Netwinder WaveArtist"
        depends on ARM && SOUND_OSS && ARCH_NETWINDER
        help
          Say Y here to include support for the Rockwell WaveArtist sound
          system.  This driver is mainly for the NetWinder.

cu
Adrian

-- 

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

Re: RFC: OSS driver removal, a slightly different approach

[Erik Andersen]

On Thu Jan 19, 2006 at 11:45:01PM +0100, Adrian Bunk wrote:
> config SOUND_WAVEARTIST
>         tristate "Netwinder WaveArtist"
>         depends on ARM && SOUND_OSS && ARCH_NETWINDER
>         help
>           Say Y here to include support for the Rockwell WaveArtist sound
>           system.  This driver is mainly for the NetWinder.

I own two netwinders (strongArm SA110) and I would be glad to
fire them up to test things if someone feels like writing a
driver....

 -Erik

--
Erik B. Andersen             http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 19:55 -0700, Erik Andersen wrote:
> On Thu Jan 19, 2006 at 11:45:01PM +0100, Adrian Bunk wrote:
> > config SOUND_WAVEARTIST
> >         tristate "Netwinder WaveArtist"
> >         depends on ARM && SOUND_OSS && ARCH_NETWINDER
> >         help
> >           Say Y here to include support for the Rockwell WaveArtist sound
> >           system.  This driver is mainly for the NetWinder.
> 
> I own two netwinders (strongArm SA110) and I would be glad to
> fire them up to test things if someone feels like writing a
> driver....

I guess you are not volunteering to do it yourself...?

If you feel like tackling this google "Writing an ALSA driver", it
basically walks you through the process, you could do it in a weekend
with the source to the OSS driver in hand.

Lee

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Lee Revell]

On Thu, 2006-01-19 at 22:21 +0000, Alan Cox wrote:
> > > SOUND_WAVEARTIST
> 
> Not sure
> 

ARM, specifically this:

http://www.netwinder.org/about.html

Lee

Re: RFC: OSS driver removal, a slightly different approach

[Rene Herman]

Krzysztof Halasa wrote:

>> SOUND_ADLIB
> 
> IIRC 8-bit sound, ISA. GUS on DOS used to emulate it

Extremely classic card. Would be fun to still have around if only for 
history's sake...

>> SOUND_PAS
> 
> Pro Audio Spectrum. Earlier than GUS? 8-bit I think

Also drives my PAS16s. Yes, it's very old -- non-pnp ISA and all that. 
Used to be a fairly popular card at the time though (since it sounds 
better than most other cards of the era) so there's still a couple of 
those around. I believe I have three lying around somewhere, one of them 
in fact still installed (in a machine that's currently not available 
though).

Sure, wouldn't be a tragedy to remove, but keeping it neither (writing 
an ALSA driver for the stupid thing has been on my personal TODO only 
slightly shorter then all the items preceding it).

>> SOUND_PSS
>> SOUND_SB
> 
> The original one (8-bit)? Not sure about relation to Kahlua and PAS

The relation to PAS16 at least is that the PAS includes a (independent) 
SB8 compatible chip. The OSS driver supplies two sound devices. At the 
moment, I'm not recalling with certainty whether or not they were also 
hardware mixed, but I guess they were...

Rene.

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Brent Cook]

On Jan 19, 2006, at 9:46 PM, Rene Herman wrote:

> Krzysztof Halasa wrote:
>
>>> SOUND_ADLIB
>> IIRC 8-bit sound, ISA. GUS on DOS used to emulate it
>
> Extremely classic card. Would be fun to still have around if only  
> for history's sake...

The Adlib card that I had was just an OPL-2 synthesizer, no PCM  
support at all. Normally, it was mono, 9 voices, 2 FM operators per  
voice + 3 noise channels, but there was a mode that supported 4  
operators and reduced the number of voices to 4 or 5.

An OPL-3 is just 2 OPL-2's, one for each stereo channel. I think that  
any card with an OPL-3 (SB-16) can act like an OPL-2, i.e. would be  
suitable for porting the driver. I really wish I still had my  
old .rol and .pat file collection; had a killer version of Bohemian  
Rhapsody.

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Stuffed Crust]

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

On Fri, Jan 20, 2006 at 01:04:30AM -0600, Brent Cook wrote:
> The Adlib card that I had was just an OPL-2 synthesizer, no PCM  
> support at all. Normally, it was mono, 9 voices, 2 FM operators per  
> voice + 3 noise channels, but there was a mode that supported 4  
> operators and reduced the number of voices to 4 or 5.

> An OPL-3 is just 2 OPL-2's, one for each stereo channel. I think that  
> any card with an OPL-3 (SB-16) can act like an OPL-2.

The OPL2 is a 2-operator mono synth, While the OPL3 can operate in a
mode that makes it appear as two OPL2s (stereo, yay!) it has a native
4-operator mode that halves the number of resultant voices, but allows
much more complex instruments, as well as crude native stereo 
capabilities.  (In the end, to do proper stereo panning you had to use 
two voices and vary the volumes directly)

Meanwhile.  The original Adlib did indeed use an OPL2, and since the
original Sound Blaster was little more than an adlib with PCM bolted on,
so did the first few Sound Blaster cards (newer ones also dropped the
CMS AM synth chip, first by making them socketed and optional, later by
eliminating the capability altogether) The Sound Blaster Pro upped the
ante to include a mixer, stereo PCM and two OPL2s, one for each channel. 
Creative Labs quickly revised the SBPro to include a single OPL3
instead, and that's also what went into the SB16 and its ilk (Vibra16,
AWE32, SB32, AWE64, with and without the CSP chip).  They dropped the FM
synthesis capability entirely when they went to PCI cards.

But I digress.

 - Solomon [I think I've used every card Creative put out in the ISA days]
-- 
Solomon Peachy        				 ICQ: 1318344
Melbourne, FL 					 
Quidquid latine dictum sit, altum viditur.

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

Re: RFC: OSS driver removal, a slightly different approach

[Jan Engelhardt]

>> > SOUND_ADLIB
>> 
>> IIRC 8-bit sound, ISA. GUS on DOS used to emulate it
>
> Extremely classic card. Would be fun to still have around if only for history's
> sake...

Given that most soundcards I had yet seem to be adlib-compatible (DOS games 
commonly have adlib output), it would not be so hard to find hardware for 
testing.


Jan Engelhardt
-- 

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Clemens Ladisch]

Krzysztof Halasa wrote:

> Adrian Bunk <bunk@stusta.de> writes:
>
> > 3. no ALSA drivers for the same hardware
> >
> > SOUND_ACI_MIXER
>
> Never heard

A chip used on miroPCM (ISA) cards.  An ALSA driver has been written for it,
and it seems the ACI stuff is supported.  (This driver is not yet in the
kernel tree.)

Martin, has your miro.c a complete implementation of what is in aci.c?


Clemens

Re: [Alsa-devel] Re: RFC: OSS driver removal, a slightly different approach

[Martin Langer]

On Fri, Jan 20, 2006 at 09:25:50AM +0100, Clemens Ladisch wrote:
> Krzysztof Halasa wrote:
> 
> > Adrian Bunk <bunk@stusta.de> writes:
> >
> > > 3. no ALSA drivers for the same hardware
> > >
> > > SOUND_ACI_MIXER
> >
> > Never heard
> 
> A chip used on miroPCM (ISA) cards.  An ALSA driver has been written for it,
> and it seems the ACI stuff is supported.  (This driver is not yet in the
> kernel tree.)
> 
> Martin, has your miro.c a complete implementation of what is in aci.c?

Not all card models are tested, yet. It could be possible that 
something is broken. There is a lack of bugreports for ISA cards...

Be aware that the driver for the radio part of the miroSOUND PCM20 
still depends on the OSS aci driver. Someone has to move those files 
drivers/media/radio/miropcm20* to ALSA. Meanwhile I got a miroSOUND 
PCM20 and so I'm still waiting that the ALSA miro driver will be moved 
into the kernel tree for doing it... 

Any plans about moving ALSA miro driver into the kernel? Or is there 
something completely wrong which has to be fixed at first?


martin

Re: RFC: OSS driver removal, a slightly different approach

[Jamie Heilman]

Krzysztof Halasa wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> > SOUND_MSNDCLAS
> > SOUND_MSNDPIN
> 
> Turtle Beach, I think it's newer than (at least the original) GUS.

Makes me sad to see this one get so stale.  The Fiji and Pinnacle
cards sounded really good and had excellent noise characteristics for
their period of manufacture.  The ALSA driver (not in the kernel tree)
has never worked for me; xruns like crazy during playback, apparently
due to a different buffering approach (aimed at lower latency) from
the OSS driver.  But support has suffered ever since 2.6 landed.  I
opened a bug on the OSS driver (http://bugme.osdl.org/show_bug.cgi?id=1709)
ages ago and it never really went anywhere.  Last time I tried the OSS
driver (even with the fixes mentioned in bug 1709) it didn't work at
all, and so I gave up on using my Fiji with newer kernels.  I have a
friend who even wrote his own pndsperm firmware to handle AC3 digital
output from his Multisound card (though he was never happy with the audio
quality).  Anyway, if some attention is given to the ALSA msnd driver
again I'd be happy to test.

Re: RFC: OSS driver removal, a slightly different approach

[Bob Tracy]

Krzysztof Halasa wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> > (...)
> > SOUND_PAS
> 
> Pro Audio Spectrum. Earlier than GUS? 8-bit I think

16-bit actually.  SoundBlaster emulation capability of various kinds
was claimed by the manufacturer, but I know of few cards of that era
that *didn't* make such claims :-).

> Don't you all think a large part (if not most) of the "ALSA-unsupported"
> cards is no longed in any (Linux-related) use? I wouldn't be surprised
> if they just don't exist anymore. Who is to write drivers for them and -
> more importantly - who can test them?

I can help out with the testing of the PAS, including the SCSI side of
the Pro Audio Studio version of the card (another can of worms that the
ALSA folks rightly have no responsibility for: it never really worked
well with Linux because the driver supported the NCR chipset in polling
mode only).

As far as other old ISA soundcards I might be able to help test, I also
have a GUS with the multiple proprietary CD-ROM interfaces on it, and a
MAUI -- the latter being in a semi-modern PIII/1000 machine running FC4.

-- 
-----------------------------------------------------------------------
Bob Tracy                   WTO + WIPO = DMCA? http://www.anti-dmca.org
rct@frus.com
-----------------------------------------------------------------------

Re: RFC: OSS driver removal, a slightly different approach

[Jesper Juhl]

On 1/19/06, Adrian Bunk <bunk@stusta.de> wrote:
[snip]
> My proposed timeline is:
[snip]
> - after the release of 2.6.17 (and before 2.6.18):
>   remove the subset of drivers marked at OBSOLETE_OSS_DRIVER without
>   known regressions in the ALSA drivers for the same hardware

May I suggest you also update the "When" part of this entry in
Documentation/feature-removal-schedule.txt :

What:   drivers depending on OBSOLETE_OSS_DRIVER
When:   January 2006
Why:    OSS drivers with ALSA replacements
Who:    Adrian Bunk <bunk@stusta.de>

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

Re: RFC: OSS driver removal, a slightly different approach

[Adrian Bunk]

On Thu, Jan 19, 2006 at 10:06:47PM +0100, Jesper Juhl wrote:
> On 1/19/06, Adrian Bunk <bunk@stusta.de> wrote:
> [snip]
> > My proposed timeline is:
> [snip]
> > - after the release of 2.6.17 (and before 2.6.18):
> >   remove the subset of drivers marked at OBSOLETE_OSS_DRIVER without
> >   known regressions in the ALSA drivers for the same hardware
> 
> May I suggest you also update the "When" part of this entry in
> Documentation/feature-removal-schedule.txt :
> 
> What:   drivers depending on OBSOLETE_OSS_DRIVER
> When:   January 2006
> Why:    OSS drivers with ALSA replacements
> Who:    Adrian Bunk <bunk@stusta.de>

Sure. This will be sent as part of my patch to update the 
OBSOLETE_OSS_DRIVER dependencies.

cu
Adrian

-- 

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

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Martin Habets]

It seems to me we can already get rid of sound/oss/dmasound now.
I cannot find anything refering to it anymore, and the ALSA powermac
driver is being maintained.

Martin

On Thu, Jan 19, 2006 at 06:46:00PM +0100, Adrian Bunk wrote:
> My proposal to remove OSS drivers where ALSA drivers for the same 
> hardware exists had two reasons:
> 
> 1. remove obsolete and mostly unmaintained code
> 2. get bugs in the ALSA drivers reported that weren't previously
>    reported due to the possible workaround of using the OSS drivers
> 
> I'm slowly getting more and more reports for the second case.
> 
> 
> The list below divides the OSS drivers into the following three 
> categories:
> 1. ALSA drivers for the same hardware
> 2. ALSA drivers for the same hardware with known problems
> 3. no ALSA drivers for the same hardware
> 
> 
> My proposed timeline is:
> - shortly before 2.6.16 is released:
>   adjust OBSOLETE_OSS_DRIVER dependencies to match exactly the
>   drivers under 1.
> - from the release of 2.6.16 till the release of 2.6.17:
>   approx. two months for users to report problems with the ALSA
>   drivers for the same hardware
> - after the release of 2.6.17 (and before 2.6.18):
>   remove the subset of drivers marked at OBSOLETE_OSS_DRIVER without
>   known regressions in the ALSA drivers for the same hardware
> 
> 
> To make a long story short:
> 
> If you are using an OSS driver because the ALSA driver doesn't work 
> equally well on your hardware, send me an email with a bug number in the 
> ALSA bug tracking system now.

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Adrian Bunk]

On Fri, Jan 20, 2006 at 11:54:43AM +0000, Martin Habets wrote:

> It seems to me we can already get rid of sound/oss/dmasound now.
> I cannot find anything refering to it anymore, and the ALSA powermac
> driver is being maintained.

You are correct that I forgot to add the dmasound drivers to my list, 
but I don't think we can get rid of all of them since I doubt the ALSA 
powermac driver was able to drive m68k hardware.

Can someone from the ppc developers drop me a small note whether 
SND_POWERMAC completely replaces DMASOUND_PMAC?

> Martin

TIA
Adrian

-- 

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

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Olaf Hering]

 On Fri, Jan 20, Adrian Bunk wrote:

 
> Can someone from the ppc developers drop me a small note whether 
> SND_POWERMAC completely replaces DMASOUND_PMAC?

It doesnt. Some tumbler models work only after one plug/unplug cycle of
the headphone. early powerbooks report/handle the mute settings
incorrectly. there are likely more bugs.

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Benjamin Herrenschmidt]

On Fri, 2006-01-20 at 22:29 +0100, Olaf Hering wrote:
>  On Fri, Jan 20, Adrian Bunk wrote:
> 
>  
> > Can someone from the ppc developers drop me a small note whether 
> > SND_POWERMAC completely replaces DMASOUND_PMAC?
> 
> It doesnt. Some tumbler models work only after one plug/unplug cycle of
> the headphone. early powerbooks report/handle the mute settings
> incorrectly. there are likely more bugs.

Interesting... Ben Collins hacked something to have Toonie work as a
"default" driver for non supported machine and saw that problem too, I
think he fixes it, I'll check with him what's up there and if his fix
applied to tumbler.c as well.

Ben.

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Ben Collins]

On Sat, 2006-01-21 at 10:16 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2006-01-20 at 22:29 +0100, Olaf Hering wrote:
> >  On Fri, Jan 20, Adrian Bunk wrote:
> > 
> >  
> > > Can someone from the ppc developers drop me a small note whether 
> > > SND_POWERMAC completely replaces DMASOUND_PMAC?
> > 
> > It doesnt. Some tumbler models work only after one plug/unplug cycle of
> > the headphone. early powerbooks report/handle the mute settings
> > incorrectly. there are likely more bugs.
> 
> Interesting... Ben Collins hacked something to have Toonie work as a
> "default" driver for non supported machine and saw that problem too, I
> think he fixes it, I'll check with him what's up there and if his fix
> applied to tumbler.c as well.

My "fix" was basically the result of converting to the platform
functions. It's hit or miss whether this works with tumbler too.

You can try the Ubuntu kernel packages (they can be unpacked and used on
non Ubuntu systems pretty easily) to see if it works for you. Tumbler
platform function conversion isn't even tested, so I'd be happy to hear
any feedback.

-- 
Ben Collins
Kernel Developer - Ubuntu Linux

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Takashi Iwai]

At Fri, 20 Jan 2006 18:22:10 -0500,
Ben Collins wrote:
> 
> On Sat, 2006-01-21 at 10:16 +1100, Benjamin Herrenschmidt wrote:
> > On Fri, 2006-01-20 at 22:29 +0100, Olaf Hering wrote:
> > >  On Fri, Jan 20, Adrian Bunk wrote:
> > > 
> > >  
> > > > Can someone from the ppc developers drop me a small note whether 
> > > > SND_POWERMAC completely replaces DMASOUND_PMAC?
> > > 
> > > It doesnt. Some tumbler models work only after one plug/unplug cycle of
> > > the headphone. early powerbooks report/handle the mute settings
> > > incorrectly. there are likely more bugs.
> > 
> > Interesting... Ben Collins hacked something to have Toonie work as a
> > "default" driver for non supported machine and saw that problem too, I
> > think he fixes it, I'll check with him what's up there and if his fix
> > applied to tumbler.c as well.
> 
> My "fix" was basically the result of converting to the platform
> functions. It's hit or miss whether this works with tumbler too.
> 
> You can try the Ubuntu kernel packages (they can be unpacked and used on
> non Ubuntu systems pretty easily) to see if it works for you. Tumbler
> platform function conversion isn't even tested, so I'd be happy to hear
> any feedback.

Don't forget to forward your patches to alsa-devel or me ;)


thanks,

Takashi

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Ben Collins]

On Mon, 2006-01-23 at 13:20 +0100, Takashi Iwai wrote:
> > > > > Can someone from the ppc developers drop me a small note whether 
> > > > > SND_POWERMAC completely replaces DMASOUND_PMAC?
> > > > 
> > > > It doesnt. Some tumbler models work only after one plug/unplug cycle of
> > > > the headphone. early powerbooks report/handle the mute settings
> > > > incorrectly. there are likely more bugs.
> > > 
> > > Interesting... Ben Collins hacked something to have Toonie work as a
> > > "default" driver for non supported machine and saw that problem too, I
> > > think he fixes it, I'll check with him what's up there and if his fix
> > > applied to tumbler.c as well.
> > 
> > My "fix" was basically the result of converting to the platform
> > functions. It's hit or miss whether this works with tumbler too.
> > 
> > You can try the Ubuntu kernel packages (they can be unpacked and used on
> > non Ubuntu systems pretty easily) to see if it works for you. Tumbler
> > platform function conversion isn't even tested, so I'd be happy to hear
> > any feedback.
> 
> Don't forget to forward your patches to alsa-devel or me ;)

I'm passing everything through to BenH, especially since it's all using
functions new in his ppc tree.

Update on this "fix", it worked only because platform function
interrupts weren't enabled. Now that they are, it's back to the same old
thing.

At least that's a clue, though.

-- 
Ben Collins
Kernel Developer - Ubuntu Linux

Re: [Alsa-devel] RFC: OSS driver removal, a slightly different approach

[Benjamin Herrenschmidt]

On Fri, 2006-01-20 at 20:04 +0100, Adrian Bunk wrote:
> On Fri, Jan 20, 2006 at 11:54:43AM +0000, Martin Habets wrote:
> 
> > It seems to me we can already get rid of sound/oss/dmasound now.
> > I cannot find anything refering to it anymore, and the ALSA powermac
> > driver is being maintained.
> 
> You are correct that I forgot to add the dmasound drivers to my list, 
> but I don't think we can get rid of all of them since I doubt the ALSA 
> powermac driver was able to drive m68k hardware.
> 
> Can someone from the ppc developers drop me a small note whether 
> SND_POWERMAC completely replaces DMASOUND_PMAC?

It should...

Ben.

Re: RFC: OSS driver removal, a slightly different approach

[Ralf Baechle]

On Thu, Jan 19, 2006 at 06:46:00PM +0100, Adrian Bunk wrote:

> 3. no ALSA drivers for the same hardware
[...]
> SOUND_AU1550_AC97
[...]
> SOUND_IT8172
[...]
> SOUND_VRC5477

I'm already hammering the responsible people to rewrite the drivers for
ALSA since a while but slow progress.  The latter two platforms have no
active maintainers so I don't expect to see ALSA drivers.

  Ralf

Re: RFC: OSS driver removal, a slightly different approach

[Dan Malek]

On Jan 21, 2006, at 4:05 PM, Ralf Baechle wrote:

> On Thu, Jan 19, 2006 at 06:46:00PM +0100, Adrian Bunk wrote:
>
>> 3. no ALSA drivers for the same hardware
> [...]
>> SOUND_AU1550_AC97

The Au1550 should have an ALSA driver.  It was done
some time ago.  Perhaps we just didn't submit it to the
proper maintainer.  I'll track that down.

	-- Dan

Re: RFC: OSS driver removal, a slightly different approach

[Jordan Crouse]

On 23/01/06 09:11 -0500, Dan Malek wrote:
> 
> On Jan 21, 2006, at 4:05 PM, Ralf Baechle wrote:
> 
> >On Thu, Jan 19, 2006 at 06:46:00PM +0100, Adrian Bunk wrote:
> >
> >>3. no ALSA drivers for the same hardware
> >[...]
> >>SOUND_AU1550_AC97
> 
> The Au1550 should have an ALSA driver.  It was done
> some time ago.  Perhaps we just didn't submit it to the
> proper maintainer.  I'll track that down.

My official position is that I would prefer an ALSA driver if exists.

Jordan

-- 
Jordan Crouse
Senior Linux Engineer
AMD - Personal Connectivity Solutions Group
<www.amd.com/embeddedprocessors>

Re: RFC: OSS driver removal, a slightly different approach

[Martin Michlmayr]

* Adrian Bunk <bunk@stusta.de> [2006-01-19 18:46]:
> SOUND_TRIDENT
> - ALSA #1293 (device supported by OSS but not by ALSA)
> - maintainer of the OSS driver wants his driver to stay

That driver generally doesn't seem very well maintained in ALSA.
I reported a bug report ages ago about a long delay when loading the
snd_ali5451 ALSA module which doesn't occur with trident but nothing
happened.  https://bugtrack.alsa-project.org/alsa-bug/view.php?id=873
-- 
Martin Michlmayr
http://www.cyrius.com/