audio device interface:
1) When attempting to match the appropriate mixer control, we weren't
checking the class label, but only the second level label, so for
devices that had both an "inputs.cd" and a "record.cd", for example,
we could never do the right thing except by chance. For this reason,
evidently, all the record masters were labeled (by the underlying
drivers) either "record.record" or "record.volume", to distinguish
from "outputs.master". We'll now accept "record.master", and document
that as the the new preferred way.
2) More importantly, the model was deficient. Selecting a port on many
chips completely disables most of the level controls, which doesn't play
nice with other applications which are trying to use the interface. Now,
selecting a port simply sets which mixer input control shall be changed,
setting state in the audio layer. In other words, the "mixerout" port
is really selected all the time, enabling the final stage mixer, and
setting "gain" sets the level of the appropriate input. It should be
possible for separate applications to each control the mic, dac, and cd
inputs at the same time using this interface, simply by reiterating their
port selections with each change, but applications that don't bother to
do that aren't any worse off than they were before.
The user is expected to set the master output with another application,
dedicated to that task. Though it is now meaningful to select "no port"
with the audio device interface, to manipulate the master output, there's
no particular reason for an audio device consumer to do that. (I added
the capability in order to restore the initial state of the audio device,
for testing purposes. It might also be useful to users of broken binary-
only applications.)
Observe that the mixer device interface (and so, "mixerctl") still
retains all capabilities, including the ability to set the actual input
port on the chip, overriding the level controls. No change is being made
to the mixer device interface. The mixer device simply presents all the
controls on the chip, with no attempt at abstraction, so there are no
bugs there.
The upshot is, that applications that have been trying to use the audio
device interface to change the volume, such as mplayer, now "just work".
I've tested these changes extensively with "eso" and "eap" since first
proposing them on tech-kern last January, and somewhat with "esm" and a
few others. This closes both PR kern/10221, and PR kern/17159.
* Separate the code to set the default parameters into a new function,
audio_set_defaults(). Make it use audiosetinfo(), which properly initializes
the block size and whatnot. Use this in both audioattach() and the
/dev/audio case of audio_open().
* Do not force a reinitialization when /dev/sound is opened.
* Do all of the block size sanity checks in auto_init_ringbuffer(), not in
both audio_calc_blksize() and audiosetinfo().
* Fix a bug in audiosetinfo() that caused the block size to not be recalculated
immediately if we set it to 0.
* For AUDIO_GET[IO]OFFS, modify the deltablks calculation so that it gives us
the number of block boundaries crossed.
be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
Back-out revision 1.170 and and 1.166. Revision 1.170 fixes some problems
introduced in revision 1.166. It isn't clear what problem revision 1.166
was attempting to address. It seems bogus anyway, since we later check
the modes in audio_check_params().
cannot change the recording or playback mode of the device, it can
only change other mode-like values (like AUMODE_PLAY_ALL). Be very
explicit about fixing up the user's mode value based on the mode of
the device. Before, giving AUMODE_PLAY_ALL could cause AUMODE_PLAY
to become set on the device, and once AUMODE_PLAY_ALL was set it
was impossible to clear.
kqueue provides a stateful and efficient event notification framework
currently supported events include socket, file, directory, fifo,
pipe, tty and device changes, and monitoring of processes and signals
kqueue is supported by all writable filesystems in NetBSD tree
(with exception of Coda) and all device drivers supporting poll(2)
based on work done by Jonathan Lemon for FreeBSD
initial NetBSD port done by Luke Mewburn and Jason Thorpe
This merge changes the device switch tables from static array to
dynamically generated by config(8).
- All device switches is defined as a constant structure in device drivers.
- The new grammer ``device-major'' is introduced to ``files''.
device-major <prefix> char <num> [block <num>] [<rules>]
- All device major numbers must be listed up in port dependent majors.<arch>
by using this grammer.
- Added the new naming convention.
The name of the device switch must be <prefix>_[bc]devsw for auto-generation
of device switch tables.
- The backward compatibility of loading block/character device
switch by LKM framework is broken. This is necessary to convert
from block/character device major to device name in runtime and vice versa.
- The restriction to assign device major by LKM is completely removed.
We don't need to reserve LKM entries for dynamic loading of device switch.
- In compile time, device major numbers list is packed into the kernel and
the LKM framework will refer it to assign device major number dynamically.
binaries which were working fine on NetBSD 1.5. We defer this change
until a longer-term fix is found as explain in the commit message in
revision 1.132.
Further details can be found in PR17159.
among other things, it behaved as if full-duplex audio devices
were always ready for writing. Also commented the code in case.
This fixes PRs kern/11179 and kern/13829.
recording ring buffer could overrun the end of the buffer. When
recording resumed, memory after the end of the buffer would be read,
sometimes causing a system crash.
http://mail-index.netbsd.org/tech-kern/2002/03/04/0005.html
auconv.c: Add conversion functions
audio.c: Sample alignment, calling conversion functions, etc.
audio_if.h: Add four hw_* members to "struct audio_params"
audiovar.h: Add conversion buffers, etc.
auich and uaudio: Add conversion request code to *_set_params().
Actually, the silence filler can do any multiple of 8 bits now, but I didn't
allow the parameter check to accept more than 32 bit to avoid confusion
of drivers that fail to check the parameters themselves thoroughly.
This should be changed later.
Because zeroing them causes zero division panic with devices which don't
support 8kHz mulaw, and the effect of this line was to force calling
audio_calcwater even when unnecessary.
