9fea18b18b
A program that wants to make a sound opens /dev/dsp, writes PCM, and closes
it. That is what UNIX audio has always been and it now exists here:
tone 440 2
Three pieces, in the order a sample passes through them. **/dev/dsp** is a
character device where write() is audio and a handful of OSS ioctls say what
the samples are. **AudioEngine** is everything above a driver that is not
specific to a chip -- the format, whether there is room, and what a write does
when there is not. **A driver** is bound by class, exactly as a display driver
is: device_find_class(DEVCLASS_AUDIO).
OSS numbering rather than something new, because every UNIX audio program ever
written already knows it and the only thing a different set would achieve is
making ports harder. They are read/write ioctls, which is the part that
matters: a program asks for 44100, the device sets 48000 and writes 48000
back, the program resamples. One that ignores the answer plays 9% fast, and
that is its bug rather than the driver's.
**The engine is deliberately one stream.** Mixing several programs is a real
feature with a real design behind it, and building it before anything had
played a single sound would be exactly what docs/plan/1.0.md keeps a register
for: work that exists and is connected to nothing. The second program that
wants to play at the same time is what should cause it to be written.
**audio_wait() sleeps on the timer tick, not on the device.** That looks like
the lazy choice and is not: a ring that drains is a ring with room, so asking
again in ten milliseconds always makes progress, whereas sleeping on the card
makes audio depend on an interrupt arriving. On a machine whose line is
misrouted that is not a stutter, it is a writer that never wakes. The handler
still accounts for finished buffers -- deleting it would cost efficiency, not
correctness -- and it retires descriptors through the same `tail` pointer
queue() uses, so the two cannot disagree about what is in flight.
**AC'97 first because HDA is two unproven things at once.** It is the simplest
audio device that exists on real machines and in QEMU both. Intel HDA is what
the laptop actually has and is a much larger driver; writing it against an
interface nothing had ever played through would have meant debugging the
driver and the interface simultaneously. HDA arrives as a second
struct audio_ops and nothing above it changes -- which is the entire point of
the class.
Two things the wiring needed: PCI class 0x04 now maps to DEVCLASS_AUDIO (the
driver bound and /proc/devices showed it, but audio_get() found nothing,
because the class byte had never been translated), and include/x86.h grew
inw() -- AC'97's mixer is all 16-bit registers and reading one a byte at a
time returns the low half twice on some codecs.
**Tested by measuring what came out, not by not crashing.** QEMU's wav backend
writes the guest's audio to a file; `tone 440 2` produced 1.97 seconds of
44.1 kHz stereo with peak amplitude 14177 against the generator's table
maximum of 14178, and 880 zero crossings per second -- 440 Hz exactly. wav is
on every QEMU target rather than a host backend, because a build machine may
have no sound card and it is the only backend whose output can be checked.
Both supported configurations: one boot each, no traps, no panics, socktest
and memfdtest green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
68 lines
3.5 KiB
C
68 lines
3.5 KiB
C
#pragma once
|
|
|
|
// The timer interrupt rate the kernel is built around. Everything that turns
|
|
// ticks into a duration divides by this. It used to be the literal 100 written
|
|
// out at each site, which made it look like a fact about the hardware; it is
|
|
// not. It is a target, and kernel/arch/x86_64/lapic.c calibrates the LAPIC
|
|
// timer against the PIT to actually hit it.
|
|
#define HZ 100 // timer interrupts per second
|
|
|
|
// The tick rate the *user-space ABI* is defined in, which is a different thing
|
|
// from HZ and must not follow it. glibc and musl both answer sysconf(_SC_CLK_TCK)
|
|
// with a hardcoded 100, so times() and /proc/stat are read as hundredths of a
|
|
// second no matter what the kernel's internal rate is. Linux calls this USER_HZ
|
|
// and scales at the syscall boundary; so does SchOS, in the two places below.
|
|
#define USER_HZ 100
|
|
|
|
// Converting a POSIX timespec/timeval into ticks. These used to appear as the
|
|
// bare literals 10000000 and 10000 at each call site, where they looked like
|
|
// magic numbers rather than what they are: the length of one tick, expressed
|
|
// in the units the caller happens to be using.
|
|
#define NSEC_PER_TICK (1000000000 / HZ)
|
|
#define USEC_PER_TICK (1000000 / HZ)
|
|
#define MSEC_PER_TICK (1000 / HZ)
|
|
|
|
#define NPROC 128 // maximum number of processes
|
|
#define KSTACKSIZE 8192 // per-process kernel stack; see kstacks[] in proc.c
|
|
#define KSTACK_CANARY 0xDEADC0DEDEADC0DEULL // sentinel at kstack[0], see kstack_check_canary()
|
|
#define NCPU 16 // maximum number of CPUs
|
|
#define NOFILE 128 // open files per process
|
|
#define NFILE 512 // open files per system
|
|
#define NINODE 200 // maximum number of active i-nodes
|
|
#define NDEV 13 // maximum major device number
|
|
#define RAMDISK_DEV 2 // memory-backed block device (kernel/dev/ramdisk.c)
|
|
#define USBDISK_DEV 3 // USB mass storage (kernel/drivers/usb_storage.c)
|
|
|
|
// Device the root filesystem is mounted from. Building with RAMROOT=1 defines
|
|
// RAMDISK_ROOT and boots from the SCHFS image linked into the kernel instead
|
|
// of the IDE disk, leaving the physical disk free to be reformatted from a
|
|
// running system. See kernel/dev/ramdisk.c.
|
|
#ifdef RAMDISK_ROOT
|
|
#define ROOTDEV RAMDISK_DEV
|
|
#else
|
|
#define ROOTDEV 1 // device number of file system root disk
|
|
#endif
|
|
#define MAXARG 32 // max exec arguments
|
|
#define MAXENV 64 // max environment variables passed through exec
|
|
#define MAXPATH 128 // max path
|
|
#define MAXOPBLOCKS 30 // max # of blocks any FS op writes
|
|
#define LOGSIZE (MAXOPBLOCKS*3) // max data blocks in on-disk log
|
|
// Disk block cache, in blocks. 256 * BSIZE = 1 MB.
|
|
//
|
|
// Was MAXOPBLOCKS*3 = 90 blocks, and at the old 1 KB BSIZE that is a 90 KB
|
|
// cache -- smaller than the toybox binary that every single command execs. So
|
|
// nothing was ever still resident on the next command and each one paid the
|
|
// full read again. 1 MB holds toybox with room to spare, which is what makes
|
|
// the *second* command fast rather than just the first.
|
|
//
|
|
// Sized rather than maximised: these are statically allocated in bio.c, so
|
|
// this is memory the system always spends. 1 MB is affordable on a machine
|
|
// with tens of megabytes; 8 MB would not be.
|
|
#define NBUF 256
|
|
#define FSSIZE 150000 // size of file system in blocks
|
|
|
|
// Network interfaces the stack will attach. Two is already an ordinary machine
|
|
// -- a laptop with Ethernet plus a virtual adapter -- and each one costs a
|
|
// struct netif, so the limit is about keeping a fixed array honest rather than
|
|
// about memory.
|
|
#define NETIF_MAX 4
|