Sound through ALSA, a 2D game, and a stack walk that cannot panic
SDL 3 has no OSS backend and SchOS has no ALSA kernel side, so sound now goes SDL -> alsa-lib -> alsa-plugins' OSS plugin -> /dev/dsp. That path found two bugs underneath it: - ac97: resetting the PCM-out box also clears the descriptor list address, and nothing set it again. Every stream after the first stop played a "list" at physical address 0 -- silence -- and ALSA resets before each stream. If the engine halts at the end of the queue, the run bit is set again. - /dev/dsp: SETFRAGMENT, GETFMTS, GETCAPS, SETTRIGGER, GETOPTR and GETODELAY for the plugin's ring-and-pointer model, and poll(), writable once a whole fragment fits (ALSA spun at 76% CPU otherwise). speaker-test now plays in real time at 0% CPU, verified in a recording of QEMU's AC'97. - /etc/asound.conf: the default device is a plug to the OSS device at 16-bit stereo 48 kHz, what every SchOS audio driver plays. Also: - getstackpcs: each frame link must go up the same stack by less than KSTACKSIZE. The chain ends at the syscall entry with the user's rbp, which lbreakouthd uses as a register (-1024); the walk dereferenced it under the syscall tracer and the kernel panicked inside acquire(). - fb: FBIOGET_VSCREENINFO reports nominal timings, as Linux's efifb does, instead of zeros, which Xorg's fbdev turned into a 0 Hz RandR mode. - procdump (Ctrl-P) shows where runnable threads are in user space. - World: lbreakouthd instead of lbreakout2 (its stk.c passes vsnprintf a size of 511 plus the prefix length, and Alpine's fortified headers trap on that), plus curl, alsa-lib and alsa-plugins. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S1giNvrHTrPMPw7V6x1kQ4
This commit is contained in:
parent
393bf674f5
commit
c77841ce3d
11 changed files with 237 additions and 12 deletions
|
|
@ -234,6 +234,12 @@ ac97_queue(struct device *d, const void *pcm, int bytes)
|
|||
// just written is what makes this a queue rather than a one-shot.
|
||||
outb(a->nabm + PO_LVI, (uint8)idx);
|
||||
|
||||
// An engine that ran off the end of the queue halts. QEMU resumes it when
|
||||
// LVI moves; the datasheet asks for the run bit again, so if it is still
|
||||
// halted after the write above, give it that.
|
||||
if (a->running && (inw(a->nabm + PO_SR) & SR_DCH))
|
||||
outb(a->nabm + PO_CR, CR_RPBM | CR_IOCE);
|
||||
|
||||
release(&a->lock);
|
||||
return take;
|
||||
}
|
||||
|
|
@ -263,6 +269,13 @@ ac97_stop(struct device *d)
|
|||
acquire(&a->lock);
|
||||
outb(a->nabm + PO_CR, 0);
|
||||
outb(a->nabm + PO_CR, CR_RR); // reset the box: CIV, LVI, PICB to 0
|
||||
for (int spin = 0; spin < 100000 && (inb(a->nabm + PO_CR) & CR_RR); spin++)
|
||||
;
|
||||
// The reset clears the descriptor list's address too, and the engine then
|
||||
// walks a "list" at physical address 0: every write after the first stop
|
||||
// played zeros. ALSA resets the device before each stream, so that was all
|
||||
// of them. Linux's intel8x0 rewrites it after every reset for this reason.
|
||||
outl(a->nabm + PO_BDBAR, a->bdl_phys);
|
||||
for (int i = 0; i < NDESC; i++)
|
||||
a->filled[i] = 0;
|
||||
a->head = 0;
|
||||
|
|
|
|||
Loading…
Reference in a new issue