From owner-freebsd-multimedia Tue Jan 16 11:38:39 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA05374 for multimedia-outgoing; Tue, 16 Jan 1996 11:38:39 -0800 (PST) Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.9.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA05364 for ; Tue, 16 Jan 1996 11:38:35 -0800 (PST) Received: (from james@localhost) by miller.cs.uwm.edu (8.7.3/8.7.3) id NAA23377; Tue, 16 Jan 1996 13:37:22 -0600 Date: Tue, 16 Jan 1996 13:37:22 -0600 From: Jim Lowe Message-Id: <199601161937.NAA23377@miller.cs.uwm.edu> To: brad@american.com, dwhite@resnet.uoregon.edu Subject: Re: vat: no audio output Cc: brad@mozart.american.com, hasty@rah.star-gate.com, multimedia@freebsd.org, multimedia@rah.star-gate.com Sender: owner-multimedia@freebsd.org Precedence: bulk > It's an interesting artifact of the vat code that if the audio open fails, > then the VU meters don't do anything even if audio is being received from > the net... > > (so, for example, if /dev/audio is not accessible to your process, because > it's chmod 600, vat looks dead even if you are getting audio from the net) > -brad > Yes, I think this has to do with the design of vat. Try listening to 3 or four sessions at the same time. The VU meters will only work on the one that is currently active. This is really an artifact of how the internal vat clock works. It reads samples from the sound card to determine timing characteristics. This works well if you are in the workstation world and sound cards actually produce the frequency's that they are asked to. This doesn't work so well in the PC world where soundcard will produce something that is close to the frequency you ask for. The problem isn't an easy one to solve. Vmix attempts to solve the problem by using system interval timers to clock things, but this still isn't a real good solution. -Jim From owner-freebsd-multimedia Thu Jan 18 10:40:24 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA24358 for multimedia-outgoing; Thu, 18 Jan 1996 10:40:24 -0800 (PST) Received: from felix.acet.org (FELIX.ACET.ORG [192.188.104.49]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA24349 for ; Thu, 18 Jan 1996 10:40:19 -0800 (PST) Received: from becky.acet.org.noname by felix.acet.org (4.1/SMI-4.1) id AA01214; Thu, 18 Jan 96 13:41:55 EST Received: by becky.acet.org.noname (4.1/SMI-4.1) id AA14967; Thu, 18 Jan 96 13:40:50 EST From: tlehman@becky.acet.org (Tom) Message-Id: <9601181840.AA14967@becky.acet.org.noname> Subject: FreeBSD and VAT To: multimedia@rah.star-gate.com, multimedia@freebsd.org Date: Thu, 18 Jan 1996 13:40:49 -0500 (EST) Cc: toml@mitre.org X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-multimedia@freebsd.org Precedence: bulk Hi, I have recently installed FreeBSD 2.1 (via CD) and set everything up with the MBONE tools. I am using mrouted version 3.8, sd, and vat-and-half (from rah.star-gate.com). Everything seems to work fine, except the vat audio is very choppy. I am using a Soundblaster 16 soundcard and the sound driver provided on the FreeBSD 2.1 CD. Can anyone help me with some suggestions on how to improve this. Is this a multicasting problem or is this just the best I can expect with an inexpensive soundcard? Any help will be greatly appreciated. Thanks! Tom Lehman tlehman@becky.acet.org From owner-freebsd-multimedia Thu Jan 18 10:56:41 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA25285 for multimedia-outgoing; Thu, 18 Jan 1996 10:56:41 -0800 (PST) Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.9.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA25280 for ; Thu, 18 Jan 1996 10:56:39 -0800 (PST) Received: (from james@localhost) by miller.cs.uwm.edu (8.7.3/8.7.3) id MAA06528; Thu, 18 Jan 1996 12:56:27 -0600 Date: Thu, 18 Jan 1996 12:56:27 -0600 From: Jim Lowe Message-Id: <199601181856.MAA06528@miller.cs.uwm.edu> To: multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org Subject: Re: FreeBSD and VAT Cc: toml@mitre.org Sender: owner-multimedia@freebsd.org Precedence: bulk > Hi, I have recently installed FreeBSD 2.1 (via CD) and set everything > up with the MBONE tools. I am using mrouted version 3.8, sd, and > vat-and-half (from rah.star-gate.com). Everything seems to work > fine, except the vat audio is very choppy. I am using a > Soundblaster 16 soundcard and the sound driver provided on the FreeBSD > 2.1 CD. > > Can anyone help me with some suggestions on how to improve this. Is > this a multicasting problem or is this just the best > I can expect with an inexpensive soundcard? There are several ways to find out what the problem is. The easiest method would be to click on the receiving person with . This brings up the stats page. Look for lost packets and such. You can plot the packets missing, duplicates or whatever by clicking on the appropriate radio button. The soundblaster will probably always sound a little choppy just because it really doesn't run at 8khz. The way to fix that is to purchase a full duplex sound card which contains a CS4231 codec that will actually produce 8khz when you ask for 8khz. The only card that I know which does this is the Gus PnP card. I don't have one yet (they are fairly new) but Amancio says it works great. -Jim From owner-freebsd-multimedia Thu Jan 18 11:24:45 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA26697 for multimedia-outgoing; Thu, 18 Jan 1996 11:24:45 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA26691 for ; Thu, 18 Jan 1996 11:24:40 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA18399; Thu, 18 Jan 1996 20:25:34 +0100 From: Luigi Rizzo Message-Id: <199601181925.UAA18399@labinfo.iet.unipi.it> Subject: Re: FreeBSD and VAT To: james@miller.cs.uwm.edu (Jim Lowe) Date: Thu, 18 Jan 1996 20:25:33 +0100 (MET) Cc: multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org In-Reply-To: <199601181856.MAA06528@miller.cs.uwm.edu> from "Jim Lowe" at Jan 18, 96 12:56:08 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org Precedence: bulk > The soundblaster will probably always sound a little choppy just because it > really doesn't run at 8khz. The way to fix that is to purchase a full duplex ^^^^^^^^^^^^^^^^^^^ What do you mean by that ? You cannot expect any two cards to have exactly the same rate, so the software (and I mean the user-level software, not the device driver) must compensate speed mismatches by removing/adding samples. If it doesn't in a soft way (by means of small corrections at every segment), sooner or later you will be way out of sync and you will hear clicks. I cannot tell what is the maximum % difference in sample rates which can give acceptable results (it depends a lot on the block size you are using), but my feeling is that 1% or less should not give too bad results. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-multimedia Thu Jan 18 12:07:52 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id MAA28849 for multimedia-outgoing; Thu, 18 Jan 1996 12:07:52 -0800 (PST) Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.9.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA28840 for ; Thu, 18 Jan 1996 12:07:45 -0800 (PST) Received: (from james@localhost) by miller.cs.uwm.edu (8.7.3/8.7.3) id OAA10985; Thu, 18 Jan 1996 14:07:16 -0600 Date: Thu, 18 Jan 1996 14:07:16 -0600 From: Jim Lowe Message-Id: <199601182007.OAA10985@miller.cs.uwm.edu> To: luigi@labinfo.iet.unipi.it Subject: Re: FreeBSD and VAT Cc: multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org Sender: owner-multimedia@freebsd.org Precedence: bulk > > The soundblaster will probably always sound a little choppy just because it > > really doesn't run at 8khz. The way to fix that is to purchase a full duplex > ^^^^^^^^^^^^^^^^^^^ > > What do you mean by that ? You cannot expect any two cards to have > exactly the same rate, so the software (and I mean the user-level > software, not the device driver) must compensate speed mismatches > by removing/adding samples. If it doesn't in a soft way (by means > of small corrections at every segment), sooner or later you will > be way out of sync and you will hear clicks. > > I cannot tell what is the maximum % difference in sample rates > which can give acceptable results (it depends a lot on the block > size you are using), but my feeling is that 1% or less should not > give too bad results. > Usually the sound cards are not even close to 8khz. They are sometimes off by > 1khz depending on the sound card. Vat doesn't take this into consideration. In fact, Vat uses the sound card for a timer. It assumes that the packets are arriving at 8khz and uses this value, no matter what the record rate actually is, as Vat's internal clock. The block/packet size in vat is 160 bytes (or 20ms @ 8khz). I don't think that 1% would be a problem for short bursty conversations. If one was playing a CD for a long period of time (say 40 minutes), or listening to a conference, then 1% compounded could be a problem -- since then it is 1% per second for 40 minutes. I don't know that I agree with the way they implemented the internal clock in vat, but I am not sure they had much to choose from. They wanted the program to run on a variety of systems. The only thing that I can think of that will give you 20ms resolution would be the system interval timer (which I am not sure if it available on all systems such at NT, Macs, Windows, etc...) or reading 8000hz samples (160 byte blocks) from a sound card. Now on Sun, Dec, and workstation type systems, the variance in the sound cards is about .001%. This is also true about the CS4231 codec on the GUS PnP cards if my test program was working correctly when Amancio ran it. My GUS Max card has a variance of about 2% at 8000hz if I tell it to run at 8230hz. I can make a PAS-16 have a variance of about .1% if I run it at 8116hz. The problem is that not every PC sound card works the same. Some of this depends on the bus and chipset timing. The CS4231 actually goes through a calibration cycle to set the correct frequency. The VOXware sound drivers that are in FreeBSD/Linux do not attempt to do frequency correction in the drivers. But if someone would like to do this, the code is certainly available :-). Vmix attempts to correct for this utilizing interval timers -- but doesn't do a real good job. Attached is the program I used for timing of various sound cards. -Jim ----------------------------------------------- #include #include #include #include #include #include #include /* #define BROKEN_SELECT /* soundcard needs read before select */ char *dev="/dev/dsp1"; /* or on command line */ int blocksize = 160; main(int ac, char **av) { struct timeval tv, start; int fd; fd_set rfd; int cc; int i; double u; if(ac>1) dev = av[1]; if((fd=open(dev, O_RDONLY)) < 0) { perror(dev); exit(-1); } if(ioctl(fd, SNDCTL_DSP_SETBLKSIZE, &blocksize) < 0) { printf("Setting blocksize failed: %s\n", strerror(errno)); } #ifdef BROKEN_SELECT read(fd, dev, 1); #endif gettimeofday(&start, 0); cc = 0; i = 0; FD_ZERO(&rfd); while (1) { int n; char buf[blocksize]; FD_SET(fd, &rfd); select(fd+1, &rfd, 0, 0, 0); n = read(fd, buf, blocksize); if (n < 0) { perror("read"); exit(1); } if(n!=blocksize) printf("read %d, wanted blocksize\n", n); cc += n; if (++i >= 50) { i = 0; gettimeofday(&tv, 0); u = tv.tv_sec - start.tv_sec; u += 1e-6 * (tv.tv_usec - start.tv_usec); printf("%d %lg %lg\n", cc, u, (double)cc / u); fflush(stdout); } } } From owner-freebsd-multimedia Thu Jan 18 14:40:25 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id OAA09249 for multimedia-outgoing; Thu, 18 Jan 1996 14:40:25 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id OAA09241 for ; Thu, 18 Jan 1996 14:40:12 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id XAA18683; Thu, 18 Jan 1996 23:41:33 +0100 From: Luigi Rizzo Message-Id: <199601182241.XAA18683@labinfo.iet.unipi.it> Subject: Re: FreeBSD and VAT To: james@miller.cs.uwm.edu (Jim Lowe) Date: Thu, 18 Jan 1996 23:41:33 +0100 (MET) Cc: multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org In-Reply-To: <199601182007.OAA10985@miller.cs.uwm.edu> from "Jim Lowe" at Jan 18, 96 02:06:57 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org Precedence: bulk > Usually the sound cards are not even close to 8khz. They are sometimes > off by > 1khz depending on the sound card. Vat doesn't take this into > consideration. In fact, Vat uses the sound card for a timer. It assumes > that the packets are arriving at 8khz and uses this value, no matter what > the record rate actually is, as Vat's internal clock. The block/packet > size in vat is 160 bytes (or 20ms @ 8khz). I think there still is a solution, similar to what is used to put the time-of-day clocks in sync on Unix systems. It must be applied to the receive side, of course. Once you see that packets arrive faster than what the sound card can cope, "compress" packets. If they arrive slower than expected, "expand" them. Theoretically, compression and expansion should be done by resampling the data (expensive) but, given the small differences (1-2 bytes per segment) it probably suffices to duplicate/clip the last bytes of the packet. It helps if you add a 1-packet buffer between the network and the audio device, so you can realize that packets are coming slowly without actually remaining without data. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-multimedia Thu Jan 18 18:27:16 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA23836 for multimedia-outgoing; Thu, 18 Jan 1996 18:27:16 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id SAA23830 for ; Thu, 18 Jan 1996 18:27:11 -0800 (PST) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id SAA05047; Thu, 18 Jan 1996 18:23:49 -0800 Message-Id: <199601190223.SAA05047@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Luigi Rizzo cc: james@miller.cs.uwm.edu (Jim Lowe), multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org Subject: Re: FreeBSD and VAT In-reply-to: Your message of "Thu, 18 Jan 1996 23:41:33 +0100." <199601182241.XAA18683@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Jan 1996 18:23:48 -0800 From: "Amancio Hasty Jr." Sender: owner-multimedia@freebsd.org Precedence: bulk Hi, We do have a problem with most cards not keeping an accurate frequency and in fact it can be also a problem for workstations. You are a little off here. I would rather read the packets at a regular interval on the driver than attempt to compress or decompress packets. At any rate, this is an intellectual exercise for our sound blaster champions or our OS gurus 8) I really not sure why vat has to rely on a soundcard to keep its internal clock -- sounds kludgy to me. >>> Luigi Rizzo said: > > Usually the sound cards are not even close to 8khz. They are sometimes > > off by > 1khz depending on the sound card. Vat doesn't take this into > > consideration. In fact, Vat uses the sound card for a timer. It assumes > > that the packets are arriving at 8khz and uses this value, no matter what > > the record rate actually is, as Vat's internal clock. The block/packet > > size in vat is 160 bytes (or 20ms @ 8khz). > > I think there still is a solution, similar to what is used to put > the time-of-day clocks in sync on Unix systems. It must be applied > to the receive side, of course. > > Once you see that packets arrive faster than what the sound card > can cope, "compress" packets. If they arrive slower than expected, > "expand" them. Theoretically, compression and expansion should be > done by resampling the data (expensive) but, given the small > differences (1-2 bytes per segment) it probably suffices to > duplicate/clip the last bytes of the packet. It helps if you add > a 1-packet buffer between the network and the audio device, so you > can realize that packets are coming slowly without actually remaining > without data. > > Luigi > ==================================================================== > Luigi Rizzo Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it Universita' di Pisa > tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ > ==================================================================== From owner-freebsd-multimedia Fri Jan 19 01:10:46 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id BAA00951 for multimedia-outgoing; Fri, 19 Jan 1996 01:10:46 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id BAA00866 for ; Fri, 19 Jan 1996 01:08:15 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id KAA19591; Fri, 19 Jan 1996 10:01:38 +0100 From: Luigi Rizzo Message-Id: <199601190901.KAA19591@labinfo.iet.unipi.it> Subject: Re: FreeBSD and VAT To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Fri, 19 Jan 1996 10:01:38 +0100 (MET) Cc: james@miller.cs.uwm.edu, multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org In-Reply-To: <199601190223.SAA05047@rah.star-gate.com> from "Amancio Hasty Jr." at Jan 18, 96 06:23:29 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org Precedence: bulk > Hi, > > We do have a problem with most cards not keeping an accurate frequency > and in fact it can be also a problem for workstations. > > You are a little off here. I would rather read the packets at a regular > interval on the driver than attempt to compress or decompress packets. this does not solve the problem. The best thing the output driver can do (assuming it has a correct clock with sufficient resolution) is to eat samples at 8 KHz. BUT: if the sender is claiming 8KHz but in fact uses a different sample rate (because of inaccuraces), this does not fix anything. It is the receiver side that must adapt to what is coming in (within reasonable tolerance). TV sets have always done this way, they adjust their hsync and vsync to whatever is coming in. What the output driver might try to do, _when working with a stream of incoming data_, is to change speed (i.e. add/discard samples) to avoid the input queue exceed soe low/hi water mark. Only correcting the speed is not enough. > At any rate, this is an intellectual exercise for our sound blaster > champions or our OS gurus 8) In the long term it should go in the driver, I agree. In the short term I think the easiest place to fix this is within the application. > > >>> Luigi Rizzo said: > > > > I think there still is a solution, similar to what is used to put > > the time-of-day clocks in sync on Unix systems. It must be applied > > to the receive side, of course. The comparison with TV sets is more appropriate. But yesterday night was late! > > Once you see that packets arrive faster than what the sound card > > can cope, "compress" packets. If they arrive slower than expected, > > "expand" them. Theoretically, compression and expansion should be > > done by resampling the data (expensive) but, given the small > > differences (1-2 bytes per segment) it probably suffices to > > duplicate/clip the last bytes of the packet. It helps if you add > > a 1-packet buffer between the network and the audio device, so you > > can realize that packets are coming slowly without actually remaining > > without data. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-multimedia Fri Jan 19 03:08:19 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA08035 for multimedia-outgoing; Fri, 19 Jan 1996 03:08:19 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA08029 for ; Fri, 19 Jan 1996 03:08:16 -0800 (PST) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id DAA00513; Fri, 19 Jan 1996 03:05:03 -0800 Message-Id: <199601191105.DAA00513@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Luigi Rizzo cc: james@miller.cs.uwm.edu, multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org Subject: Re: FreeBSD and VAT In-reply-to: Your message of "Fri, 19 Jan 1996 10:01:38 +0100." <199601190901.KAA19591@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 1996 03:05:03 -0800 From: "Amancio Hasty Jr." Sender: owner-multimedia@freebsd.org Precedence: bulk >>> Luigi Rizzo said: > can do (assuming it has a correct clock with sufficient resolution) > is to eat samples at 8 KHz. BUT: if the sender is claiming 8KHz > but in fact uses a different sample rate (because of inaccuraces), > this does not fix anything. Well, it looks like the easiest thing is to dump vat and just rely on whatever frequency the card runs at. There is no easy way to adjust for frequency oscillations on the receiver side. You would have to have a reference point interlace with the data in order for the receiver to adjust accordingly. Due to the undeterministic behavior of the net it is not sufficient nor desired to depend on the frequency of the incoming packets so in my opinion the reference point would have to be part of the data stream. All fun and games however I think that it would be easier to come up with a different audio tool than to fix vat. The other problem that vat suffers from is that it uses for gsm 8 bit ulaw which is totally bogus. From the gsm's README: GSM 06.10 compresses frames of 160 13-bit samples (8 kHz sampling rate, i.e. a frame rate of 50 Hz) into 260 bits; for compatibility with typical UNIX applications, our implementation turns frames of 160 16-bit linear samples into 33-byte frames (1650 Bytes/s). So for our environment it is not desirable to use ulaw because this encurs further unnecessary processing on the system and we may lose precision when expanding 8bit ulaw to 16 bit to be able to feed it to gsm encoding algorithm and I really hate to see what happens on the receiver side. Amancio From owner-freebsd-multimedia Fri Jan 19 03:30:21 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA09250 for multimedia-outgoing; Fri, 19 Jan 1996 03:30:21 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA09211 for ; Fri, 19 Jan 1996 03:29:58 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA00392; Fri, 19 Jan 1996 12:25:02 +0100 From: Luigi Rizzo Message-Id: <199601191125.MAA00392@labinfo.iet.unipi.it> Subject: Re: FreeBSD and VAT To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Fri, 19 Jan 1996 12:25:01 +0100 (MET) Cc: james@miller.cs.uwm.edu, multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org In-Reply-To: <199601191105.DAA00513@rah.star-gate.com> from "Amancio Hasty Jr." at Jan 19, 96 03:04:44 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org Precedence: bulk > Well, it looks like the easiest thing is to dump vat and just rely > on whatever frequency the card runs at. > > There is no easy way to adjust for frequency oscillations on the > receiver side. You would have to have a reference point interlace with the > data in order for the receiver to adjust accordingly. Due to the > undeterministic behavior of the net it is not sufficient nor desired > to depend on the frequency of the incoming packets so in my opinion > the reference point would have to be part of the data stream. > > All fun and games however I think that it would be easier to come up > with a different audio tool than to fix vat. I jumped in the discussion because I believe this is a general problem, not only with VAT (which I have never used). The fact that the net is undeterministic may cause jitter and segment losses. jitter can be compensated somewhat by adding some buffering (and delay) between the net and the audio output. Segment losses can be easily detected if segments carry some sequence number or so (is this the "reference point" you mention before ?). I think they do, or at least they ought to. Differences in the sample rate between the sender and the receiver will *always* exist to some extent, and are not affected by jitter or segment losses. Even small differences accumulate and will cause clicks in the output, unless the receiver syncronizes with the sender. I did not say that this should be done by fine adjustments of the sample frequency at the receiver side. This might be hard or unfeasible. I said that the same effect can be achieved by adding/dropping samples in the stream of data sent to the audio output. > The other problem that vat suffers from is that it uses for gsm > 8 bit ulaw which is totally bogus. From the gsm's README: > > GSM 06.10 compresses frames of 160 13-bit samples (8 kHz sampling > rate, i.e. a frame rate of 50 Hz) into 260 bits; for compatibility > with typical UNIX applications, our implementation turns frames of 160 > 16-bit linear samples into 33-byte frames (1650 Bytes/s). > > So for our environment it is not desirable to use ulaw because this > encurs further unnecessary processing on the system and we may lose > precision when expanding 8bit ulaw to 16 bit to be able to feed it ulaw/alaw to linear is simply a table lookup without loss of precision. Linear to u/alaw is equally a table lookup, although the table is larger and you loose some LSBs (but the quality remains ulaw). The overhead for both conversions is definitely negligible WRT the GSM compression/decompression. Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-multimedia Fri Jan 19 03:51:13 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA10061 for multimedia-outgoing; Fri, 19 Jan 1996 03:51:13 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA10056 for ; Fri, 19 Jan 1996 03:51:10 -0800 (PST) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id DAA00952; Fri, 19 Jan 1996 03:47:45 -0800 Message-Id: <199601191147.DAA00952@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Luigi Rizzo cc: james@miller.cs.uwm.edu, multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org Subject: Re: FreeBSD and VAT In-reply-to: Your message of "Fri, 19 Jan 1996 12:25:01 +0100." <199601191125.MAA00392@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 1996 03:47:44 -0800 From: "Amancio Hasty Jr." Sender: owner-multimedia@freebsd.org Precedence: bulk >>> Luigi Rizzo said: > > The overhead for both conversions is definitely negligible WRT the GSM > compression/decompression. rtpv2 does have a sequence number in the packets however we still have the problem that the sample may have been recorded within a given delta offset of the intended frequency . For instance, the card may oscillate and start recording a sample at 6000hz then pass that on to vat -- what do you then? Well Jim's solution is to depend on the system clock to at least attempt to provide an accurate time sample however his program breaks down because the system clock itself oscillates and I have heard Jim when his system clock gets updated by his nntp daemon. Well, we still have problems for cards which don't support ulaw. Probably there are more cards which support 16bit i/o output than ulaw. You see ulaw for cards which don't have ulaw hardware compression the driver does the conversion. For low end machines this begins to strain the system. The GUS PnP supports ulaw and alaw in hardware. At any rate, I am losing track . Any suggestions, as to how to solve the problem that certain cards don't run at given frequency and that they tend to oscillate. Tnks, Amancio Lets make sure that for those buying new sound gear for FreeBSD that they should at least consider the GUS PnP. From owner-freebsd-multimedia Fri Jan 19 04:41:34 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA12616 for multimedia-outgoing; Fri, 19 Jan 1996 04:41:34 -0800 (PST) Received: from ceres.fokus.gmd.de (ceres.fokus.gmd.de [192.35.149.15]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA12606 for ; Fri, 19 Jan 1996 04:41:22 -0800 (PST) Message-Id: <199601191241.EAA12606@freefall.freebsd.org> Received: from lupus (actually lupus.fokus.gmd.de) by ceres.fokus.gmd.de with SMTP (PP-ICR1v5); Fri, 19 Jan 1996 13:39:38 +0100 X-Mailer: exmh version 1.6.5 12/11/95 To: "Amancio Hasty Jr." cc: multimedia@freebsd.org, multimedia@rah.star-gate.com From: Henning Schulzrinne X-Url: http://www.fokus.gmd.de/step/hgs/ Subject: Re: FreeBSD and VAT In-reply-to: Your message of "Fri, 19 Jan 1996 03:47:44 PST." <199601191147.DAA00952@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 1996 13:39:33 +0100 Sender: owner-multimedia@freebsd.org Precedence: bulk > > Any suggestions, as to how to solve the problem that certain cards > don't run at given frequency and that they tend to oscillate. > If you know the "real" rate, just configure your card to run at a different nominal frequency (it sounds like they can be adjusted to any rate). If the card can't keep its frequency stable, it will sound like a tape deck which can't move the tape at constant frequency. For voice, pauses between sentences and/or turn taking will take care of even large frequency deviations. For music, you probably don't want to listen to a card that can't keep pitch... Given how cheap crystal oscillators are, I'm amazed that people build cards that can't stick to a nominal frequency. (All useful frequencies are multiples of either 8000 or 11025 Hz, it seems.) Henning Schulzrinne From owner-freebsd-multimedia Fri Jan 19 05:33:01 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA14544 for multimedia-outgoing; Fri, 19 Jan 1996 05:33:01 -0800 (PST) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA14529 for ; Fri, 19 Jan 1996 05:32:51 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA00599; Fri, 19 Jan 1996 14:24:10 +0100 From: Luigi Rizzo Message-Id: <199601191324.OAA00599@labinfo.iet.unipi.it> Subject: Re: FreeBSD and VAT To: hasty@rah.star-gate.com (Amancio Hasty Jr.) Date: Fri, 19 Jan 1996 14:24:09 +0100 (MET) Cc: james@miller.cs.uwm.edu, multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org In-Reply-To: <199601191147.DAA00952@rah.star-gate.com> from "Amancio Hasty Jr." at Jan 19, 96 03:47:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org Precedence: bulk > rtpv2 does have a sequence number in the packets however we still have > the problem that the sample may have been recorded within a given > delta offset of the intended frequency . For instance, the card may > oscillate and start recording a sample at 6000hz then pass that on > to vat -- what do you then? Well Jim's solution is to depend on the If the card claims 8KHz and it 25% off, it's badly broken and we can't help much. If the card is within 2-3% of its nominal frequency, as Jim suggested, that means a difference of 4-5 bytes per packet, and I think we can easily compensate it. Remember, the "clock" can only be the sender's sample rate. It may have jitter or be inaccurate, but it rules the speed at which data come in. > Well, we still have problems for cards which don't support ulaw. Probably > there are more cards which support 16bit i/o output than ulaw. > You see ulaw for cards which don't have ulaw hardware compression > the driver does the conversion. For low end machines this begins to > strain the system. I don't get this. ulaw and alaw conversion it's a simple table lookup: for (i=0;i; Fri, 19 Jan 1996 06:38:03 -0800 (PST) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA00749; Fri, 19 Jan 1996 15:34:49 +0100 From: Luigi Rizzo Message-Id: <199601191434.PAA00749@labinfo.iet.unipi.it> Subject: Re: FreeBSD and VAT To: schulzrinne@fokus.gmd.de (Henning Schulzrinne) Date: Fri, 19 Jan 1996 15:34:48 +0100 (MET) Cc: hasty@rah.star-gate.com, multimedia@freebsd.org, multimedia@rah.star-gate.com In-Reply-To: <199601191239.EAA01431@rah.star-gate.com> from "Henning Schulzrinne" at Jan 19, 96 01:39:14 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org Precedence: bulk > Given how cheap crystal oscillators are, I'm amazed that people build > cards that can't stick to a nominal frequency. (All useful frequencies > are multiples of either 8000 or 11025 Hz, it seems.) I believe all cards have crystals. The cheapest ones can only run at certain discrete frequencies which are an integral submultiples of the crystal. More sophisticated cards have a full synthetizer which allows a wider range of choices sample_freq = crystal * N1/N2 Luigi ==================================================================== Luigi Rizzo Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it Universita' di Pisa tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ ==================================================================== From owner-freebsd-multimedia Fri Jan 19 07:10:49 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id HAA18207 for multimedia-outgoing; Fri, 19 Jan 1996 07:10:49 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id HAA18202 for ; Fri, 19 Jan 1996 07:10:41 -0800 (PST) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id HAA02578; Fri, 19 Jan 1996 07:08:17 -0800 Message-Id: <199601191508.HAA02578@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Luigi Rizzo cc: schulzrinne@fokus.gmd.de (Henning Schulzrinne), multimedia@freebsd.org, multimedia@rah.star-gate.com Subject: Re: FreeBSD and VAT In-reply-to: Your message of "Fri, 19 Jan 1996 15:34:48 +0100." <199601191434.PAA00749@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 1996 07:08:16 -0800 From: "Amancio Hasty Jr." Sender: owner-multimedia@freebsd.org Precedence: bulk The question is can they keep a lock on the frequency and if packet size can induce oscillations. It will be interesting if someone lets say with a SB to run Jim's test program with various buffer sizes. I would start with 160 and just try to measure the behavior of the card in lets say multiples of 160 to 2048 or so . It would not surprise if some cards have problems with keeping a frequency with small packets. Amancio >>> Luigi Rizzo said: > > Given how cheap crystal oscillators are, I'm amazed that people build > > cards that can't stick to a nominal frequency. (All useful frequencies > > are multiples of either 8000 or 11025 Hz, it seems.) > > I believe all cards have crystals. The cheapest ones > can only run at certain discrete frequencies which are an integral > submultiples of the crystal. More sophisticated cards have a full > synthetizer which allows a wider range of choices > > sample_freq = crystal * N1/N2 > > Luigi > ==================================================================== > Luigi Rizzo Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it Universita' di Pisa > tel: +39-50-568533 via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 http://www.iet.unipi.it/~luigi/ > ==================================================================== From owner-freebsd-multimedia Fri Jan 19 08:57:42 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id IAA26635 for multimedia-outgoing; Fri, 19 Jan 1996 08:57:42 -0800 (PST) Received: from miller.cs.uwm.edu (miller.cs.uwm.edu [129.89.9.13]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id IAA26626 for ; Fri, 19 Jan 1996 08:57:34 -0800 (PST) Received: (from james@localhost) by miller.cs.uwm.edu (8.7.3/8.7.3) id KAA15680; Fri, 19 Jan 1996 10:56:03 -0600 Date: Fri, 19 Jan 1996 10:56:03 -0600 From: Jim Lowe Message-Id: <199601191656.KAA15680@miller.cs.uwm.edu> To: hasty@rah.star-gate.com, schulzrinne@fokus.gmd.de Subject: Re: FreeBSD and VAT Cc: multimedia@freebsd.org, multimedia@rah.star-gate.com Sender: owner-multimedia@freebsd.org Precedence: bulk > From: Henning Schulzrinne > > > > > Any suggestions, as to how to solve the problem that certain cards > > don't run at given frequency and that they tend to oscillate. > > > If you know the "real" rate, just configure your card to run at a > different nominal frequency (it sounds like they can be adjusted to any > rate). If the card can't keep its frequency stable, it will sound like > a tape deck which can't move the tape at constant frequency. For voice, > pauses between sentences and/or turn taking will take care of even > large frequency deviations. For music, you probably don't want to > listen to a card that can't keep pitch... > > Given how cheap crystal oscillators are, I'm amazed that people build > cards that can't stick to a nominal frequency. (All useful frequencies > are multiples of either 8000 or 11025 Hz, it seems.) Yes, and maybe this is the real solution. Just come up with a device that one can seperatly calibrate. Maybe something like /dev/caudio (calibrated audio). Then run a calibration program that would sample against the time of day clock and set the frequency based on sampled results. The calibration program could be run at boot up of the system and determine actual speeds for the different sound cards and tell the driver what these speeds are. This way when the user would ask for 8khz, they should be able to get something within .1% of 8khz from /dev/caudio (or for Amancio /dev/cdsp :-). I don't know why I didn't think of this before (a year or two ago). Thank you. I suppose one could make caudio/cdsp a little more complicated and add features for full duplex utilizing the oddities of the different sound cards. Such as pas-16, 2 SB's, SB-16, gus, gus-max, etc... This way one could have a calibrated full duplex interface for whatever application they wanted to use it for. The BSD audio interface seems to have all the stuff needed. It would certainly solve a lot of problems. Anyone care to write it and add it to the VOXware distribution? -Jim From owner-freebsd-multimedia Fri Jan 19 10:24:16 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA03031 for multimedia-outgoing; Fri, 19 Jan 1996 10:24:16 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA02964 for ; Fri, 19 Jan 1996 10:23:28 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53505(11)>; Fri, 19 Jan 1996 10:22:18 PST Received: from localhost ([127.0.0.1]) by crevenia.parc.xerox.com with SMTP id <177478>; Fri, 19 Jan 1996 10:21:46 -0800 X-Mailer: exmh version 1.6.4 10/10/95 To: Luigi Rizzo cc: hasty@rah.star-gate.com (Amancio Hasty Jr.), james@miller.cs.uwm.edu, multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org Subject: Re: FreeBSD and VAT In-reply-to: Your message of "Fri, 19 Jan 1996 03:25:01 PST." <199601191125.MAA00392@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 1996 10:21:33 PST From: Bill Fenner Message-Id: <96Jan19.102146pst.177478@crevenia.parc.xerox.com> Sender: owner-multimedia@freebsd.org Precedence: bulk In message <199601191125.MAA00392@labinfo.iet.unipi.it>you write: >Amancio wrote: >> Well, it looks like the easiest thing is to dump vat and just rely >> on whatever frequency the card runs at. This is nonsense; you still need to send data over the network at some standard rate. >The fact that the net is undeterministic may cause jitter and >segment losses. jitter can be compensated somewhat by adding some >buffering (and delay) between the net and the audio output. Segment >losses can be easily detected if segments carry some sequence number >or so (is this the "reference point" you mention before ?). In fact, vat has a playout buffer that dynamically changes in size based on currently observed network jitter. >Differences in the sample rate between the sender and the receiver will >*always* exist to some extent, and are not affected by jitter or >segment losses. Even small differences accumulate and will cause clicks >in the output, unless the receiver syncronizes with the sender. In the workstation world, where vat came from, generally audio hardware manages to be able to have an exact clock. It's too bad that PC hardware can't. >> The other problem that vat suffers from is that it uses for gsm >> 8 bit ulaw which is totally bogus. Amancio, you really need to tone down your attitude, because you can be really insulting sometimes. On most workstation platforms, 8 bit ulaw is what you get directly from the audio device -- no translation happens as it does on FreeBSD. If 8 bit ulaw is the most efficient thing to use, and the most common across platforms, then you use it! Bill From owner-freebsd-multimedia Fri Jan 19 10:49:06 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id KAA04035 for multimedia-outgoing; Fri, 19 Jan 1996 10:49:06 -0800 (PST) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id KAA04030 for ; Fri, 19 Jan 1996 10:49:03 -0800 (PST) Received: from rah.star-gate.com (localhost.v-site.net [127.0.0.1]) by rah.star-gate.com (8.6.12/8.6.12) with ESMTP id KAA00790; Fri, 19 Jan 1996 10:45:58 -0800 Message-Id: <199601191845.KAA00790@rah.star-gate.com> X-Mailer: exmh version 1.6.5 12/11/95 To: Bill Fenner cc: Luigi Rizzo , james@miller.cs.uwm.edu, multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org Subject: Re: FreeBSD and VAT In-reply-to: Your message of "Fri, 19 Jan 1996 10:21:33 PST." <96Jan19.102146pst.177478@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jan 1996 10:45:57 -0800 From: "Amancio Hasty Jr." Sender: owner-multimedia@freebsd.org Precedence: bulk >>> Bill Fenner said: > In message <199601191125.MAA00392@labinfo.iet.unipi.it>you write: > >Amancio wrote: > >> Well, it looks like the easiest thing is to dump vat and just rely > >> on whatever frequency the card runs at. > > This is nonsense; you still need to send data over the network at some > standard rate. True but why base your sense of timing on the card? > >The fact that the net is undeterministic may cause jitter and > >segment losses. jitter can be compensated somewhat by adding some > >buffering (and delay) between the net and the audio output. Segment > >losses can be easily detected if segments carry some sequence number > >or so (is this the "reference point" you mention before ?). > > In fact, vat has a playout buffer that dynamically changes in size based on > currently observed network jitter. > > >Differences in the sample rate between the sender and the receiver will > >*always* exist to some extent, and are not affected by jitter or > >segment losses. Even small differences accumulate and will cause clicks > >in the output, unless the receiver syncronizes with the sender. > > In the workstation world, where vat came from, generally audio hardware > manages to be able to have an exact clock. It's too bad that PC hardware > can't. The problem is that we have some cheap or ill design soundcards which the PC people love to buy as stated before CS4231 based cards don't have a problem the frequency problem. > >> The other problem that vat suffers from is that it uses for gsm > >> 8 bit ulaw which is totally bogus. > > Amancio, you really need to tone down your attitude, because you can be real ly > insulting sometimes. On most workstation platforms, 8 bit ulaw is what you > get directly from the audio device -- no translation happens as it does on > FreeBSD. If 8 bit ulaw is the most efficient thing to use, and the most > common across platforms, then you use it! Oh Bill, is not a matter of attitude is matter of conserving CPU cycles for low end machines which don't have hardware support. vat's interface to the sound driver should accomodate different sound formats. If I am not mistaken SGI audio interface is 16bit and not ulaw but it doesn't matter much. Lets assume that we had a capility of transmitting mpeg am I going to have to translate my mpeg input format to ulaw to accommodate vat's current handicap? Is not a matter of attitude is a matter of choice and cpu utilization. I do expect this year several affordable mpeg codecs to come to the PC arena . So what I am saying is not a hypothetical case. At any rate, I didn't mean to upset you. Take care, Amancio From owner-freebsd-multimedia Fri Jan 19 11:57:47 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA09175 for multimedia-outgoing; Fri, 19 Jan 1996 11:57:47 -0800 (PST) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA09169 for ; Fri, 19 Jan 1996 11:57:45 -0800 (PST) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53970(1)>; Fri, 19 Jan 1996 11:57:04 PST Received: from localhost by crevenia.parc.xerox.com with SMTP id <177478>; Fri, 19 Jan 1996 11:56:46 -0800 To: "Amancio Hasty Jr." cc: Bill Fenner , Luigi Rizzo , james@miller.cs.uwm.edu, multimedia@freebsd.org, multimedia@rah.star-gate.com, tlehman@becky.acet.org, toml@mitre.org Subject: Re: FreeBSD and VAT In-reply-to: Your message of "Fri, 19 Jan 96 10:45:57 PST." <199601191845.KAA00790@rah.star-gate.com> Date: Fri, 19 Jan 1996 11:56:31 PST From: Bill Fenner Message-Id: <96Jan19.115646pst.177478@crevenia.parc.xerox.com> Sender: owner-multimedia@freebsd.org Precedence: bulk In message <199601191845.KAA00790@rah.star-gate.com> you write: >>>> Bill Fenner said: > > This is nonsense; you still need to send data over the network at some > > standard rate. > >True but why base your sense of timing on the card? The reason to base your sense of timing on the audio samples that you're reading is because you have to read the audio samples anyway, and if they give you an accurate clock then that's just that much less overhead that you need to use. On real audio hardware, this is true; apparently it isn't on PC audio hardware. This just means that you need to use some higher- overhead mechanism of obtaining your timing information. >vat's interface to the sound driver should accomodate different sound formats. Up until recently, vat only ran on machines that had native ulaw codecs. Why are you bashing it for expecting a ulaw codec to exist? >If I am not >mistaken SGI audio interface is 16bit and not ulaw but it doesn't matter much. The SGI audio interface has a 16 bit mode, just like the later Sun audio interfaces; they both also have native ulaw modes. >Lets assume that we had a capility of transmitting mpeg am I going to >have to translate my mpeg input format to ulaw to accommodate vat's >current handicap? If your hardware supplies you with data in a format other than what you are going to transmit on the wire, then you must do something to it to cause it to be in the format that is expected to be transmitted on the wire. Whether this is a linear->ulaw lookup or frequency conversion or mpeg->gsm transcoding, it's necessary for interoperability. Bill (P.S. When you get your new mpeg encoder card, do you care that most of the world won't be able to hear you?) From owner-freebsd-multimedia Sat Jan 20 23:30:34 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA01853 for multimedia-outgoing; Sat, 20 Jan 1996 23:30:34 -0800 (PST) Received: from sylvia.tummy.com (efm@ariel.tummy.com [206.28.166.237]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id XAA01847 Sat, 20 Jan 1996 23:30:31 -0800 (PST) Received: (from efm@localhost) by sylvia.tummy.com (8.7.3/8.7.3) id BAA10668; Sun, 21 Jan 1996 01:30:21 -0600 From: Evelyn Mitchell Message-Id: <199601210730.BAA10668@sylvia.tummy.com> Subject: COMMERCIAL: XVScan - HP ScanJets under FreeBSD To: freebsd-announce@freebsd.org Date: Sun, 21 Jan 1996 01:30:18 -0600 (CST) Cc: freebsd-multimedia@freebsd.org X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multimedia@freebsd.org Precedence: bulk XVScan ====== Image Acquisition Software for FreeBSD, Linux and HP-UX Workstations ---------------------------------------------------------- January 20, 1996 tummy.com, ltd. xvscan@tummy.com (orders, information, customer support) http://www.tummy.com/xvscan XVScan adds scanning capability with HP ScanJet scanners to XV Version 1.17 If you've never used John Bradley's XV image manipulation software, it's difficult to describe how powerful it is. XV reads and writes files in a dozen different formats, provides powerful color-map editing, window capture, color-space conversion, cropping, image manipulation algorithms, and the list goes on. With XVScan, you now have the ability to acquire images directly into XV from your HP ScanJet scanner in a very cost efficient (and more importantly time efficient) manner. What's New in Version 1.17 1) FreeBSD support 2) Auto Document Feeder (ADF) Support 3) Web-based help 4) More error detection and reporting The SCSI card shipped by HP with the ScanJet doesn't work. XVScan was tested with the NCR SCSI board. Users of NCR 53c810 based PCI SCSI boards will need a patched version of the `/usr/src/sys/pci/ncr.c' driver to prevent the `handshake timeout' errors during the scanning phase. This has been corrected in the current development source tree. This applies to the 2.1.0 release of FreeBSD and older. The current version of XVScan is 1.17 dated 01/20/96 based upon XV version 3.10a dated 12/29/94. The ScanJet 3c support is now in. No new image types are yet supported (the 3c is capable of scanning 30-bit color and 10-bit greyscale) as XV only supports 8 and 24-bit images. 10-bit grey could be simulated using 24-bits, but 3/4 of the colors would NOT be true grey -- only 256 true greys can be held in 24-bit TrueColor. XVScan is $US50 for ftp or email delivery. Media (floppies, DDS 2 tape) is an additional $US15 within the US, $25 internationally. Contact xvscan@tummy.com to order. For more information see: http://www.tummy.com/xvscan Payment accepted via check, Visa/Mastercard/Discover cards. XVScan tummy.com, ltd. Suite 807 300 S 16th Street Omaha NE 68102 http://www.tummy.com/xvscan (402) 344-4426