[Top] [All Lists]

[PATCH?] MACE Audio ALSA driver

Subject: [PATCH?] MACE Audio ALSA driver
From: TJ <>
Date: Mon, 12 Mar 2007 15:26:05 +0000
Dkim-signature: a=rsa-sha1; c=relaxed/relaxed;; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=jkqZK+nPmm/tWfLMzXR+kmM3DQtM8/gW2q6WfgBdkRUzHlmrN4t/aCEPvVufn798qgUlltxLAUBKilV5dN/ucpsY3rTmrMKMVyXtvm0NrYnc9MqXwW+LFbm5UpEVEIN2lzUYz2+ySML8jYJHmgRtcIBNB5VN15RjNV52CCdXuAo=
Domainkey-signature: a=rsa-sha1; c=nofws;; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=SYpcVHh9tmeFXae8lktjTDqrfDXZcBbhHeNFHvC2pjphzO0m8mbkLBJ2nTYPO2ChRjEbob8NZaEkS42HX7aMypEXcP3MsKJ8dEjNNNyF7qOEC22bYliGheiRc5fEs+344BZoeBJfIUqCExg3znwyb9R/xbvdMy24BQ7QD/RJiWM=
Original-recipient: rfc822;

I have been working on an audio driver for the SGI O2.
It is more complete then the sgio2audio driver that is about, but PCM still
doesn't work for other reasons.

Namely the DMA feed doesn't seem to run correctly, see output below.

#comments start with # and generally come after the line they refer to

allocated ring base. CPU addr=0x9000000004620000, Bus addr=0x44620000
#Note the bus/phys address that dma_alloc_coherent gave us.

sizeof void*=8, unsigned long=8, int=4, u32=4, u32*=8, u64=8, u64*=8
in playback open
In hw param for channel 1
In pcm prepare for channel 1
in playback for channel 1, rate 44100, sub-channels 2
In pcm trigger
In DMA start for channel 1
#about to start DMA, but before we do start, lets do a push first

In DMA push for 1
ring base 0x9000000004620000, dst_base 0x9000000004621000, dst_pos 0x0, dst

4096 remain, 0 used
reduced remain to 3968
starting push loop. ringbase=0x44620010,
       0[ writep=0x0 (0), readp=0x0 (0), depth=0x0 (0) ]
       1[ writep=0x0 (0), readp=0x0 (0), depth=0x0 (0) ]
       2[ writep=0x0 (0), readp=0x0 (0), depth=0x0 (0) ]
#this is a printout that I have dotted around to the code to watch the
# pointers in mace, these numbers are freshly read in.
#Note the change in the ringbase address! It always seems to get incremented
# by 0x10, why?

#looping here

after push loop, 0 remain, 3968 used, dst pos 3968
Finished push loop. ringbase=0x44620010,
       0[ writep=0x0 (0), readp=0x0 (0), depth=0x0 (0) ]
       1[ writep=0xF80 (3968), readp=0x0 (0), depth=0xF80 (3968) ]
       2[ writep=0x0 (0), readp=0x0 (0), depth=0x0 (0) ]
#bar ringbase, this is what we would expect

DMA started. ringbase=0x44620010,
       0[ writep=0x0 (0), readp=0x0 (0), depth=0x0 (0) ]
       1[ writep=0xF80 (3968), readp=0x40 (64), depth=0xF40 (3904) ]
       2[ writep=0x0 (0), readp=0x0 (0), depth=0x0 (0) ]
#DMA enabled, and the read pointer has moved on

In pcm pointer. ringbase=0x44620010,
       0[ writep=0x0 (0), readp=0x0 (0), depth=0x0 (0) ]
       1[ writep=0xF80 (3968), readp=0x40 (64), depth=0xF40 (3904) ]
       2[ writep=0x0 (0), readp=0x0 (0), depth=0x0 (0) ]

#This is inside one of the ALSA callbacks some time later.
#Note the read pointer has not moved any further, its always sticks at
#0x40?! Even if push code didn't put the correct data in the correct place
#as far as mace is concerned there is still a depth of 0xF40, so why has it

Currently I think it has something to do with the ad1843. I have tried to
butter interpret the specs file to improve ad1843_init() and
ad1843_setup_dac(). (Note sgio2audio will need a few changes to work 'as
was', with my ad1843.c, main change is I made channel/dac/adc index/id
consistent, ie 0=adc,1=dac1,2=dac2 see ad1843_setup_dac())

I do most of this from a remote location to the O2 at the moment (the driver
has been stable enough to allow be to remotely reboot after a test) so I
have not worked on the kinks in the mixer code (and vol buttons) other then
they run ok with out errors. (and of course if I ever get dma going I would
not be able to hear it, although my girlfriend my get a nasty/noisy shock)

It is my plan to get ALSA to write/dma directly into the 4k channel buffer
(I know what needs to be done to get alsa to do this, assuming that the way
alsa stores s24_be in 32bits is agreeable to mace) thus removing the dma
push func. But for now (while testing) I'll keep the psudo dma setup.

Any thoughts, help, major coding mistakes by my self?



I would like to thanks all those that have already helped me with this in
the IRC channel.

Attachment: mace_audio.diff
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>
  • [PATCH?] MACE Audio ALSA driver, TJ <=