Date: Tue, 4 Apr 95 10:18:55 JST From: Masahiro SEKIGUCHI <seki@sysrap.cs.fujitsu.co.jp> To: "Jordan K. Hubbard" <jkh@FreeBSD.org> Cc: hackers@FreeBSD.org Subject: Re: Whee - I've got my MBONE feed.. Message-ID: <9504040118.AA00039@seki.sysrap.cs.fujitsu.co.jp> References: <199504031156.EAA02326@time.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9504040118.AA00039>