From owner-freebsd-multimedia Fri Sep 5 11:41:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA24898 for multimedia-outgoing; Fri, 5 Sep 1997 11:41:49 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA24890 for ; Fri, 5 Sep 1997 11:41:42 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA12468; Fri, 5 Sep 1997 19:29:26 +0200 From: Luigi Rizzo Message-Id: <199709051729.TAA12468@labinfo.iet.unipi.it> Subject: Re: speed setting problem with SB16 on snd970904.tgz To: grady@scam.XCF.Berkeley.EDU Date: Fri, 5 Sep 1997 19:29:25 +0200 (MET DST) Cc: multimedia@freebsd.org In-Reply-To: <199709051718.TAA12430@labinfo.iet.unipi.it> from "grady@scam.XCF.Berkeley.EDU" at Sep 5, 97 11:20:22 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > This works! (after :%s/d->speed/d->play_speed/g) right. I am in the middle of implementing split format operation (some cards do support that, and the SB16 needs that if you want to do full duplex without too much hassle) so I applied an inverse substitution forgetting that the original name was play_speed, not just speed :( > Things are _almost_ wonderful. But now that I can hear everything, > I'm noticing there are clicks in the output. They occur 4 or 5 times > per second. I hear them both with timidity (playing on dspW) and > catting a file to /dev/audio. I think they are occurring with > absolutely regularity, although the music makes it hard to hear yes. The reason is that I am not using auto mode right now (other work in progress, see dmabuf_auto.c ... ) so when you get an interrupt (4 times per second default) you might miss a sample. This problem seems not to appear with the CS4236, either because they have a bigger data fifo (does the SB16 has a data fifo at all ? and how do I enable it ?) or because it generates an interrupt earlier (maybe when the last sample is acquired, rather than at the first underrun/overrun) or a combination of the two. The problem will go away with auto dma, but implementing autodma is tricky in presence of broken chips such as the opti931 so I need to design things carefully first. That's why it is getting so long. > BTW, when I cat to /dev/audio, I see the message: > default ioctl snd1 subdev 4 fn 0x402c7413 fail this is "cat" trying ioctl(fd, TIOCGETA, ...) on the sound device. I always forget to trap this one... Luigi