From alsa-devel-owner@alsa.jcu.cz  Fri Mar 12 19:07:55 1999
Received: from a1fw01.mobilkom.at (firew21.mobilkom.at [193.154.243.18])
	by marvin.jcu.cz (8.9.1a/8.9.1) with SMTP id TAA31077
	for <alsa-devel@alsa.jcu.cz>; Fri, 12 Mar 1999 19:06:03 +0100
From: T.Mertes@mobilkom.at
Received: by a1fw01.mobilkom.at; (5.65v3.2/) id AA03624; Fri, 12 Mar 1999 19:06:00 +0100
Message-Id: <48A7CB4095A7D11187EF00609748374C02F161B2@w1sxms01.mobilkom.at>
To: arloafoe@cs.vu.nl
Cc: alsa-devel@alsa.jcu.cz
Subject: RE: Enlarging the dma buffer for audiopci (fwd)
Date: Fri, 12 Mar 1999 19:10:30 +0100
Mime-Version: 1.0
Content-Type: text/plain
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list



	Andy Lo A Foe wrote: 

	> Maybe, but not practical. Many programs can do flawless playback
with very
	> small DMA buffers even. The trick is to do smart buffering and/or
set the
	> program/thread that's feeding the audio card at a higher priority
(RT) to
	> prevent underruns (skipping). 

	I think you missunderstand something. The problem is:
	When the sound playing program is waiting for the read() system
	call the sound driver runs out of data. This is not because of a
	sound driver problem or a problem of the sound playing program
	or its priority.

	You can have the best driver with the smartes buffering and the
	trickiest sound playing program under the highest RT priority.
	If the sound playing program has to wait for a disk read() this
	does not help at all. The sound playing program waits for (for
	example) two seconds for the read() system call to complete.
	Very high disk load can make this happen. Have you ever tried

	  find / -name "*core*"

	while playing a wave sound file. Of course your dentry cache
	must be clean to put real load on the disk. Have you compiled
	your new kernel while playing sound. Or do both (from X11 of
	course) while doing also Netscape/Xemacs and other DISK and
	CPU load on the system. If you still have no dropouts please say
	to me which soundcard, driver, and wave file playing software
	you use.

	You wrote also

	> It could be difficult to allocate large amounts of contigeous
buffers in
	> the lower 16MB memory range.

	I think with PCI DMA you don't have this limitation. You missed
	this point also.

	Greetings Thomas


