Date: Mon, 9 Dec 1996 23:01:35 -0800 (PST) From: Doug White <dwhite@gdi.uoregon.edu> To: "Denis DeLaRoca (310) 825-4580" <CSP1DWD@MVS.OAC.UCLA.EDU> Cc: multimedia@freebsd.org Subject: Re: GUS & Mbone: more updates Message-ID: <Pine.BSI.3.94.961209225606.641C-100000@gdi.uoregon.edu> In-Reply-To: <199612100204.SAA24559@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Dec 1996, Denis DeLaRoca (310) 825-4580 wrote: > Yes that gateway was dropping packets. Here at UCLA I was seeing a loss > not exceeding 8% -- not enough for significant audio cuts/dropouts, > only tiny dropouts here and there. I wasn't paying too much attention to the loss percents, but most of the time the audio was excellent. That gateway died for a minute or so at one point, that's what prompted me to post that. > Humm? I'll check that tomorrow. Amancio says that this is just indicitive that a P90 just isn't quite enough to keep everything up to date :) A p133 or p166 is in my future... > It's in /sys/i386/isa/isa.c, I am not sure it these messages are > legacy diagnostic messages or legitimate error output... Found it. It's an error, but not serious. I remember a bunch of messages about this when guspnp3 or so came out. I forgot where it was. > I've never seen these with my PAS16 card. What I keep seeing very > freuqntly is > > aud write: resource temporarily busy > > which is a result of a pwrite("aud write") in vat's audio-voxware.cc > when its write() to the audio device fails. I haven't figured out what > activity on the system interferes with /dev/audio to trigger the above > failures. I don't get that (on 4.0a2), but the write select debug is attached to a select() in the /dev/audio interface (/sys/i386/isa/sound/audio.c) which appears to trip along nicely until the record channel(?) busys out and all hell breaks loose. > The sound quality I am getting in half-duplex mode with a ProAudio > Spectrum 16 card is quite good, not as splendid as with the GUS card > mind you, but quite acceptable -- the only minor problem is that > vat's clocking of audio output is slightly amiss and every so often > a couple of audio samples overlap on output as the playback buffer > is reset. The PAS may have a yet better clock than the SBs do --they supposedly have a horrible clock that can't keep time properly. This is supposedly the story behind the poor audio quality, but as my accidental experiment the other day shows, it still happens on the GUS. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.94.961209225606.641C-100000>