From owner-freebsd-multimedia Sun Jun 29 15:32:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA20069 for multimedia-outgoing; Sun, 29 Jun 1997 15:32:39 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA20064 for ; Sun, 29 Jun 1997 15:32:37 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 29 Jun 1997 18:31:33 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA17384; Sun, 29 Jun 97 18:31:32 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id SAA27372; Sun, 29 Jun 1997 18:29:48 -0400 Message-Id: <19970629182948.23390@ct.picker.com> Date: Sun, 29 Jun 1997 18:29:48 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: Re: mtv - Any SB16/32/AWE32 owners hearing audio? References: <19970629081228.57316@ct.picker.com> <199706291745.KAA04450@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199706291745.KAA04450@rah.star-gate.com>; from Amancio Hasty on Sun, Jun 29, 1997 at 10:45:57AM -0700 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty: |Find out where in the sound driver the sample rate is being set for |the sound blaster and check the code for supported rates. | |Another to thing to try out is to playback with a freebsd binary |a sound stream with a similar sample rate and sample size (8 or 16 bits). Ah!, that was one of the first things I did. It's trying to play: 22050Hz, 16-bit, mono I verified (via fxtv) that I can play (& record) samples of this format and rate. Also, it also tries to set up the DMA buffers (SETFRAGMENT) to: 127 buffers, each 1024 bytes apiece It then queries the DMA buffer config (GETOSPACE) to determine the actual number of buffers assigned by the sound driver, adjusted for how much memory the driver has to devote to buffers, and is returned: 64 buffers, each 1024 bytes apiece There's also a SETTRIGGER (-3) ioctl mtv is doing (beats me what this does). This is a new ioctl in Voxware 3.5. Our existing 3.0-current & 2.2 linux emulation code doesn't pass it, so given that mtv works for you fine and (I assume) you haven't hacked up your linux emulation to pass this new ioctl, then I'm thinking that this ioctl isn't related to the problem. Aside from these /dev/dsp ioctls, soundwise, all mtv's doing are VOLUME and DSP volume /dev/mixer ioctls. BTW, I think I mentioned this before but just to get it on the same page, with the 3.0 Voxware code checked into the 2.2 and 3.0 trees, I can hear very short blips of the correct audio each time I toggle mute (on mtv) or adjust the volume control (via xmix). I also don't get the "Invalid argument" dialog I do with 3.5, so mtv "thinks" the 3.0 sound driver's working right. Does this provide any useful clues? Randy