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>
90 lines
3.5 KiB
C
90 lines
3.5 KiB
C
#pragma once
|
|
|
|
// The device model: one list of everything attached, whatever bus found it.
|
|
//
|
|
// Before this there were two registries in kernel/drivers/registry.c -- one
|
|
// array of PCI drivers, one of USB drivers -- and nothing that knew about both.
|
|
// That is fine for binding drivers to hardware, which is all it was for, and
|
|
// useless for the three things wanted next:
|
|
//
|
|
// *Enumeration.* "What is in this machine, and what claimed it" had no
|
|
// answer that covered a USB disk and a PCI display at once. A device manager
|
|
// is exactly that question, so it needs exactly this list.
|
|
//
|
|
// *Classes.* A compositor should ask for "the display" and not care whether
|
|
// that is the VBE framebuffer or virtio-gpu. Without a class, every consumer
|
|
// hardcodes a driver, and adding the second driver means editing the
|
|
// consumers -- which is how a framebuffer address ends up hardcoded in three
|
|
// places, as it once was here.
|
|
//
|
|
// *A boundary for drivers that are not compiled in.* Drivers the user
|
|
// installs (see docs/architecture/devices.md) have to attach somewhere that is not "an
|
|
// array in registry.c", because that array is fixed at link time.
|
|
//
|
|
// The shape is deliberately the one NeXTSTEP/macOS uses rather than Linux's:
|
|
// a device is an object with a class and an ops vtable, and consumers talk to
|
|
// the class. It is *not* a device tree -- there is no parent/child nesting
|
|
// here, only a flat list with a bus tag, because nothing yet needs to walk a
|
|
// hierarchy and a tree that nobody traverses is just a harder list.
|
|
|
|
#define DEV_NAMELEN 24
|
|
|
|
// Which bus found it. This is provenance, not capability -- what the device
|
|
// *does* is its class.
|
|
enum dev_bus {
|
|
DEVBUS_PLATFORM = 0, // found by looking, not by enumerating: PS/2, VBE
|
|
DEVBUS_PCI,
|
|
DEVBUS_USB,
|
|
DEVBUS_NBUS
|
|
};
|
|
|
|
// What it is. A consumer asks for a class and gets whatever is bound.
|
|
enum dev_class {
|
|
DEVCLASS_OTHER = 0,
|
|
DEVCLASS_DISPLAY,
|
|
DEVCLASS_INPUT,
|
|
DEVCLASS_STORAGE,
|
|
DEVCLASS_NET,
|
|
DEVCLASS_BUS, // a controller that finds more devices (xHCI, hubs)
|
|
DEVCLASS_AUDIO,
|
|
DEVCLASS_NCLASS
|
|
};
|
|
|
|
struct device {
|
|
char name[DEV_NAMELEN]; // "vga0", "xhci0" -- unique, human-readable
|
|
char desc[48]; // free text for the enumerator
|
|
enum dev_bus bus;
|
|
enum dev_class class;
|
|
|
|
// Where it came from, for the enumerator to print. Zero when not applicable.
|
|
uint16 vendor, product;
|
|
uint8 b, s, f; // PCI bus/slot/func
|
|
|
|
const char *driver; // whatever claimed it, or 0 for unclaimed
|
|
void *ops; // class-specific vtable; see display.h
|
|
void *priv; // the driver's own state
|
|
|
|
int in_use;
|
|
};
|
|
|
|
#define NDEVICE 32
|
|
|
|
// Register a device. Returns it, or 0 if the table is full. The name is made
|
|
// unique by appending an index, so a caller passes "vga" and gets "vga0".
|
|
struct device *device_add(const char *base, enum dev_bus bus,
|
|
enum dev_class class, const char *driver);
|
|
|
|
// Set the human-readable description. Bounded copy into the fixed field, so
|
|
// callers do not each need to know how long it is.
|
|
void device_set_desc(struct device *, const char *);
|
|
|
|
// Walk. Returns 0 past the end; index is dense over registered devices.
|
|
struct device *device_at(int i);
|
|
int device_count(void);
|
|
|
|
// First device of a class with a bound driver, or 0. This is how a consumer
|
|
// finds "the display" without naming a driver.
|
|
struct device *device_find_class(enum dev_class class);
|
|
|
|
const char *dev_bus_name(enum dev_bus);
|
|
const char *dev_class_name(enum dev_class);
|