From alsa-devel-owner@alsa.jcu.cz  Sat Jan  9 06:08:56 1999
Received: from executioner.lis.net.au (mail@executioner.lis.net.au [203.35.83.3])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id GAA22751
	for <alsa-devel@alsa.jcu.cz>; Sat, 9 Jan 1999 06:08:42 +0100
Received: from uucp by executioner.lis.net.au with local-rmail (Exim 2.05 #4)
	id 0zyqdW-0003WB-00 (Debian); Sat, 9 Jan 1999 16:08:34 +1100
Received: from kerry by gotss1.gotss.ml.org with local (Exim 1.92 #1)
	id 0zyqcv-0000Ut-00 (Debian); Sat, 9 Jan 1999 16:07:57 +1100
Message-ID: <19990109160757.A1876@gotss.ml.org>
Date: Sat, 9 Jan 1999 16:07:57 +1100
From: Kerry Hoath <kerry@gotss.ml.org>
To: alsa-devel@alsa.jcu.cz, alsa-user@alsa.jcu.cz
Subject: Unable to allocate DMA bounce-buffers for sound
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

I post this question to both lists, because it is both a programming and
user-level problem.

I am running Debian 2.0, Linux 2.0.36 kernel with
Advanced Linux Sound Architecture Driver Version 0.2.0-pre10p2.
I am using a GUSMax soundcard, (ISA) and the same thing happens with any ISA
soundcard. After my machine has been running for awhile, and the memory
pool becomes fragmented, I am unable to record or play sound. The kernel seems
not to be able to get a large enough chunk of Dma-able memory below the 16-meg
limit. My machine has 64-megs of ram so total ram isn't the problem. Running
the swapout tool that comes with the ftape distribution dirtys enough pages
to free up the needed ram about 30% of the time.
I am wondering if there is a way to tell the driver to allocate the DMA ram
it will need when the PCM support id loaded, (I am happy to insmod these 
drivers and don't care about dynamic).
If the driver requires 256k of ram for 2 128-k buffers, (full duplex operation)
I am more than happy to see it get allocated first up, and see the driver hold
on to it. Currently, if I don't mike-up in 2 minutes whilst running
speak-freely, the pcm supports unloads and it is anyone's guess whether 
Alsa can get sufficient memory back for recording. If it fails,  my sfmike
crashes and burns.

In the old days, OSS/free if compiled into the kernel would grab  the DMA
buffers and hold onto them. This meant that sound would allways work. It would
be good if the option existed to allocate the ISA buffers at module load.
Anyone got thoughts on this? I don't mind allocating 1 meg in 64 if necessary,
I personally run text applications because I am totally blind so I don't
exactly have a ram shortage. I'm using a whole 14 megs at the moment.

If my memory serves me correctly the old Ultrasound project drivers grabbed
the memory and held it as well. Those were a great set of drivers. I had 2.99a4
but never saw a 3.0 and don't know how stable the lastest versions of those
drivers were. I'd preferr to use Alsa if possible.

Regards, Kerry.

-- 
--
Kerry Hoath:
kerry@gotss.ml.org or khoath@lis.net.au
ICQ UIN: 8226547


