"off_t" and the return value is a "paddr_t" to allow mappings
at offsets past 2^31 bytes. Somewhat inspired by FreeBSD, which
only changed the offset to a "vm_offset_t".
Includes updates for the i386, pc532 and sh3 mmmmap from Jason Thorpe.
* Rearrange the speed mapping table and adjust the code so that the highest
rate can actually be used. Previously we ended up rounding up slightly
lower speeds and then losing because set_params couldn't set the mode
back to the current one.
* Allow 260 as a valid I/O address, since the SB1 can be jumpered to this.
* Change the MPU-401 code so it can be attached as a separate device.
(XXX Really, the SB code ought to just attach a subdevice itself.)
* Do not attach an OPL on the SB1. Writing to the OPL registers at
SB_base+0 on this card wedges my machine.
(XXX Should we access it at 388 instead? The Creative web site claims
that this board *does* have an OPL2, but I haven't played with this
extensively.)
* Allocate the SB DMA channels at open time, rather than attach time, so
that a single DRQ can be used for multiple cards (if only one is in use
at a given time).
(XXX Let me tell you why this is a horrible hack. If the ISA DMA code
tries to allocate a bounce buffer after boot time, it will generally fail,
because there is no contiguous memory below 16MB and the code to allocate
contiguous pages doesn't know how to move things around. Now, we
shouldn't ever be using bounce buffers here, because we use
isa_dmamem_alloc(). So we just turn off BUS_DMA_ALLOCNOW and we don't
actually try to. That's cool, and it even works, but isa_dmamem_alloc()
has the same problem. It just happens that we allocate the ring buffers
at boot time, and whenever we reallocate them (due to the buffer size
changing), we just deallocated the previous (contiguous) buffer, so we get
lucky. This is absolutely disgusting and needs to be fixed.)
* Improve the midisyn layer a little.
* Add a driver for the Yamaha OPL[23] FM synths.
The opl driver is not finished yet; it sounds pretty awful.
For some strange reason I cannot get any FM sound from my SB64 cards,
but a regular SB16 works fine.
Also, even on the SB1, we can leave the DMA controller in auto-initalize
mode and just send a command to the board for each block. This may help
prevent FIFO underruns.
the /dev/rmidiN devices, or with a sequencer interface via /dev/music.
So far the only supported MIDI device is the MPU401 port on SoundBlaster
(and only on SB on isapnp, since we do not have locators with multiple
values yet).
The changes is to allow some limited mixer manipulation through
the audio device (instead of the mixer device).
This rendered 4 methods in audio_hw_if unused so garbage collect these.
Because of the braindead design of the SB the input and output have to
use different precisions (8 and 16 bits). It is possible to set the driver
to use 8 bits on both and it will the emulate 8 bits on the output by
expanding it to 16 bits.
at the same time instead by using two different calls. This enables
it to check more easily if the combined mode is all right.
- Improve the error checking in audio.c.
- Add a new audio property, AUDIO_PROP_INDEPENDENT, show if the
play and record settings are independent.
- Fix some buglets in audio.c.
* Make it possible to use software assisted encodings that expand the
sample size.
* Use 16 bits per sample when emulating mulaw coding on the SB.
* Prepare for SB16 without CT1745 mixer.
- Change the way attach and open works to allow multiple audio
devices.
- Split the mulaw.c file into two to avoid dragging in mulaw
convertsion when they are not needed. Add 16 bit alaw/mulaw tables.
- Change the way audio properties are gotten.
- Recognize more versions os SoundBlaster.
- It is now possible to handle devices that want "looping" DMA,
e.g. the SoundBlaster correctly. The WSS and SB drivers use this.
To do this several new methods were introduced in audio_hw_if.
- Different silence handling (forced by previous change).
- The audio driver can now be mmap()-ed, but due to problems in
the VM system only for writing for now.
- The OSS (Linux) audio emulation takes advantage of some of the
new features.
renamed AUDIO_ENCODING_SLINEAR and AUDIO_ENCODING_LINEAR reverts to the
NetBSD 1.2 sematics. A kernel with COMPAT_12 defined will accept
AUDIO_ENCODING_LINEAR and treat it as before, without COMPAT_12 it
will be rejected.
mrg