bug sound was not played if the total amount of data written to
the device was less than one blocksize
Noticed by: NABETANI Masaki and FreeBSD-users-jp
DEB macro). There are probably quite a few other messages that warrant
a similar treatment, and many more that should be converted to plain
log messages (e.g. "WARNING: wrintr but write DMA inactive!"). Now
that I think of it, same goes for the CAM code (e.g. the famed "tagged
openings" message)
add support for Vibra16X, OPTi925, and bring in several assorted
fixes to the code and documentation.
Also present here are apm hooks so that laptops can properly
reconfigure the hardware after suspend (tested on the Libretto50).
Reviewed by: jordan
These asm statments are not quite as pessimal as when I complained
about them in rev.1.9 of audio.c. They seem to be only 40% slower
than the C version on P5's and the same speed on K6's.
signals delivered to a process writing to the audio device the
system: if you try
cat /dev/zero > /dev/dsp (or cat /dev/zero > /dev/pcaudio)
and press Ctrl-C : for a second or two the system appears to freeze
(e.g. the cursor will disappear if you move the mouse, xclock
blocks, etc.). I think that interrupts etc. still run so the problem
is not too terrible, but still annoying
[ The problems appears to also be in isa/pcaudio.c, though that is ignored ]
Submitted by: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
select/poll and DEVFS changes, which are limited to an include/define
in sound.h and the actual select/poll implementation in sound.c
[ This commit is blind, but the code is similar enough that there will
hopefully be no problems. ]
changes:
o rip the old select from his distribution to prevent extra pollution
o the code now uses audio dma, helps reduce clicks
o improved card support, should work in full duplex on sb16 cards
o add better voxware ioctl support pointed out by Joao Carlos Mendes
Luis <jonny@coppe.ufrj.br>
o remove an unused file that I included for more complete history
o and MANY other changes
I have personally tested this code with a CS4237 based card and an AWE32
(non-PnP). Both cards worked fine in 8bit and 16bit mode.
the normal CS4326 except that it's had it's ID's tweaked for some reason)
Also mark the device as alive in the attach routine so that the pnp system
doesn't think the attach failed.
