wiz@NetBSD.org (Thomas Klausner) writes:
> On Fri, Dec 19, 2003 at 11:31:49AM -0800, Wolfgang S. Rupprecht wrote:
> I'm not streaming over the web, but I mostly read the mplayer
> data from

Just to be really clear, I'm not really streaming from the web either.
I'm running audiorecord(1) on a old, otherwise useless computer in the
living room and playing it with audioplay(1) on the computer in the
office.

playing (local computer): 
   audioplay -f -c 2 -e slinear_le -s 44100 -P 16 /portalfs/tcp/cayenne/6060

recording (remote computer), via /etc/inetd.conf:
   /usr/bin/audiorecord -c 2 -e slinear_le -P 16 -s 44100 -F wav -p line -

>> My guess was that it was related to underflows.  An underflow would
>> trigger it and then the sound would stutter for a long time after
>> that.  It is highly likely that when I stream the audio from one card
>> to the other that the two cards are clocking at a slightly different
>> speed.  If the recording card is clocking a very small amount slower,
>> I'll eventually run out of samples to play.
>
> Hm, not sure about that, but the hard disk, CPU and video card are
> definitely up to the task.

I see it within *seconds* of doing across the net xfers (usually
within 30 seconds to 45 seconds).  I'm sure my 100base-tx is up to
44.1k 16-bit 2-channel audio too. ;-)

I have never had it happen when playing mp3's via gqmpeg and/or mpg123
directly.  It will eventually happen under mplayer and gmplayer, but
takes 10-15 minutes to happen.  Something about the back-to-back 
"audiorecord | audioplay" really excites the bug.

-wolfgang
-- 
Wolfgang S. Rupprecht 		     http://www.wsrcc.com/wolfgang/
       The above "From:" address is valid.  Don't mess with it.