All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Boullis <nboullis@debian.org>
To: alsa-devel@lists.sourceforge.net
Subject: How to deal with cards with a large on-board buffer?
Date: Wed, 3 May 2006 01:41:25 +0200	[thread overview]
Message-ID: <20060502234125.GC4109@home> (raw)

Hi,

I'm trying to write an ALSA interface for the audio part of MPEG2 
decoder boards Sigma Designs Hollywod+ and Creative Labs DXR3, both 
based on Sigma Designs EM8300 chip.

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?

Browsing at the code, I found out the fifo_size element of the 
snd_pcm_hardware_t type, that is not documented in Takashi Iwai's 
excellent "Writing an ALSA Driver" guide. Is it something that might be 
used to enforce this? (I tried, of course, but my test was 
unsuccessful...)

I also discovered the SNDRV_PCM_INFO_DOUBLE, SNDRV_PCM_INFO_BATCH 
and SNDRV_PCM_INFO_BLOCK_TRANSFER that are give little information, and 
that sound to me like things that might be useful. Any explanation about 
those?


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
   - 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
   - the buffers for DMA transfers are declared in a FIFO; they mustn't 
     be too large (8kB is ok; 16kB is not since it's larger that the 
     on-chip buffer)
   - 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
   - interruptions are not raised when buffers are DMA-transfered, but 
     at fixed 20.2ms interval (stable experimental value)
   - it might be required that DMA buffers are aligned on 4kB boundaried 
     (or page boundaries)

Any idea how to correctly deal with such a beast? I tried a few ones, 
but none was really successful...


Cheers,

Nicolas Boullis


-------------------------------------------------------
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-02 23:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-02 23:41 Nicolas Boullis [this message]
2006-05-03 12:26 ` How to deal with cards with a large on-board buffer? 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

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=20060502234125.GC4109@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.