writing an alsa driver for an MPEG decoder chip

writing an alsa driver for an MPEG decoder chip

[Nicolas Boullis]

Hi,

I am a member of the dxr3 project, that tries to write a linux driver 
for the MPEG decoder em8300 chip that is mainly used in Sigma Design's 
Hollywood+ and Creative Labs DXR3 boards.
This chip handles hardware decoding of MPEG video, but is also able do 
perform some limited audio playback.
We corrently have a working OSS interface for the audio playbak, that 
I'd like to replace with an ALSA one.
I tried to write one, using Takashi Iwai's excellent "Writing an ALSA 
Driver" guide. Unfortunately, the driver that I managed to write seems 
to work fine when playing sound with xmms, but all other apps that I 
tried failed to get any sound.

Anyone can help me figure out whet I missed?
You can grab the relevant file at
http://dxr3.sourceforge.net/download/em8300_alsa.c

Thanks in advance,

Nicolas Boullis


PS: I am not subscribed to this list, please CC replies to me.


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

Re: writing an alsa driver for an MPEG decoder chip

[James Courtier-Dutton]

Nicolas Boullis wrote:
> Hi,
> 
> I am a member of the dxr3 project, that tries to write a linux driver 
> for the MPEG decoder em8300 chip that is mainly used in Sigma Design's 
> Hollywood+ and Creative Labs DXR3 boards.
> This chip handles hardware decoding of MPEG video, but is also able do 
> perform some limited audio playback.
> We corrently have a working OSS interface for the audio playbak, that 
> I'd like to replace with an ALSA one.
> I tried to write one, using Takashi Iwai's excellent "Writing an ALSA 
> Driver" guide. Unfortunately, the driver that I managed to write seems 
> to work fine when playing sound with xmms, but all other apps that I 
> tried failed to get any sound.
> 
> Anyone can help me figure out whet I missed?
> You can grab the relevant file at
> http://dxr3.sourceforge.net/download/em8300_alsa.c
> 
> Thanks in advance,
> 
> Nicolas Boullis
> 
> 
> PS: I am not subscribed to this list, please CC replies to me.
> 

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.

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

Re: writing an alsa driver for an MPEG decoder chip

[Nicolas Boullis]

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

Re: writing an alsa driver for an MPEG decoder chip

[James Courtier-Dutton]

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

Re: writing an alsa driver for an MPEG decoder chip

[Nicolas Boullis]

After sending my previous message, I figured out that with a smaller 
period_bytes_max, I can play some sound with xine. It looks like you got 
a point. Thanks! :-)

Anyway, explanations and suggestions for improvement are still very 
welcome... ;-)

On Sun, Aug 28, 2005 at 11:51:49PM +0100, James Courtier-Dutton wrote:
> 
> Your FIFO looks to me to be a scatter gather array with each entry 
> pointing to a buffer in memory.

You're perfectly right. Is there a better way to handle scatter-gather 
arrays within the ALSA framework?


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

It is a FIFO implemented in a circular buffer: there is this circular 
buffer and two pointers that point to the head and tail of the FIFO 
within this buffer (look for MA_PCIRdPtr and MA_PCIWrPtr in my code).


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

And the em8300 chip only handles 2-channel 16-bit big-endian streams, 
which means 4 bytes per sample.


> 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

between 2 interrupts?


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

Almost: these are 2-byte words rather than bytes. Hence, there is:
   - 1 2-byte word for the upper 16 bits of physical address to data 
     block
   - 1 2-byte word for the lower 16 bits of physical address to data 
     block
   - 1 2-byte word for the size (in bytes) of the data block


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

Re: writing an alsa driver for an MPEG decoder chip

[James Courtier-Dutton]

Nicolas Boullis wrote:
> After sending my previous message, I figured out that with a smaller 
> period_bytes_max, I can play some sound with xine. It looks like you got 
> a point. Thanks! :-)
> 
> Anyway, explanations and suggestions for improvement are still very 
> welcome... ;-)

Well, get it working first, then improve it. For example, all the 
"magic" stuff is unneeded now.

> 
> On Sun, Aug 28, 2005 at 11:51:49PM +0100, James Courtier-Dutton wrote:
> 
>>Your FIFO looks to me to be a scatter gather array with each entry 
>>pointing to a buffer in memory.
> 
> 
> You're perfectly right. Is there a better way to handle scatter-gather 
> arrays within the ALSA framework?

The Linux kernel has it's own scatter gather framework, but I can't 
remember off hand how best to use it.

> 
> 
> 
>>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?
> 
> 
> It is a FIFO implemented in a circular buffer: there is this circular 
> buffer and two pointers that point to the head and tail of the FIFO 
> within this buffer (look for MA_PCIRdPtr and MA_PCIWrPtr in my code).
>

Is the number of entries in the scatter-gather list a fixed size? If so, 
how big is it? If the number of entries in the scatter-gather list can 
be varied each time you open the device, then set the "periods_min/max 
to the range of values it can take. Most sound cards generally do 
between 2 and 8 periods.

> 
> 
>>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.
> 
> 
> And the em8300 chip only handles 2-channel 16-bit big-endian streams, 
> which means 4 bytes per sample.
> 
> 
> 
>>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
> 
> 
> between 2 interrupts?

Yes.

> 
> 
> 
>>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?
> 
> 
> Almost: these are 2-byte words rather than bytes. Hence, there is:
>    - 1 2-byte word for the upper 16 bits of physical address to data 
>      block
>    - 1 2-byte word for the lower 16 bits of physical address to data 
>      block
>    - 1 2-byte word for the size (in bytes) of the data block
> 

You would generally pre allocate all the DMA memory use for sound in the
snd_em8300_create() function.

One would then fill the scatter-gather list with pointers to the DMA 
memory in the snd_em8300_pcm_prepare() function.

One would also try to do the fewest number of read/write to IO memory in 
the em8300_alsa_audio_interrupt() function. I.e. remove the 
read_ucregister(MA_PCISize) calls etc, and cache their values in the 
em8300_alsa_t structure.
You might want to write to the MA_PCISize register if you want the 
application to be able to select a different number of periods. It would 
be set in the prepare() function.


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

Re: writing an alsa driver for an MPEG decoder chip

[Nicolas Boullis]

On Mon, Aug 29, 2005 at 01:04:18AM +0100, James Courtier-Dutton wrote:
> >Anyway, explanations and suggestions for improvement are still very 
> >welcome... ;-)
> 
> Well, get it working first, then improve it.

And as it now seems to be working, it's now time for improvements... ;-)

> For example, all the "magic" stuff is unneeded now.

I kept this stuff because I thought it was useful for compatibility with 
older alsa, but it seems I was mistaken. Thanks for pointing this, I 
will replace the magic stuff with the non-magic one... ;-)


> The Linux kernel has it's own scatter gather framework, but I can't 
> remember off hand how best to use it.

OK. But do you think it is worth spending some time. Isn't it fine the 
way I do it?


> Is the number of entries in the scatter-gather list a fixed size? If so, 
> how big is it? If the number of entries in the scatter-gather list can 
> be varied each time you open the device, then set the "periods_min/max 
> to the range of values it can take. Most sound cards generally do 
> between 2 and 8 periods.

The number of entries in the scatter-gather list is computed by dividing 
the size of the list (MA_PCISize) by the size of an entry. I used to 
think that MA_PCISize was read-only, which leads to a fixed-size list. 
But it certainly is worth trying to write it and see if it works fine... 
;-)

(With the firware I am using, there are 32 elements in the list.)


> You would generally pre allocate all the DMA memory use for sound in the
> snd_em8300_create() function.

I do call snd_pcm_lib_preallocate_pages_for_all in snd_em8300_pcm(). 
Should I move the call to snd_em8300_create()?


> One would then fill the scatter-gather list with pointers to the DMA
> memory in the snd_em8300_pcm_prepare() function.

That's already what I do... ;-)


> One would also try to do the fewest number of read/write to IO memory in 
> the em8300_alsa_audio_interrupt() function. I.e. remove the 
> read_ucregister(MA_PCISize) calls etc, and cache their values in the 
> em8300_alsa_t structure.
> You might want to write to the MA_PCISize register if you want the 
> application to be able to select a different number of periods. It would 
> be set in the prepare() function.

Or I guess I might use the number of periods instead of re-computing 
it... ;-)


Thanks for your help,

Nicolas


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