Re: ASC/EASC audio device (take 3) (was take 2)

[Nat Sloss <nathanialsloss%yahoo.com.au@localhost>]

On Wed, 17 Jan 2024 12:59:52 John Klos wrote:
> > I've found that I'd mucked up the interrupt handler and two register
> > definitions.
> > 
> > The new patch to be applied to a clean tree is found at:
> > ftp://ftp.netbsd.org/pub/NetBSD/misc/nat/ascaudio-take3.diff
> 
> I've tried these on a Quadra 605:
> 
> [     1.000000] ascaudio0 at obio0: Apple Sound Chip
> [     1.000000] audio0 at ascaudio0: playback, capture, half duplex,
> independent [     1.000000] audio0: slinear_be:16 1ch 22254Hz, blk 8192
> bytes (368.1ms) for playback [     1.000000] audio0: slinear_be:16 1ch
> 11025Hz, blk 8192 bytes (743ms) for recording [     1.000000] spkr0 at
> audio0: PC Speaker (synthesized)
> [     1.000000] wsbell0 at spkr0 mux 1
> 
> cat ~john/beethoven7th.wav > /dev/sound0
> cat: stdout: Resource temporarily unavailable
> 
> [   990.244170] audio0(ascaudio0): audio_write: device timeout, seq=0,
> usrbuf=64936/H64936, outbuf=32768/32768 [   993.260963] audio0(ascaudio0):
> audio_write: device timeout, seq=0, usrbuf=64936/H64936,
> outbuf=32768/32768 [   996.344458] audio0(ascaudio0): audio_drain: device
> timeout, seq=0, usrbuf=64936/H64936, outbuf=32768/32768 [  1014.080159]
> audio0(ascaudio0): audio_write: device timeout, seq=0,
> usrbuf=64790/H64790, outbuf=32768/32768 [  1017.097002] audio0(ascaudio0):
> audio_write: device timeout, seq=0, usrbuf=64790/H64790,
> outbuf=32768/32768 [  1020.180487] audio0(ascaudio0): audio_drain: device
> timeout, seq=0, usrbuf=64790/H64790, outbuf=32768/32768
> 
> What else can I try?
> 

Try adding:

	mutex_enter(&sc->sc_intr_lock);
	do {
		status = bus_space_read_1(&sc->sc_tag, sc->sc_handle,
					FIFOSTATUS);
+static int m;
+if (m < 3) {
+	printf("status %x\n", status);
+	m++;
+
	again = false;
	count = 0;
	if ((status & A_HALF) == 0)

to ascaudio_intr to see if the interrupt actually fires.

I took the ASCIRQ value of 5 from the qemu emulation and this may be wrong.

If nothing is printed, rebuild the kernel with options DEBUG and see if 
anything is printed to the console about the IRQ number.


Best regards,

Nat