From owner-freebsd-multimedia Sun Aug 24 11:46:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA14854 for multimedia-outgoing; Sun, 24 Aug 1997 11:46:27 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA14849 for ; Sun, 24 Aug 1997 11:46:24 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.7/8.7.3) with SMTP id OAA13555 for ; Sun, 24 Aug 1997 14:46:22 -0400 (EDT) Message-Id: <199708241846.OAA13555@whizzo.TransSys.COM> X-Mailer: exmh version 2.0zeta 7/24/97 To: multimedia@freebsd.org From: "Louis A. Mamakos" Subject: problems with guspnp sound driver Mime-Version: 1.0 Content-Type: text/plain Date: Sun, 24 Aug 1997 14:46:22 -0400 Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I've been noticing some problems with the sound driver lately. It's hard to say exactly when it started. For a while now, I've been playing some mpeg compresses audio files in "jukebox" mode on the FreeBSD systems that I have at work and at home. I've got a bunch of files; however I've found that if I say something like: mpg123 /u/louie/jukebox/*.mpg things seem to "degrade" after the second or third audio file. At the time, I thought this was some sort of bug with mpg123, so I got into the habit of: for f in /u/louie/jukebox/*.mpg; do mpg123 -q $f; done instead, running a new instance for each audio file. This continues to be what I do on my system at work which has thsi version of the guspnp driver: VoxWare Sound Driver:3.5-alpha8-970706 (Sun Jul 6 01:23:34 PDT 1997 Amancio Hasty@rah.star-gate.com) with a GUS PnP board. Ok, so far so good. On my system at home, I've been tracking the sound driver release pretty closely and have guspnp16 running now. Lately, I've not been using the "jukebox" audio too much at home, and haven't really been paying attention. Over the last few days, however, I've noticed that when I run mpg123 to play an audio sample, I get this weird distortion - sort of a fluttering effect, almost with an echo (which might be the same sample replayed, or non-sync between the left and right channels, not sure). It happens repeatedly, and occurs in the same place in the audio playback each time. I don't think it's a decoding problem with mpg123; if I invoked mpg123 -s foo.mpg | pcmplay instead, then the playback either occurs with no problems or fewer problems in different places. I'd fiddled around with ktrace and some debug printfs in mpg123 to see if there's something weird going on with the size of the write()'s being done at the time that the distortion occurs, but I haven't seen anything obvious. I'm begining to think that the original problem I saw (playing multiple files) and this latest problem (distortion during a file playback) are the same sort of thing, but just happening sooner. It's almost as if there is some de-synchronizing thing happening in the sound driver after sustained writes which gets cleared or reset when the device is closed and reopened. I've seen the same thing happen using the 'xaudio' command that was recently mentioned as part of a GUI mpeg audio player, so I don't think it's the software. Sorry about the lack of further detail - what should I do to try to narrow down the cause of this? I've got a bunch of the older sound drivers, and if it's useful, I can build a kernel with one of the older ones and see if it happens again. It would be helpful to know where significant changes occured so I can minimize the number of reboots. Or perhaps some debug messages that I could corrolate with the distorted audio? Sorry for bringing this up so late in the process, but it was hard to know where the problem lies and I've run out of easy things to try.. I'm running a GUS PnP, and fairly recent 3.0-current. louie