Andy:
Hmm, we'll probably also see this once we implement our intercom messaging
functionality.
Without looking at the code, my best guess would be the either "prime rx"
section of code or the idle spin.
Did it at least fix the write stall?
DAVID A. KONDRAD
Software Design Engineer
On-Q/Legrand
www.onqlegrand.com
Andy Ngo
<[EMAIL PROTECTED]
ahoo.com> To
avid A Kondrad
01/14/2008 11:23 <[EMAIL PROTECTED]>,
PM [EMAIL PROTECTED]
incidsp.com
cc
Subject
Re: OSS audio driver under-run
breakthrough
I tried your changes; unfortunately, I'm still getting stall problems on
the read side (we're doing simultaneously reads and writes to the audio
device). Oh well, I'll stick to the self-recovering logic (unstalling the
lockup and re-opening the audio device) we have in place in our code.
Regards,
Andy
----- Original Message ----
From: Andy Ngo <[EMAIL PROTECTED]>
To: David A Kondrad <[EMAIL PROTECTED]>;
[email protected]
Sent: Monday, January 14, 2008 6:51:34 PM
Subject: Re: OSS audio driver under-run breakthrough
Wow, thanks. I gotta try this out!
Regards,
Andy
----- Original Message ----
From: David A Kondrad <[EMAIL PROTECTED]>
To: [email protected]
Sent: Monday, January 14, 2008 1:21:39 PM
Subject: OSS audio driver under-run breakthrough
Greetings,
I've seen quite a few posts regarding lockups with the audio driver,
especially on under-run conditions and closing (also related to under-run).
Most people were tracking it down to DMA register errors and such, but I
believe those were symptoms of a larger problem.
We have a system that plays intercom announce tones (for talking,
hands-free, etc) as well as door chimes.
Our approach was to open the sound device at the beginning of the program
and start a thread that processed sound requests and
pumped the data out to /dev/dsp. This all sounds resonable, except that the
audio output thread would lock up inside write after a few sound requests.
As a note, we're currently using the supported montavista 2.6.10 with all
current MV patches applied, but I found the exact same code inside the
2.6.23 kernel.
Turning on kernel debugging and dumping the audio driver dma context
information we noticed a few very strange things related to the lockup:
1. We were occasionally getting "Called again while In Use" kmsg's from
audio_process_dma (davinci-audio-dma-intfc.c)
The only way this could happen is if the ISR tried to get inside that
function while the DSR was working on it.
2. When audio would freeze we would see that the dma queue was always full.
This led me to believe that someone wasn't waking up the next DMA
transfer in line.
Problem 1:
----------
After many iterations of adding more debug messages and playing a sound
file with different write sizes and thread sleep times,
I found the culprit to be the code inside the following if statement:
File : davinci-audio-dma-intfc.c:
Func: sound_dma_irq_handler
All the comments in the file point toward using delayed-service-routine
tasklets to process any queue requests, which this code violates by
processing it in the ISR instead of firing off the DSR.
That code doesn't belong there and in fact messes up the audio driver
state.
Solution:
---------
Surround the entire if statement with:
#if 0
if(AUDIO_QUEUE_LAST(s)) {
// Code omitted (processes a queue request then returns)
}
#endif
Problem 2:
----------
File: davinci-audio-dma-intfc.c
Func: audio_dsr_handler
// snip
if(AUDIO_QUEUE_EMPTY(s)) {
// snip
AUDIO_INCREMENT_HEAD(s); /* Empty the queue */
// snip
}
The severe issue here is that the queue is already empty (s->dma_q_count ==
0) and AUDIO_INCREMENT_HEAD(s) has the side effect of decrementing
dma_q_count.
Solution:
---------
The fix is to comment out AUDIO_INCREMENT_HEAD(s) inside that if-statement
to ensure that the dma_q_count does not drop below 0.
Problem 3:
----------
If the AIC33 driver is configured as AIC33_MASTER, the audio sounds like it
is being played at 1/2 sampling rate or slower.
There was a hack posted at one time to the official 2.6.10 source that
fixed this for the DVEVM, but the drivers in 2.6.23 were reworked and I
couldn't find a nice way to apply them.
Solution: ???
---------
The only thing I can do at moment to get rid of this problem is to use the
AIC33 as a slave to the McBSP.
I have a feeling that it is going to cause me trouble when we move to our
target board which has 2 AIC33's tied to the same McBSP.
Speaking of which, anybody use multiple AIC33's in a davinci design?
Summary:
With the changes I listed, we are now able to run our test app without
locking up the /dev/dsp device regardless of the artificial latencies
introduced.
I'm not familiar with the patching protocol (although I've garnered a
little bit off of the exchanges with the NAND driver), but is this
something that should be submitted to the 2.6.23 git?
Regards,
David
DAVID A. KONDRAD
Software Design Engineer
On-Q/Legrand
www.onqlegrand.com
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
