On Wed, Jul 25, 2001 at 10:01:17AM +0200, Audun Arnesen Nordal wrote:
> 
> I just don't have any luck with sound on my NetBSD 386 boxes *sigh*. I
> couldn't get sound working on the integrated Intel 82801AA AC-97 that came
> with one box because the driver is only partly working and the chip is
> kinda stupid from what I understood. So I bought a SB 128 PCI which seems

I've one too. It needs mixerctl frobbings to get sound out, and as it
can only do 48Khz it's not really usefull (most MP3 are 44100 :)

> to attach nicely, but there's just no way I can get it to play.
> 
> Excerpt from dmesg:
> NetBSD 1.5W (dell.current) #6: Tue Jul 24 19:12:46 CEST 2001
>  root@audun.tromso.fast.no:/usr/current/sys/arch/i386/compile/dell.current
> [...]
> eap0 at pci2 dev 10 function 0: vendor 0x1274 product 0x5880 CT5880C (rev.
> 0x02)
> eap0: interrupting at irq 11
> eap0: SigmaTel STAC9721/23 codec; 18 bit DAC, 18 bit ADC, Rockwell 3D
> audio0 at eap0: full duplex, mmap, independent
> midi0 at eap0: AudioPCI MIDI UART

I have one eap too:
eap0 at pci1 dev 5 function 0: Ensoniq AudioPCI 97 (rev. 0x08)
eap0: interrupting at irq 11
eap0: Crystal CS4297A codec; headphone, 20 bit DAC, 18 bit ADC, Spatializer 3D
audio0 at eap0: full duplex, mmap, independent
midi0 at eap0: AudioPCI MIDI UART
> 
> BTW, the card seems to share an interrupt with a usb host controller if
> that matters:
> uhci0 at pci0 dev 31 function 2: vendor 0x8086 product 0x2412 (rev. 0x02)
> uhci0: interrupting at irq 11
> 

Mine also share interrupt:
pciide3: using irq 11 for native-PCI interrupt
eap0: interrupting at irq 11
auich0: interrupting at irq 11

So this shouldn't be a problem.

> 
> Now, audioctl -a gives
> name=Ensoniq AudioPCI
> version=
> config=eap
> encodings=ulinear:8,mulaw:8*,alaw:8*,slinear:8*,slinear_le:16,ulinear_le:16*,sli
> near_be:16*,ulinear_be:16*
> properties=full_duplex,mmap,independent
> full_duplex=0
> fullduplex=0
> blocksize=4384
> hiwat=14
> lowat=10
> monitor_gain=0
> mode=
> play.rate=8000
> play.channels=1
> play.precision=8
> play.encoding=mulaw
> play.gain=127
> play.balance=32
> play.port=0x0
> play.avail_ports=0x0
> play.seek=0
> play.samples=0
> play.eof=0
> play.pause=0
> play.error=0
> play.waiting=0
> play.open=0
> play.active=0
> play.buffer_size=65536
> record.rate=8000
> record.channels=1
> record.precision=8
> record.encoding=mulaw
> record.gain=191
> record.balance=32
> record.port=0x1
> record.avail_ports=0x7
> record.seek=0
> record.samples=0
> record.eof=0
> record.pause=0
> record.error=0
> record.waiting=0
> record.open=0
> record.active=0
> record.buffer_size=65536
> record.errors=0

The difference with mine:
-blocksize=384
-hiwat=170
-lowat=127
+blocksize=4384
+hiwat=14
+lowat=10

Hum, different block size. Maybe audioplay can't deal with this ?

> 
> mixerctl -a gives
> mixerctl: /dev/mixer: Operation not supported by device

I can't explain this. Did you try to rebuild /dev/mixer* ?

--
Manuel Bouyer <bouyer@antioche.eu.org>
--