Date: Thu, 23 May 1996 14:05:27 -0700 From: hasty@netcom.com (Amancio Hasty Jr) To: multimedia@freebsd.org Subject: gus pnp problems... Message-ID: <199605232105.OAA19332@netcom11.netcom.com>
next 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. Yet, have to see the gus pnp hang the system over here. I really beat on the last version of the gus pnp driver in particular to eliminate the 5 or 6 second repeat loop seen with vat. I will dig further into the code for areas which may cause a large cat of a file to hose a system. 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. 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. 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. 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. 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. Also, hopefully my system will be backup again . It just trashed again the Ascend 400 . My Ascend Pipeline 50 lately has been killing my ISPs Ascend 400. Okay, so it is raining over here :( Have fun guys, Amancio
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605232105.OAA19332>