From owner-freebsd-multimedia Tue Aug 26 10:04:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA21906 for multimedia-outgoing; Tue, 26 Aug 1997 10:04:30 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA21900 for ; Tue, 26 Aug 1997 10:04:25 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id KAA05425; Tue, 26 Aug 1997 10:03:50 -0700 (PDT) Message-Id: <199708261703.KAA05425@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: CSP1DWD@MVS.OAC.UCLA.EDU, multimedia@FreeBSD.ORG Subject: Re: guspnp17 and vat/rat In-reply-to: Your message of "Tue, 26 Aug 1997 15:34:00 +0200." <199708261334.PAA00328@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Aug 1997 10:03:50 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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/ > _____________________________|______________________________________