All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Courtier-Dutton <James@superbug.co.uk>
To: Nicolas Boullis <nboullis@debian.org>
Cc: alsa-devel@lists.sourceforge.net
Subject: Re: writing an alsa driver for an MPEG decoder chip
Date: Sun, 28 Aug 2005 23:51:49 +0100	[thread overview]
Message-ID: <43124005.4030709@superbug.co.uk> (raw)
In-Reply-To: <20050828223555.GA16031@home>

Nicolas Boullis wrote:
> Hi,
> 
> On Sun, Aug 28, 2005 at 10:59:49PM +0100, James Courtier-Dutton wrote:
> 
>>I looked at the code. The period and buffer size selection looks a bit 
>>wrong. Can you explain to me what the actual buffer contraints are for 
>>the em8300 card? It looks to me that the only current contraint is 
>>number of periods. This seems to me to be rather a strange contrain to have.
> 
> 
> First of all, thanks for your answer.
> Unfortunately, I have to admit that I'm not sure I have undestood what 
> periods really are.
> 
> The em8300 chip uses a small on-chip circular buffer (whose size is 
> given by the read_ucregister(MA_PCISize) call) as a FIFO. This FIFO is 
> fed with structs that contain both a pointer to some sound data in main 
> memory and size of this buffer. The structs have a size of 3, which 
> means the cicrular buffer has a size of read_ucregister(MA_PCISize)/3 
> elements.
> 
> A fifo engine takes all elements in the fifo in order. For each element, 
> the DMA engine gets the sound data from main memory, and the sound is 
> played. Sometimes, the chip raises an interruption when the DMA engine 
> as finished reading a buffer. (That's generally once every two buffers, 
> but it happens that 2 consecutive buffers both lead to an interruption. 
> I never understood how that works...)
> 
> Hence, I thought I should set up read_ucregister(MA_PCISize)/3 static 
> buffers of random (well, <65536 bytes) size, and let each buffer 
> correspond to 1 period.
> 
> Do you think this is broken and this could explain why most applications 
> fail to get any sound, while xmms succeeds?
> 
> 
> Thanks for your help,
> 
> Nicolas Boullis
> 

Your FIFO looks to me to be a scatter gather array with each entry 
pointing to a buffer in memory.
You say that it is circular, which sort of contradicts the FIFO name for 
it, so which is it, A FIFO or a circular buffer?

ALSA has the following terms, periods and frames.
A frame equivalent to having one sample for every channel. E.g. stereo 
16bit PCM would have a frame size of 4 bytes, but a 5.1 16bit PCM would 
have a frame size of 12 bytes.

A period is the time between interrupts for the sound card, and this 
normally is closely linked to a fixed number of frames per period.

Now, I will explain what periods are.
One period in alsa is the amount of sound samples

A buffer is simply the total of period_size * periods.

How is the 3 byte FIFO struction layed out? 2 bytes offset, 1 byte size?

James


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

  reply	other threads:[~2005-08-28 22:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-28 14:46 writing an alsa driver for an MPEG decoder chip Nicolas Boullis
2005-08-28 21:59 ` James Courtier-Dutton
2005-08-28 22:35   ` Nicolas Boullis
2005-08-28 22:51     ` James Courtier-Dutton [this message]
2005-08-28 23:36       ` Nicolas Boullis
2005-08-29  0:04         ` James Courtier-Dutton
2005-08-29 17:45           ` 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=43124005.4030709@superbug.co.uk \
    --to=james@superbug.co.uk \
    --cc=alsa-devel@lists.sourceforge.net \
    --cc=nboullis@debian.org \
    /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.