Date: Thu, 23 May 1996 22:36:09 -0700 From: "Amancio Hasty Jr." <hasty@rah.star-gate.com> To: "Louis A. Mamakos" <louie@TransSys.COM> Cc: hasty@netcom.com (Amancio Hasty Jr), multimedia@FreeBSD.ORG Subject: Re: gus pnp problems... Message-ID: <199605240536.WAA01869@rah.star-gate.com> In-Reply-To: Your message of "Fri, 24 May 1996 00:10:44 EDT." <199605240410.AAA03763@whizzo.transsys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > >If you enable "lecture mode" in vat, the problem seems more likely to > > >happen. If you 'cat /kernel > /dev/audio', then you can hose it up > > >pretty good. In fact, in many cases, cat'ing a big file at > > > > I noticed that you are running -current not sure if this is related > > or not to your system crashing;however, I have two FreeBSD boxes > > 1. 486DX2 66 with no PnP BIOS running FreeBSD-stable > > 2. P100 with a PnP BIOS running FreeBSD-stable. > > The -current systems are otherwise very stable. They both are running > roughly the same kernels (save for the one having the PNP > initialization code to turn on the board). > > The changes that I made to the code to get it to compile and (mostly) > run on -current systems is pretty minor. Perhaps there's someone > subtle missing; I don't really have a good "gut" feel on how the > VOXWARE, er TASD, or whatever drivers are organized. > > > I am curious about "audial 1234" whats that and if it is related > > to NCDs network audio server can you post the bits on auvoxware.c > > which opens /dev/audio. Previous versions opened /dev/audio0 and > > /dev/audio1 that may cause a system to crash and I will fix that > > for the next rev level of the gus pnp driver. > > I don't have the source code for the audio server stuff; I installed > the package from the packages-current directory on ftp.freebsd.org. > Doing a strings on the binary reveals: > > louie@whizzo[116] $ strings /usr/X11R6/bin/auvoxware | grep /dev > /dev/null > /dev/dsp > /dev/dsp1 > /dev/mixer > > Of course, I don't know what it's using /dev/dsp* for, or if it > somehow attempts to otherwise open /dev/audio. I can almost assure you that the auvoxware that you are running is trying to open /dev/dsp0 and /dev/dsp1 is easy to find out just move aside /dev/dsp1 . Like mv /dev/dsp1 /dev/dsp.save then try again audial. I will plug this problem with my next release for the gus pnp stuff. > > > With snd driver versions 3.5 and the gus pnp driver you can open > > /dev/audio for both reading and writing. Opening /dev/audio1 > > access the GF1 side of things in the GUS PnP card. /dev/audio > > accesses the emulation of a Cs4231 on the GUS PnP. > > That's nice to know. > > > As for the mic, both of my systems accept mic input with no problems and > > I have tested this quite a bit with vat . > > You may want to try a different mic or switch the power to mic switch > > found on the GUS PnP . You probably have it on or off so just try the > > opposite setting. > > Ah, excellent idea! Late last night, I tried the microphone in > windoz, and it didn't work there. I had forgotten all about the power > switch on the GUS PNP board. I don't remember what position it was > left in, but I'll tear it all apart and have a look tomorrow or this > weekend. > > > The repeat loop effect was mostly due to clearing the interrupt status > > register too late in ad1848.c . You shouldn't hear any more repeat > > loops with vat-4.0b1a and the guspnp1 driver. > > Good, I'll keep an ear out for this.. > > > You really ought to run > > vat on the P133 since the 486DX266 can barely give up with vat at > > least thats what my experiments have shown over here over the > > last week. Is easy to find out. Just click on the highlighted > > window on the vat which is receiving audio <thats left mouse click> > > and select rtp stats. When vat is keeping up and there has been > > a few frames sent by vat with PCM audio format you shall see > > a 20ms playout time --- thats is a 20ms delay. When vat fails > > to keep up it increases its playout buffer --- however this can > > also be cause by network delays . In my case, is easy since I > > can test vat with my local network and thus the network delays > > are eliminated . As for MBONE stuff, I can't really test it > > right now because an upstream mrouted on MCI is dropping 1/3 > > of the packets on the average . Hopefully, TLG and MCI will > > hash out this problem soon. > > Looking at the load average on the 486DX2/66 system, it's almost > always below about 0.5 running vic and vat. The playout moves around > somewhat, but as you said, that could be an artifact of the network > lossage between the source and my box. Once I get the microphone > working, I can try to local experiments as well as having other local > machines source some audio traffic to see how it feels about it. > Generally, the box seems pretty zippy. > > Also, today I noticed on the 486DX2 system at work some errors coming > out of vat complaining that it couldn't set non-blocking mode on > /dev/audio. I don't have the exact text of the message, but I'll try > to write it down the next time. This was with the more recent version > of vat that I got from rah.star-gate.com. I know what you are talking about . I placed that printf there. basically, vat tried to set /dev/audio on non-block mode . This will failed if the open to /dev/audio failed or if for some reason your are not running the guspnp1 sound driver. Previous versions, of the sound 3.5 don't support non-block mode. Additionally, vat no ensures that there are not many buffers queued on the sound driver by checking the number of outstanding buffers both on the input and output. On my next release of vat I will release the code and is going to be a lot of fun enabling debugging output since you will be able to see the packet delay on both input and output and how many buffers are being held on the sound driver. > Anyway, I think that there's been real significant progress here > lately, and I'm pretty excited about it! I just need to find some > more time to play around with it, but spare time seems hard to come by > these days. > Trust me I have less time than you . Last nite, I went to sleep at 5:00 AM At any rate, I am glad that you are providing valuable input and lets hope that the next round of the software will fix all the problems. Tnks! Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605240536.WAA01869>