Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Aug 1997 10:03:50 -0700
From:      Amancio Hasty <hasty@rah.star-gate.com>
To:        Luigi Rizzo <luigi@labinfo.iet.unipi.it>
Cc:        CSP1DWD@MVS.OAC.UCLA.EDU, multimedia@FreeBSD.ORG
Subject:   Re: guspnp17 and vat/rat 
Message-ID:  <199708261703.KAA05425@rah.star-gate.com>
In-Reply-To: Your message of "Tue, 26 Aug 1997 15:34:00 %2B0200." <199708261334.PAA00328@labinfo.iet.unipi.it> 

next in thread | previous in thread | raw e-mail | index | archive | help

Hmmm... 

The problem of the GUS PnP with Vat has nothing to do with blocking
vs non-blocking i/o. For starters, the audio module for vat
never generates a short write because prior to writing it checks
to see if the sound driver has enough space.

vat does not relie on silence intervals to resync rather on 
the frequency of reads . In this case, vat loops on reading
from the sound card to derive its internal clock. It reads
160 bytes at a time and prior to issuing the read call it 
checks if the read has enough bytes to read.

In audio-voxware.cc:
int VoxWare::FrameReady() 
{
  int i, io;
  count_info info;
 
 
  io =  ioctl(fd, SNDCTL_DSP_GETIPTR, &info); 
 
  if (info.blocks > 0 )
    frame_ready = 1;
  else frame_ready = 0;
 
  return frame_ready;
 
 
} 

The above method is trigger from a select call from tk/tcl and 
is always called prior to reading to determine if the sound card is
ready to read . Now Luigi, has probably not implemented 
ioctl(fd, SNDCTL_DSP_GETIPTR, &info) which is a different story.


In vat , the unit of I/O for both read and write is 160 bytes or 20ms .


	Cheers,
	Amancio

>From The Desk Of Luigi Rizzo :
> From what I know, rat tries to adapt to differences in play/record
> speeds, whereas vat does not and relies to silence intervals to resync.
> As a consequence, rat should never cause overruns, whereas vat might.
> On top of this, Amancio's driver uses non blocking io and seems not to
> check the return value from write()s to the device. So, on overruns,
> partial blocks might be written, and this could cause the observed
> behaviours (both in vat and mpeg123, which I have not looked at).
> 
> With my new driver I have had a chance to look at many interface
> modules for the audio devices. Almost all of them use non-blocking io
> and do not really check for error conditions short writes. My sound
> driver distribution has updated interface modules for many applications
> (including vat), which are tested with my code but might work well with
> guspnp as well.
> 
> 	Cheers
> 	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/
> _____________________________|______________________________________





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