btw, i wrote some ST sound support about year ago (when my Falcon was
ok). It is very incomplete but allows (on Falcon at least) to play or
record some audio. It may work on ST and TT too. Code is rather ugly,
but if anybody on this list want to write Atari audio driver, it may be
helpful. (mail me)

On Fri, 5 Nov 1999, Leo Weppelman wrote:

> On Fri, Nov 05, 1999 at 03:08:45PM +0100, WITEK Wnuk wrote:
> > On Fri, 5 Nov 1999, Leo Weppelman wrote:
> > 
> > > I have been trying the Ensoniq AudoiPCI ES1370 too, but to no avail :-( I
> > > suspect the Hades PCI-bus here, but I am not entirely sure (wish I had an
> > > analyzer ;-)
> > 
> > Why do you suspect Hades PCI-bus?
> 
> Because it has been wacky before. Things _are_ better now (new PAL's ed.),
> but I am not totally convinced. Given the time I already spend on this bus,
> you should grant me some reserve ;-)
i don't even know what PAL is.. :) (some king of programable logic?? or?)

So if you put eap in the same slot as eso before, with same irq, there are
only few things that can be broken. Or is Hades hardware more random than
i think?

Some register access works. Is it right to assume that all register access
is ok? Do you have any examples, that it is opposite? Driver maps only one
pci I/O register space.

So it may be bus-mastering that is broken. How do you think? (Did you
encounter similar problems?)

Other possibility is that card isn't reseted properly. There is no soft
reset code in eap driver (only codec is reseted). Does Hades have some
problems with PCI reset?

> > Is card detected at all?
> 
> Yes it is.
>   eap0 at pci0 dev 2 function 0: vendor 0x1274 product 0x5000 (rev. 0x01)
>   eap0: interrupting at irq 1
> 
> I have the driver running in debug mode. At the end, the relevant
btw, did you try compiling audio.c with debug? if not, try. it may give
some more interesting information
> snippets from the dmesg output can be found.

Did you press ^C while playing boing.au? Was it long file?
Did I understood you correctly: 'beep' starts once you open/close file and
never stops?

The beep is rather high frequency (like sample rate divided by two or
four), isn't it? It may mean that DMA engine isn't working properly. It
can't fetch data from memory and keeps playing few bytes fifo it has. (I
got similiar effects on i386, if i set card (FM801) to read memory
that didn't exist)

But, if so, why is DMA started?

There is no eap_intr in dmesg output.


> I saw your driver for the ac97 (es1371 right?), and I happend to see your
> mail address ;-))
Not exactly. I wrote only FM801 driver (which uses AC'97). AC'97 support
that *I* wrote never left my home (it was incomplete).

> Well back to the facts. The card is recognized. When I try to play a sample
> (or just open&close I just found out), there starts an irritating beep on
> the right-channel. I _can_ control the volume of this 'beep' with 'audioctl
> -w play.gain=30'. Soo, the card&driver do function a bit.
> All ideas are gladly accepted!
Ok. If you can control frequency with 'audioctl -w play.rate=xxx' too,
then you already have some primitive audio support :))

Now, seriously. Can you control frequency?


i still hope it is bug in driver, and can be fixed easily,
	Witek