Date: Fri, 24 May 1996 00:10:44 -0400 From: "Louis A. Mamakos" <louie@TransSys.COM> To: hasty@netcom.com (Amancio Hasty Jr) Cc: multimedia@freebsd.org Subject: Re: gus pnp problems... Message-ID: <199605240410.AAA03763@whizzo.transsys.com> In-Reply-To: Your message of "Thu, 23 May 1996 14:05:27 PDT." <199605232105.OAA19332@netcom11.netcom.com> References: <199605232105.OAA19332@netcom11.netcom.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. > 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. 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. louie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605240410.AAA03763>