Date: Wed, 11 Mar 1998 08:34:18 +0100 (MET) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: garycorc@idt.net (Gary T. Corcoran) Cc: multimedia@FreeBSD.ORG, andrew@squiz.co.nz Subject: Re: Sound driver problems, including lockup (Was: sound in -current) Message-ID: <199803110734.IAA10707@labinfo.iet.unipi.it> In-Reply-To: <35064B70.AFCD6946@idt.net> from "Gary T. Corcoran" at Mar 11, 98 03:29:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
> The hardware is a Toshiba Tecra 750 notebook with a built-in Yamaha OPL3-SA3 sound
> chip. I tried your PnP driver but it didn't find any devices - hence I conclude
> that being built-in, it's a non-PnP sound device. I later removed the pnp device
PnP can be disabled on many devices by hardwiring one of the pins. I
guess your Yamaha is no exception...
> 2. Knowing only that the sound chip was using DMA channels 0 and 1, but not
> knowing which was "play" and which was "record", and further not knowing which
> was specified first on the kernel config file line, I took a guess, figuring
> I had a 50/50 chance. Because I had guessed wrong, the machine locked solid
> when attempting to play an "au" file.
now that i remember, i did a similar mistake when trying to make the
GUS work, but did not have any problem other than not getting the
interrupt... and also with the Vibra16X i have reports that swapping
channels simply yields no progress in the transfer, but no lockups...
> 3. While your driver supports the Yamaha OPL3 chips, I was unable to convince
> it (even after a little hacking) to recognize my OPL3-SA3 chip as an OPL3 chip.
> It *did* recognize it as MSS compatible chip, and so it basically works, but...
the driver does not do anything yamaha-specific, except setting the
master volume to maximum:
> 4. The master volume control setting seems to be fixed at "medium", and I have
> no control of it. Using mixer and xmix, I tried all the controls, but the only
> one that has any effect is the "DSP" control. Putting that control all the way
> up allows me to hear sound, but since master volume setting is still at "medium",
> there isn't a lot of volume. For what it's worth: in Windows95, the device
> manager lists the I/O resources the chip uses. Besides the usual suspects (0x220,
> 0x530, 0x388, 0x330), it also lists 0x370-0x371, which is listed in the BIOS setup
> as being "control" registers. Maybe that is where the master volume control is?
if you look at the cs423x_attach() routine, which also takes care of
the yamaha, there is a small section of code which does the following:
if ( (vend_id & 0x2000ffff) == 0x2000a865 ) {
/* special volume setting for the Yamaha... */
outb(tmp_d.conf_base, 7 /* volume, left */);
outb(tmp_d.conf_base+1, 0 );
outb(tmp_d.conf_base, 8 /* volume, right */);
outb(tmp_d.conf_base+1, 0 );
}
where conf_base is read from the pnp config and it is probably
0x370. The above code sets the master volume to maximum.
It is a hack, but probably enough since you still have separate volume
controls on all chans... you can try to duplicate this code in the
mss_attach routine. I have no idea to distinguish the yamaha from other
mss cards other than looking at the PnP id. Maybe that register I25 returns
something special (see ad1848.c around line 1192, where it does
id = ad_read(d, 25) & 0xe7;
in which case you can put a switch entry for the yamaha.
> I'm not sure I understand why this is card-specific. If you program a DMA transfer,
> and then expect a "DMA complete" interrupt and don't get it within a certain time,
> then couldn't you have a timeout? Sorry - it's been a long time since I programmed
yes, and this is what happens normally. but if your card freezes the machine
by trying continuously to request DMA cycles then you have no resources
to handle the timeout...
> an 8237 DMA chip and don't recall offhand exactly how it's usually working.
> Hmmm... then again, if an "infinite" DMA request has already frozen the PC,
> then you're not going to get to your timer interrupt service to detect the
> problem, are you? I wonder what the old Voxware driver is doing differently
> to detect the "config error" rather than allow the lockup to occur?
maybe it just uses the card in half duplex so you don't have the
problem... i have no idea though.
cheers
luigi
-----------------------------+--------------------------------------
Luigi Rizzo | Dip. di Ingegneria dell'Informazione
email: luigi@iet.unipi.it | Universita' di Pisa
tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy)
fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/
_____________________________|______________________________________
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803110734.IAA10707>