Date: Sun, 1 Oct 1995 10:58:59 -0500 From: Jim Lowe <james@miller.cs.uwm.edu> To: gene@starkhome.cs.sunysb.edu, hackers@freebsd.org Subject: Re: Problems with VAT and Sound Code Message-ID: <199510011558.KAA05049@miller.cs.uwm.edu>
next in thread | raw e-mail | index | archive | help
> From: Gene Stark <gene@starkhome.cs.sunysb.edu> > To: hackers@freebsd.org > Subject: Problems with VAT and Sound Code > > Even with the sound code now in -stable, I am still unable to get VAT > to work with an SB-16. The symptom is that there is no sound. If you > select one of the audio tests, you hear nothing until you delete the > VAT window, at which time there is a very brief spurt of the test tone. > During the time there is no sound in the speakers, VAT appears to operate > normally. If you talk into the mike you can see the little level meter > bounce around, etc. A ps on VAT indicates it is spending its time in > select. I beleive you will have a lot of trouble getting vat to work directly with a SB-16. Vat requires a full duplex device. There is a program I wrote called vmix. This program interfaces with vat via a socket interface and emulates full duplex and does rate adjustment. Vat assumes that there is a continuous input source is running at 8khz. With most PC soundcards, running at 8khz is not possible. Some run fast (8100hz) and some run slow (7900hz). This causes several problems with vat. Vmix attempts to address these problems. Vmix is still alpha quality code, but Amancio convienced me to release it because some people would find it useful. If you pick up vmix (from ftp.cs.uwm.edu/pub/FreeBSD) check the README for problems with the SB-16 code. I don't have a SB card so I had to try and debug the problems remotly across the Internet (Thanks Charles). There is still a problem with the SB if one doesn't keep the playback buffer full. The dsp buzzes on start/stop for some reason. There are some patches in the README file that you will need for vmix to fix this problem. > > On the off chance that I might spot a problem in the audio select() > code, I started looking at that part of the drivers. My first impression > is that there are a *lot* of potential race conditions due to incorrect > positioning of DISABLE_INTR and ENABLE_INTR. Yup... I will fix that and submit a patch. Thanks for point this out. Did you spot any other potential problems other than this one? -Jim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510011558.KAA05049>