From owner-freebsd-hackers Mon Apr 3 18:27:42 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id SAA25940 for hackers-outgoing; Mon, 3 Apr 1995 18:27:42 -0700 Received: from fgwmail.fujitsu.co.jp (fgwmail.fujitsu.co.jp [164.71.1.133]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id SAA25849 for ; Mon, 3 Apr 1995 18:25:10 -0700 Received: from fdmmail.fujitsu.co.jp by fgwmail.fujitsu.co.jp (8.6.9+2.4W/3.3W5-MX941209-Fujitsu Mail Gateway) id KAA06691; Tue, 4 Apr 1995 10:23:48 +0900 Received: from fdm.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.6.9+2.4W/3.3W5-MX950127-Fujitsu Domain Mail Master) id KAA13447; Tue, 4 Apr 1995 10:23:47 +0900 Received: from sysrap by fdm.fujitsu.co.jp (5.65/6.4J.6) id AA09537; Tue, 4 Apr 95 10:23:45 +0900 Received: from seki.sysrap.cs.fujitsu.co.jp by spad.sysrap.cs.fujitsu.co.jp with smtp (Smail3.1.28.1 #1) id m0rvxS9-000CRBC; Tue, 4 Apr 95 10:30 JST Date: Tue, 4 Apr 95 10:18:55 JST From: Masahiro SEKIGUCHI Message-Id: <9504040118.AA00039@seki.sysrap.cs.fujitsu.co.jp> To: "Jordan K. Hubbard" Cc: hackers@FreeBSD.org Subject: Re: Whee - I've got my MBONE feed.. References: <199504031156.EAA02326@time.cdrom.com> Sender: hackers-owner@FreeBSD.org Precedence: bulk Great. I've been struggling with my FreeBSD box to run multicast applications. I'm very glad to know there is a FreeBSD authority having interests on multicasting/MBONE. First, I might say that my experience is based only on FreeBSD 2.0R. >1. Crank up sound card (SB16), make sure it at least works from the /dev/audio > viewpoint. Don't know of SB16 will *work*, but at least I know I can > deal with audio on a fairly generic level. SB16 works fine as a usual /dev/audio device. Vat, however, doesn't work with /dev/audio. It is not a hardware problem, but is a driver problem. As far as I know, vat is only available as binary for BSDI. It requires Sun/BSDI compatible audio interface. /dev/audio in FreeBSD 2.0 lacks some minor (I guess) ioctl's, which are essential for vat, unfortunately. /dev/vatio ("vat_audio" driver) tries to simulate BSDI audio interface on the top of /dev/audio. Vat_audio.c in 2.0R (or in 950210-SNAP) doesn't compile, however. (I have not yet tested one in 950322-SNAP.) I tried to hack vat_audio and found that vat heavily relies upon full-duplex operation of the audio device, even when you just want to listen to other guys' chatting. VoxWare supplied with 2.0R only provides half-duplex operation however. I had a feeling that the author of vat_audio (I don't know who he/she is) knows all of the story. Vat_audio actually grabs two audio devices (/dev/audio and /dev/audio1), puts one in input only and another in output only, and behaves as if it is one audio device. Hence, I believe you need two SB16 (or whatever sound card) to run vat on vat_audio. I'm very much interested in hearing from MBONE/FreeBSD hackers how they are living with vat. >4. Up comes VAT. ... abridged ... > But nothing on the speaker! No audio! Foo! I have explained my understanding of the reason. I have one more thing to say. Vat opens the path "/dev/audio" as a default audio device. It is hard coded. Then, vat sends several ioctl's which are not supported in FreeBSD /dev/audio. All of them fails (i.e., returns with errno == EINVAL). Strangely enough, vat ignores the error. (No error messages nor beep sounds.) It just sits on the screen, wasting CPU. >5. Up comes nv. ... abridged ... > No pictures! No > sound! Nv doesn't support audio. Just video. It is normal that nv generates no sounds. But, hmmm, I had no trouble seeing videos with nv running on FreeBSD 2.0R. One thing I can imagine is encoding mismatch. Nv suppoprts several video "encoding". Supported encodings vary from version to version. I suggest you first see what encoding is used for a paticular video session (sd tells you the info), then verify the encoding is supported by your copy of nv by clicking "encoding" menu item. >What's the story with this stuff? Ah, I've just recalled another fate... IGMP support codes (sys/netinet/igmp.c) in IP-Multicast 3.3 package, which I believe is the basis of FreeBSD multicast codes, is *TOTALLY* broken. A bug makes IGMP response timeouts too fast on big endian machines and causes IGMP packet traffic on the network unnecessarily high, but applications such as nv still runs. On little endian machines, on the other hand, the bug makes the timeouts too slow and makes the system fail to send IGMP responses to a local mrouter within time limits. Hence, the mrouter sometimes stops feeding IP multicast packets to me. Nv stops working, indicating "signal lost", if this happens. (It usually restarts after one or two minutes, by the way.) Temporary solution to the problem is very easy. You will find a function named igmp_input in sys/netinet/igmp.c. It inludes a line something like this: timer = ntohs(igmp->igmp_code); You should change it to: timer = igmp->igmp_code; This change forces your FreeBSD box to behave just like Sparc boxes; it is still buggy, and generates unnecessarily high IGMP traffic, but multicast applications run fine. Hope this (somewhat long) message helps.