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
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
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
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
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
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 <[email protected]>
*
Why was a new OSS driver written and accepted at such a late date, when
OSS was already deprecated?
Lee
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 <[email protected]>
> *
>
> 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
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 <[email protected]>
> > *
> >
> > 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
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 <[email protected]>
>> *
>>
>>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
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
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
Adrian Bunk <[email protected]> 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
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
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
On 1/19/06, Adrian Bunk <[email protected]> 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 <[email protected]>
--
Jesper Juhl <[email protected]>
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
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.
On Thu, Jan 19, 2006 at 10:06:47PM +0100, Jesper Juhl wrote:
> On 1/19/06, Adrian Bunk <[email protected]> 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 <[email protected]>
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
Lee Revell ([email protected]) 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
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.
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 <[email protected]>
> > > *
> > >
> > > 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.
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 <[email protected]>
> *
>
> 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
On Thu, Jan 19, 2006 at 04:50:08PM -0500, Bill Nottingham wrote:
> Lee Revell ([email protected]) 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
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.
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
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
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
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
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
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
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
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
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--
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.
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.
Krzysztof Halasa wrote:
> Adrian Bunk <[email protected]> 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
On Fri, Jan 20, 2006 at 09:25:50AM +0100, Clemens Ladisch wrote:
> Krzysztof Halasa wrote:
>
> > Adrian Bunk <[email protected]> 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
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 <[email protected]>
> > > > *
> > > >
> > > > 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
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 <[email protected]>
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
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.
Krzysztof Halasa wrote:
> Adrian Bunk <[email protected]> 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.
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
>> > 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
--
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
>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
--
>> > 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
--
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
Krzysztof Halasa wrote:
> Adrian Bunk <[email protected]> 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
[email protected]
-----------------------------------------------------------------------
>> >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
--
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
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
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
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.
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.
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 <[email protected]>
> 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
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
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.
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 <[email protected]>
> > 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
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
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 <[email protected]>
> > > 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
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
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
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
>> 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
--
>> 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
--
>> 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
--
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 <[email protected]>
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
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
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
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
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
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
<http://www.amd.com/embeddedprocessors>
* Adrian Bunk <[email protected]> [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/