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.