Re: writing an alsa driver for an MPEG decoder chip

[Nicolas Boullis <nboullis@debian.org>]

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


-------------------------------------------------------
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