sound driver on mpc823

sound driver on mpc823

[Kyle Harris]

Hi,

I'm working on a sound driver for the LM4548 (ac97 codec). I've taken
Dan Malek's cs4218_tdm driver and ported it to 2.4 kernel for a starting
point. I have a couple questions I hope someone can help me with.

The CPM reports underrun errors. The driver does not set the LAST bit
for any buffer descriptors and setting this bit prevents this error. But
only for a few bytes. If I set the data length to be greater than 16
bytes I still get underrun errors. The bit_clk (L1TCLK) is 12.288 MHz
and sync (L1RSYNC) is 48 kHz.

1) Why is the LAST bit never set? It seems this causes the application
to block waiting for completion. Which I guess is OK if the application
continues to send data to the driver. But is this desirable? How is the
device closed in this case?

2) Why do underrun errors occur even when the LAST bit is set? Is the
CPM unable to keep up at this data rate? Is this significant, or does
the driver/codec recover?

Thanks, Kyle.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: sound driver on mpc823

[Dan Malek]

Kyle Harris wrote:

> The CPM reports underrun errors. The driver does not set the LAST bit
> for any buffer descriptors and setting this bit prevents this error.

Setting the LAST indicator doesn't "prevent" the error, it just
causes the CPM to stop at this point until you can fill more buffers.
This is not the desirable effect for audio codecs, or anything else
that requires a continuous stream of data.

> ........ If I set the data length to be greater than 16
> bytes I still get underrun errors.

Just 16 bytes?  Hell, those are gone almost as quickly as you
tell the CPM the buffer is available.  You better be using huge
buffers, or lots of them.  The CS4218 driver uses 32K buffers.
You shouldn't be writing small buffers to audio codecs, the management
overhead is significant.

> 1) Why is the LAST bit never set?

For lots of reasons.  Primarily, it causes the CPM to send a continuous
stream of data from the buffers.  When you set the LAST indicator, it
will stop and transmit idles (or some other bit pattern you may program),
before it opens the next buffer and resynchronizes with the TDM.  You
clearly don't want this in an audio stream.  I also want to know when
an underrun occurs, so I can clean up the audio channel.

> ......... Which I guess is OK if the application
> continues to send data to the driver. But is this desirable? How is the
> device closed in this case?

The application must continue to send data.  If it doesn't, the CPM
will indicate an underrun condition, you will have to send the
communication channel (an SCC or SMC) a restart command, and then it
starts to poll the next BD in the ring for more data.

In the case of an audio codec, if the application can't keep up, does
it matter what you do?  With the current driver design, you give the
application the maximum amount of time to provide the data, and if it
doesn't the channel is cleanly shut down and restarted.  By using the
LAST indicator, you can get trash in the audio stream between every
buffer descriptor (and you usually will with SMC resync to the TDM).

> 2) Why do underrun errors occur even when the LAST bit is set?

There may be some race condition due to the small buffers you are
using.  It really shouldn't (but you shouldn't be using LAST in
this application anyway).

> .... Is the
> CPM unable to keep up at this data rate?

The CPM can easily keep up.  The problem is your software can't
keep buffers available for the CPM.

> ..... Is this significant, or does
> the driver/codec recover?

It would be significant for me, since I only want bits I send from
an application reaching the codec.  When I stop sending or close
the device, I want it shut down properly.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: sound driver on mpc823

[Kyle Harris]

Dan,

Dan Malek wrote:
>
> Kyle Harris wrote:
>
> > The CPM reports underrun errors. The driver does not set the LAST bit
> > for any buffer descriptors and setting this bit prevents this error.
>
> Setting the LAST indicator doesn't "prevent" the error, it just
> causes the CPM to stop at this point until you can fill more buffers.
> This is not the desirable effect for audio codecs, or anything else
> that requires a continuous stream of data.
>
> > ........ If I set the data length to be greater than 16
> > bytes I still get underrun errors.
>
> Just 16 bytes?  Hell, those are gone almost as quickly as you
> tell the CPM the buffer is available.  You better be using huge
> buffers, or lots of them.  The CS4218 driver uses 32K buffers.
> You shouldn't be writing small buffers to audio codecs, the management
> overhead is significant.

At this point I'm just trying to verify the data that is sent to the
codec. So, for debug purposes I'm sending a small number of bytes. I
understand your comments concerning streaming data. But I still don't
understand why underrun errors occur when the end of data is indicated.
I guess I won't worry about that for now.

I'm struggling to define the RAM entries and buffer descriptors such
that data is formatted correctly for the ac97 (one 16 bit slot followed
by 12 20 bit slots (of which only 4 slots are valid)). It seems I should
be able to define RAM for 1 16bit slot followed by 8 10bit slots. But
I'm not sure exactly how the CPM correlates the RAM entries to buffer
descriptors (e.g., does it advance buffer descriptors when the RAM entry
changes). Various experiments so far with the RAM and BDs don't make
much sense. Any advice is appreciated.

Thanks, Kyle.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: sound driver on mpc823

[Dan Malek]

Kyle Harris wrote:

> ....But
> I'm not sure exactly how the CPM correlates the RAM entries to buffer
> descriptors (e.g., does it advance buffer descriptors when the RAM entry
> changes).

They don't relate.  The TDM is an autonomous bit mux that moves
bits between the TDM I/O and the communication channels.  The TDM
RAM indicates where the bits are in the TDM I/O stream, how many
there are, and to which communication channel they are connected.
For example, you can tell the TDM there are three bits in every
major frame at offset 19 that belong to SMC2, and tell the SMC2 to
communicate with 8-bit data.  The TDM will pack three bits at a time
to the SMC, and when the SMC gets its eight bits it will do whatever
protocol is appropriate in the SMC and move the data to the buffer.
Any remaining bits between the TDM and the SMC are then used to start
the next 8-bits to the SMC.

The often more confusing part (but it really isn't :-), and very
necessary part is how the communication channel synchronizes to the
TDM frame.  Although it looks like there is lots to read in the
CPM and communication sections of the manual, the words are actually
quite few and very critical to understand.  There is a ton of
information in that manual that you have to understand, and don't
skip one word :-).

I have a telecom/telemetry background, so I guess I can apply that
application experience and make some sense out of the CPM/TDM a
little more easily :-).

Good Luck.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/