SndConfig for Linux/PPC

SndConfig for Linux/PPC

[Jeramy B Smith]

I've been thinking about making sndconfig run on linuxppc. 
A. rip out the sun/sbus code
B. remove defs for isa cards
C. remove the defs for pci cards that don't work on linuxppc
D. add dma sound def
E. debug, debug, debug

D is giving me the most problems, i guess i shouldnt have to probe but one of
the variabes in the defs is a bustype (isa, pci, sbus). Any ideas what I should
do and what header I would need?

I think a utility like this would help people test their sound system and be
able to diagnose if their sound problems are caused by kernel driver issues or
software (esd, etc) problems.

A utility like this might even be able to incorporate Ben's work at mapping
inputs/outputs by having a machine select screen if dmasound is present. The
user would choose his machine and the correct input/output settings would be
used.


Please feel free to tell me if I'm going about this bass-ackwards ;).



Jeramy B Smith
PenguinPPC.org
jsmith@penguinppc.org

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SndConfig for Linux/PPC

[Anirudh Joshi]

	heh... funny you bring this up, cause just yesterday i decided
(was coaxed rather) to rewrite the awacs driver.  hopefully when i'm
finished, it'll be out of dmasound.c and awacs.c will be done The Right
Way (or whatever way i think is Right :).  anyhow, it'll have all the
goodies like mixer support, etc...


ani

On Fri, 24 Sep 1999, Jeramy B Smith wrote:

> 
> I've been thinking about making sndconfig run on linuxppc. 
> A. rip out the sun/sbus code
> B. remove defs for isa cards
> C. remove the defs for pci cards that don't work on linuxppc
> D. add dma sound def
> E. debug, debug, debug
> 

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SndConfig for Linux/PPC

[Dan Malek]

Anirudh Joshi wrote:

> 
>         heh... funny you bring this up, cause just yesterday i decided
> (was coaxed rather) to rewrite the awacs driver.  hopefully when i'm
> finished, it'll be out of dmasound.c and awacs.c will be done The Right
> Way (or whatever way i think is Right :).  anyhow, it'll have all the
> goodies like mixer support, etc...

What version are you looking at?  The current version works and
has mixer support.  The Rigth Way is always a personal opinion,
and rewriting something for the sake of changing variable names
or personal coding style is a waste of time.

If you decide you have time to waste on this, make sure you start
with the latest 2.3.x version, and ask me for all of the updates
I have queued to test and check in over the next couple of weeks.



	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SndConfig for Linux/PPC

[Geert Uytterhoeven]

On Fri, 24 Sep 1999, Anirudh Joshi wrote:
> 	heh... funny you bring this up, cause just yesterday i decided
> (was coaxed rather) to rewrite the awacs driver.  hopefully when i'm
> finished, it'll be out of dmasound.c and awacs.c will be done The Right
> Way (or whatever way i think is Right :).  anyhow, it'll have all the
> goodies like mixer support, etc...

Why remove the AWACS code from damsound.c? In't it better to enhance
dmasound.c, so Amiga/Atari users benefit from your enhancements as well?

Greetings,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248648 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SndConfig for Linux/PPC

[Tom Rini]

On Sun, 26 Sep 1999, Geert Uytterhoeven wrote:

> 
> On Fri, 24 Sep 1999, Anirudh Joshi wrote:
> > 	heh... funny you bring this up, cause just yesterday i decided
> > (was coaxed rather) to rewrite the awacs driver.  hopefully when i'm
> > finished, it'll be out of dmasound.c and awacs.c will be done The Right
> > Way (or whatever way i think is Right :).  anyhow, it'll have all the
> > goodies like mixer support, etc...
> 
> Why remove the AWACS code from damsound.c? In't it better to enhance
> dmasound.c, so Amiga/Atari users benefit from your enhancements as well?

Not really.  AWACS is like 3 different chips as it is.  In reality,
dmasound.c should go away.  The common code between the atari, amiga, and
various other chips which dmasound kinda "works" on can be in one file,
then amigasound, atarisound, then awacs (which would still be dealing w/ 3
different chips) for pmacs.

---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SndConfig for Linux/PPC

[Benjamin Herrenschmidt]

On Sun, Sep 26, 1999, Dan Malek <dan@netx4.com> wrote:

>What version are you looking at?  The current version works and
>has mixer support.  The Rigth Way is always a personal opinion,
>and rewriting something for the sake of changing variable names
>or personal coding style is a waste of time.
>
>If you decide you have time to waste on this, make sure you start
>with the latest 2.3.x version, and ask me for all of the updates
>I have queued to test and check in over the next couple of weeks.

By the way, if someone is working on the sound driver, I'd be glad if
this person could have a look at the sleep/wakeup code and especially
make sure it works fine when a sound is currently playing. (In this case,
playback should be either resumed on wakeup or samples just killed and
the driver would then wait for more samples).

It works fine on my machine, but several users are experiencing trouble
with it, and I won't have time to do much work on linux this week. (With
luck, I'll be able to finish the new BootX version and cleanup a couple
of patches I have here, but that's all).

It looks like when atyfb.c is present, sleep tends to keep sound alive
which is not the case when disabling atyfb. The main difference is that
atyfb introduces a pause of approximately 500ms before the actual sleep
(and just after the wakeup).

Also, Geert, I don't know if you manage to find better default values for
MCLK, but it looks like the hangs on sleep/wakeup with chipID = 4c50 are
due to too high MCLK values. Lowering down the MCLK to 60 allowed one
user to sleep and wakeup without my horrible hack (which was to abort the
wait-chip-to-be-suspend when chipID 4c50 is encountered). 
I'm wondering if we should add code to limit the default MCLK (unless
manually specified) to 60 on the chips known to be in powerbooks. (or do
this whenever we are on a powerbook).


-- 
           Perso. e-mail: <mailto:bh40@calva.net>
           Work   e-mail: <mailto:benh@mipsys.com>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SndConfig for Linux/PPC

[jeramy b smith]

Maybe we should just make a pool and try to come up with enough money to buy a
Geert a powerbook ;)


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SndConfig for Linux/PPC

[Geert Uytterhoeven]

On 27 Sep 1999, jeramy b smith wrote:
> Maybe we should just make a pool and try to come up with enough money to buy a
> Geert a powerbook ;)

Thanks! But make sure to buy me some spare time as well :-)

Greetings,

						Geert

P.S. My sister has one... But she's not here.
--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248648 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: SndConfig for Linux/PPC

[Geert Uytterhoeven]

On Thu, 30 Sep 1999, Joerg Rambau wrote:
> I have a Rev 2 PB G3 266 MHz (bought in Dec 98)
> with Rage LT Pro, Chip ID 0x4c50.

> MCLK 78, PLL 135 crashes (and some others I cannot remember),
> MCLK 60, 63, 71, PLL 135, MCLK 100, PLL DEFAULT do not crash.
> 
> I have to say that, in contrast to earlier versions of atyfb.c,
> MCLK 100, PLL DEFAULT

Why try PLL 135?

AFAIK the RAGE PRO LT PLL upper limit is 230 Mhz. This means that the PLL locks
best in the range 115-230 MHz. Outside this range, the PLL may not lock to the
specified frequency. If you use PLL 135, atyfb will assume the PLL locks best
in the range 62.5-135 MHz, which may cause screen unstabilities.

Greetings,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248648 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/