Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 03 Apr 1995 21:17:29 -0700
From:      "Jordan K. Hubbard" <jkh@freefall.cdrom.com>
To:        Masahiro SEKIGUCHI <seki@sysrap.cs.fujitsu.co.jp>
Cc:        "Jordan K. Hubbard" <jkh@FreeBSD.org>, hackers@FreeBSD.org
Subject:   Re: Whee - I've got my MBONE feed.. 
Message-ID:  <1974.796969049@freefall.cdrom.com>
In-Reply-To: Your message of "Tue, 04 Apr 95 10:18:55 %2B0200." <9504040118.AA00039@seki.sysrap.cs.fujitsu.co.jp> 

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.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1974.796969049>