Date: Wed, 11 Mar 1998 03:29:36 -0500 From: "Gary T. Corcoran" <garycorc@idt.net> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: multimedia@FreeBSD.ORG, andrew@squiz.co.nz Subject: Re: Sound driver problems, including lockup (Was: sound in -current) Message-ID: <35064B70.AFCD6946@idt.net> References: <199803100643.HAA08610@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
I wrote: > > I never had time to write up a proper report on this, but when I was trying > > to get sound going on my notebook PC, I found that when (at first) I had > > the two DMA channels reversed in my config file (since I didn't know which > > was which in Luigi's driver) my machine locked solid when I tried to play > > a sound file. Reversing the DMA's fixed the problem. Did something change Luigi wrote: > what do you mean by "DMA chan reversed", and, especially, what hardware > caused the problem ? I think you've already surmised the answer, but I meant that I had the play and record DMA channels reversed in the kernel config file. 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 from my kernel. Here's a summary of the problems I had with sound on this machine: (using 2.2.5-BETA -- right before 2.2.5-RELEASE last October) 1. The included Voxware 3.0 driver worked with the sound chip as an "SB Pro", but only provided lousy 8-bit sound. So I tried your (Luigi's) sound driver. 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. [Also, in case this helps anyone else: I swapped the factory default settings of the DMA channels in the BIOS setup, if I recall this was necessary to get the Voxware driver to work at all] 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... 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? 5. I really wanted to be able to play midi files too, but of course your driver doesn't natively support the midi port yet. I tried using the Voxware driver, but it would only recognize the MPU-401 port and not the "regular" 0x330 midi I/O port. I tried playing midi files that way. It sort-of worked, but there were two problems: A) Being FM-synthesis only, the sound quality was only so-so (I'm used to the hardware wavetable synthesis on the AWE32 on my desktop machine). B) The timing of the midi notes was not very accurate, to put it politely. (I guess the notes about the MPU-401 driver being untested and of unknown quality were correct :) So then I put back your (Luigi's) sound driver and decided to try Timidity. After initially getting bad results until I found your file to patch Timidity, once I patched the program I got very good sound! Not quite as good as the AWE32, mind you, but very good quality. So, in summary, if I could just get control of the mixer for this chip, I'd be a happy camper. :-} I looked at the Yamaha chip web site but found no useful information... > > about a possible config error, but not a lockup. Could you perhaps detect > > this situation, Luigi? When I get some more time I'll write up some > > i'll do my best... > > the thing is, two buffers are allocated in the driver, and the 8237 is > started on both channels. "Reversing" the channels as you claim should > have the effect that write dma request go to a 8237 channel > programmed for reads, so the request is not honored (probably) by the > 8237. Then what could happen is that the soundcard is continuously > issuing request causing some kind of freeze on the ISA bus ? That was my guess as to what was happening - an "infinite" DMA request, freezing the machine. > detecting the problem is very card specific though... 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 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? Gary 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?35064B70.AFCD6946>