Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Boullis <nboullis@debian.org>
To: alsa-devel@lists.sourceforge.net
Subject: Re: How to deal with cards with a large on-board buffer?
Date: Fri, 5 May 2006 01:36:52 +0200	[thread overview]
Message-ID: <20060504233651.GH4831@home> (raw)
In-Reply-To: <20060503122658.GB11243@turing.informatik.uni-halle.de>

On Wed, May 03, 2006 at 02:26:58PM +0200, Clemens Ladisch wrote:
> > 
> > To make it short, the trouble is that, to get correct working, it seems 
> > to require that the audio buffer be kept at some minimal fill level. Is 
> > there a way I can enforce this?
> 
> The card should do this automatically as it initiates the DMA transfers
> by itself.

It does. But then I have problems if the transfered buffer has not been 
filled by the application...


> > Now, just in case someone has a better idea how to make things work, 
> > here is a more comprehensive explanation about how those cards work, *as 
> > far as I could understand* (since I got absolutely no explanation from 
> > the manufacturer):
> >    - there is a rather large on-chip buffer (0x3c00 bytes), that we can 
> >      neither write to or read directly
> 
> So it's just a FIFO that is more or less transparent to the computer?

I guess so.

> >    - we can read pointers to the current read and write positions in 
> >      this buffer
> >    - this buffer is fed by chip-initiated DMA transfers from the main 
> >      memory
> 
> How big are these transfers?

In the current code, they are 4kB (1ksample) or 8kB (2ksample). I can 
specify the size I want, but it does not work with large buffers (8kB is 
already more than half the size of the on-chip buffer). And it seems 
that there are problems when the buffers are not 4kB-aligned.


> >    - the buffers for DMA transfers are declared in a FIFO;
> 
> You mean this chip supports scatter/gather buffers?

I'm not sure what you mean exactly by scatter/gather buffers, but I 
guess it is something like that.


> >    - if the on-chip buffer is "too empty" (don't know exactly when the 
> >      chip decides it is too empty) and no buffer is available for 
> >      DMA transfer, it "sends" some junk to the internal buffer
> 
> Most sound card FIFOs operate like this.

OK, I did not know.


> >    - interruptions are not raised when buffers are DMA-transfered, but 
> >      at fixed 20.2ms interval (stable experimental value)
> 
> The ymfpci and usb drivers deal with a similar problem.

I'll try to give them a look.
But if I understand things correctly, I must ensure that the periods are 
large enough to be played in more than 20.2ms, if I want 
snd_pcm_period_elapsed to be called often enough. Is that right?


Cheers,

Nicolas

PS: sorry if I'm being stupid, I'm not used to writing audio drivers...


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

      reply	other threads:[~2006-05-04 23:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-02 23:41 How to deal with cards with a large on-board buffer? Nicolas Boullis
2006-05-03 12:26 ` Takashi Iwai
2006-05-04  1:18   ` Nicolas Boullis
2006-05-04 14:49     ` Takashi Iwai
2006-05-04 23:56       ` Nicolas Boullis
2006-05-05 12:05         ` Takashi Iwai
2006-05-03 12:26 ` Clemens Ladisch
2006-05-04 23:36   ` Nicolas Boullis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060504233651.GH4831@home \
    --to=nboullis@debian.org \
    --cc=alsa-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox