Subject: RE: Assabet UDA1341/DMA patch

From: Jamey Hicks <[email-masked]>
Date: Fri, 23 Jun 2000 11:06:05 -0400

What is the status of this driver?  Does anyone have it working without
periodic artifacts in the sound?

I sent Nico a patch that makes this work on the iPaq 3600 handheld (Bitsy).

-Jamey

> -----Original Message-----
> From: Tak-Shing Chan [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2000 4:19 AM
> To: Tak-Shing Chan
> Cc: Nicolas Pitre; [email-masked]
> Subject: Re: Assabet UDA1341/DMA patch
> 
> 
> Hi Nicolas,
> 
>      AUDIO_DMA_OVERSHOOT=2 and AUDIO_FRAGSIZE_DEFAULT=8190 works
> fine.  Another observation: odd fragsizes break things (the last
> 16-bit sample became 8-bit).  It looks like DMA overshoot is not
> a problem at all because 8190 is the biggest possible even number.
> Maybe renaming AUDIO_DMA_OVERSHOOT to AUDIO_EVEN_HACK is a better
> idea.  ;)
> 
>      Results so far:
>      * Odd fragsizes with tca=size-1 : failed
>      * Even fragsizes with tca=size-1: failed
>      * Odd fragsizes with tca=size   : failed
>      * Even fragsizes with tca=size  : passed
>      * Valid fragsize range          : 4096-8190
> 
> Tak-Shing Chan
> 
> On Tue, 20 Jun 2000, Tak-Shing Chan wrote:
> 
> > Nicolas,
> > 
> >      I think that involves two things.  First, regarding the
> > meaning of DBTA--from repeated listening experiments (from 4096
> > to 8176) I'm positive that it's value and not value-1.  The
> > result of missing samples in digital recordings are just too
> > obvious...  [by the way 11.6.1.4 says TCA is in bytes.]
> > 
> >      Second, isn't the extra datum you detected caused by DMA
> > overshoot (and the value is supposed to be fetched and ignored)?
> > My patch explicitly takes DMA overshoot into account.
> > 
> >      It seems like it's safe to specify AUDIO_DMA_OVERSHOOT as 16
> > and AUDIO_FRAGSIZE_DEFAULT as 8176.  Any confirmations?  IMHO
> > 8176 is big enough for most purposes.  Meanwhile 64 and 4096 are
> > ``failsafe'' values but not optimal.
> > 
> > Tak-Shing Chan
> > 
> > On Mon, 19 Jun 2000, Nicolas Pitre wrote:
> > 
> >> However you're limitting the DMA buffer to 4096 bytes 
> which might be quite
> >> small, especially if the system is under heavy load.
> >>
> >> The SA1100 manual explictly says that the DMA count 
> register is 13 bit
> >> wide for a maximal DMA size of 8192 bytes, which is highly 
> adviseable for
> >> audio.  However 13 bits can represent a max value of 
> 0x1fff i.e. 8191.
> >> Since most registers on the SA1100 are defined as reg = 
> value - 1, I
> >> though it was the case for the DMA too, although it is not strictly
> >> mentionned for the DMA count reg.  What I've noticed 
> though is that even
> >> if you specify 0 for the DMA count reg, you'll get at 
> least one datum
> >> through the DMA engine which tend to confirm the -1 guess.
> >>
> >> Anybody can confirm this?
> >>
> >>
> >> Nicolas
> >>
> > 
> > 
> > 
> > unsubscribe: body of `unsubscribe linux-arm-kernel' to 
> [email-masked]
> > 
> 
> 
> 
> unsubscribe: body of `unsubscribe linux-arm-kernel' to 
> [email-masked]
> 

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Tak-Shing Chan <[email-masked]>
Date: Sat, 24 Jun 2000 10:48:16 +0800 (CST)

Jamey,

     Yes it's already working without any artifacts.  I suppose
Nico will integrate the changes in the next release.

Tak-Shing Chan

---

From: Nicolas Pitre <[email-masked]>
Date: Sun, 25 Jun 2000 20:04:35 -0400 (EDT)

> periodic artifacts in the sound?

I adjusted the DMA buffer length to 4096 since the maximum DMA length
seems to be 8191 rather than 8192.

Nicolas