From alsa-devel-owner@alsa.jcu.cz  Thu Dec 17 18:17:13 1998
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id SAA19091
	for <alsa-devel@alsa.jcu.cz>; Thu, 17 Dec 1998 18:15:19 +0100
Received: from cineca.it (pc-venturi.cineca.it [193.204.122.21])
	by bologna.nettuno.it (8.8.6/8.8.6/NETTuno 3.1) with ESMTP id RAA12018
	for <alsa-devel@alsa.jcu.cz>; Thu, 17 Dec 1998 17:29:58 +0100 (MET)
Message-ID: <36793FFC.FDAFCD4D@cineca.it>
Date: Thu, 17 Dec 1998 18:31:40 +0100
From: Andrea Venturi <venturi@cineca.it>
MIME-Version: 1.0
To: Alsa Development <alsa-devel@alsa.jcu.cz>
Subject: i'm a bit confused about PCI DMA versus Bus-Master..
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

in brief.. i'm looking for a first implementation of a PCM/Mixer driver
for my ess maestro ii card and i'm trying to understand the other pci
cards alsa driver (like sonicvibes ..)

i believe that this driver is programming a _real_DMA_ to feed the Codec
for playback.. (like in a ISA card..)

in a sample implementation of a dos C program for the maestro II chip,
instead, i found the Bus-Master way to let the chip control the bus and
go to read the memory directly.. (so i understand ;-)

i believe that this is a better way to use a pci card.. (there is also
the sound blaster compatible way to feed the codec using a real DMA,
but, i believe only for compatibility reason..)

could someone comment on this?

another source of questions is the actual way to create the interrupt
and fill the DMA buffer.

In the "real DMA" case, i believe,  the interrupt comes at the _end_ of
the DMA transfer.

Instead, in the C source that i can browse, there is an autonomous timer
(named BOB timer), that is programmed before the bus master transfer
start, and raise an interrupt asynchronously (obviously before the
playback come to the end of the buffer).

The interrupt service routine read from the chip the actual position of
the playback in the buffer and set a global variable to this value, then
the program loop fills the already consumed part of the buffer with new
data from the "wav" file..

is this a clean way to  use the interrupt and feed the buffer for
playback?

ciao

andrea


-- 
andrea venturi - cineca - area csd
venturi@cineca.it - +39 0516171536

--
My point?   (Geez, I had one here somewhere, let me ask my wife...)

