From owner-freebsd-hackers Mon Apr 3 21:17:31 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA01982 for hackers-outgoing; Mon, 3 Apr 1995 21:17:31 -0700 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id VAA01975; Mon, 3 Apr 1995 21:17:30 -0700 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Masahiro SEKIGUCHI cc: "Jordan K. Hubbard" , hackers@FreeBSD.org Subject: Re: Whee - I've got my MBONE feed.. In-reply-to: Your message of "Tue, 04 Apr 95 10:18:55 +0200." <9504040118.AA00039@seki.sysrap.cs.fujitsu.co.jp> Date: Mon, 03 Apr 1995 21:17:29 -0700 Message-ID: <1974.796969049@freefall.cdrom.com> From: "Jordan K. Hubbard" 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. As you probably read later, I did manage to get video working successfully. The audio end comes next. > 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. If this is truly the case then it would be SERIOUSLY worth our while to try and find out what those are and emulate them! We're already fairly close to Sun-compat /dev/audio support and it just makes no sense to stop before reaching full compliance, yes? Do you know how we could find this information out? Any BSDI weenies out there know the appropriate magic being worked over there? > /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 believe Amancio & Jim are working on this now. Right guys? Guys?? :-) > 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. That would be Amancio Hasty, I believe. hasty@netcom.com is his email address. If the cheaper/more common cards cannot be supported at all (not even for *output*?? :-( ) then this will be a great shame as Creative Labs and their clones are taking over the PC audio card industry! Perhaps you, Amancio, Andrew & Jim could take an interest in collaboratively looking over the new VOXWARE 3.0 code? It was just released and pointed out to us. It would also be nice if someone "championed" Audio in -current so that all of this works a lot better a lot more often! Andrew has done in the past, are you still "Mr Audio", Andrew? :-). > 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. We really should find out what they are.. We have the source! We should fix these things! :-) > 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 The problem was that no video signal was being broadcast at the time on the channels I was using, not that nv was broken. I was just clueless about the MBONE's indicators for "live" channels and dead ones when I first started using things.. :-) I've since learned a little more, and am quite intrigued by all of this! > 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. Anyone know if this is still there? There have been a lot of mbone fixes going into -current these days.. Thanks for your comments! Jordan