Andy Ngo,Andrew Armstrong，你好
really? I will do more test.
[EMAIL PROTECTED]
2008-06-27
----- Original Message -----
From: Andy Ngo
To: jp_liu,Andrew Armstrong
Sent: 2008-06-26, 10:25:07
Subject: Re: Re: Re: RE: Buggy Audio Driver
JP,
I tried your fix and the write stall still occurs under heavy system
load (I forced the CPU to be utilized heavily as a test case to induce the
write stall). Hence the
fix you suggested didn't work for us since our system can be under
heaving load during usage. How did you come to the solution you suggested? Why
does switching the order of AUDIO_INCREMENT_HEAD(s) and audio_stop_dma(s) help?
Actually, when trying your suggestion, we actually got more write stalls in a
fixed period.
Anyways, I think I may be coming up to something with this write stall issue.
The change below is what I tried and it looks promising (I ran my heaving
system stress test for 3 hours and not a write stall has occurred yet, usually
I would get 3-5 stalls already); I'll let it run overnight to see if I no write
stall occurs (I have an infinite audio loopback test that reads from the device
and plays it back to the device, while other heaving processing is going on).
Just by trial and error, I uncommented the code to the 2 DMA_START calls in
audio_stop_dma (davinci-audio-dma-intfc.c):
Change
void audio_stop_dma(audio_stream_t * s)
{
...
if (s->spin_idle) {
#if 0
DMA_START(s, SPIN_ADDR, SPIN_SIZE);
DMA_START(s, SPIN_ADDR, SPIN_SIZE);
#endif
s->dma_spinref = 2;
} else
...
}
to
void audio_stop_dma(audio_stream_t * s)
{
...
if (s->spin_idle) {
#if 1
davinci_start_sound_dma(s, SPIN_ADDR, SPIN_SIZE);
davinci_start_sound_dma(s, SPIN_ADDR, SPIN_SIZE);
#endif
s->dma_spinref = 2;
} else
...
}
I looked at the other drivers in the oss directory and some have these
commented DMA_START calls enabled so I wonder why it was commented out for this
board. It's good so far (usually I would have 3-5 stalls in the 3-hour period I
have run the test). I'm keeping my fingers crossed.
JP, when you switch to McASP as the master, you need to adjust the J-value,
D-values 8-MSBs and 6-MSBs based on the clock to your AIC33 codec you're
using.. For the DVEVM, the clock is 22Mhz (#define MCLK 22), so the J-value,
D-values 8-MSBs and 6-MSBs values you see in davinci_set_samplerate
(davinci-audio-aic33.c) is based on this clock. For our system, the MCLK is
actually 22.588 Mhz so I adjusted the J-value, D-values 8-MSBs and 6-MSBs for
the sample rate I'm using (8Khz) and it works fine; I had weird sounds like you
did until I adjusted the J-value, D-values 8-MSBs and 6-MSBs; took me a while
to figure it out.
For those willing to try out what I did, please let the forum know if it fixes
your write stall problems. Thanks.
Regards,
Andy
----- Original Message ----
> From: jp_liu <[EMAIL PROTECTED]>
> To: Andrew Armstrong <[EMAIL PROTECTED]>
> Cc: davinci-linux-open-source <[email protected]>
> Sent: Wednesday, June 25, 2008 6:41:07 PM
> Subject: Re: Re: Re: RE: Buggy Audio Driver
>
>
> Sounds good! If got any new info about it, Dont forget to tell me.
>
> ----- Original Message -----
> From: "Andrew Armstrong"
> Cc: "davinci-linux-open-source"
>
> Sent: Wednesday, June 25, 2008 7:14 PM
> Subject: Re: Re: Re: RE: Buggy Audio Driver
>
>
> Guys,
>
> I tried jp_liu's suggested kernel fix, however I left my AIC33 as
> MASTER, and it seems to be running without locking up. Cheers JP!
>
> On a side note, I never really got the McASP to work as a master
> successfully, but I did not bother digging around for the cause.
>
> Thanks for all your help, I will probably revisit this in the near
> future.
>
> Best Regards,
>
> Andrew
>
>
> On Wed, 2008-06-25 at 11:19 +0800, jp_liu wrote:
> > Andy Ngo,Andrew Armstrong,PQuiney,davinci-linux-open-source,
> >
> > yes, I changed it base david's version(btw, thanks david). the sound
> > is bad because commented out "if (AUDIO_QUEUE_LAST(s)){ ... }" in
> > function sound_dma_irq_handler().
> > but another issue is cannot set clock-rate to 8000 when using the
> > McASP as the master, it is so bad.
> > I think set which is master is not the point to caused the problem,
> > but I have not confirm it yet.
> >
> >
> >
> > [EMAIL PROTECTED]
> > 2008-06-25
> > ----- Original Message -----
> > From: Andy Ngo
> > To: jp_liu,Andrew Armstrong,PQuiney,davinci-linux-open-source
> > Sent: 2008-06-25, 11:11:47
> > Subject: Re: Re: RE: Buggy Audio Driver
> >
> >
> >
> >
> > Thanks, jp_liu. I will try that out. This is similarly to
> > David Conrad's initial breakthrough post a while back but it
> > sounds promising.. By the way, I too am using the McASP as the
> > master and not the AIC33 codec.
> >
> > Regards,
> > Andy
> >
> > ----- Original Message ----
> > From: jp_liu
> > To: Andy Ngo ; Andrew Armstrong
> > ; PQuiney
> > ; davinci-linux-open-source
> >
> > Sent: Tuesday, June 24, 2008 7:25:08 PM
> > Subject: Re: Re: RE: Buggy Audio Driver
> >
> > Andy Ngo,Andrew Armstrong,PQuiney,davinci-linux-open-source,
> >
> > I also spent many days debug this issue, and I change some
> > codes, until now, It looks run well.
> >
> > 1st, commented out the marco #define AIC33_MASTER
> > in davinci-audio-aic33.c
> > 2nd, function sound_dma_irq_handler() in
> > davinci-audio-dma-intfc.c, I change it like this:
> > static void sound_dma_irq_handler(int sound_curr_lch, u16
> > ch_status, void* data)
> > {
> > ....
> > /*
> > AUDIO_INCREMENT_HEAD(s);
> > audio_stop_dma(s);
> > */
> > audio_stop_dma(s);
> > AUDIO_INCREMENT_HEAD(s);
> > ....
> > }
> > I think it is the point what cause lockup in read/write
> >
> > 3rd. function audio_dsr_handler() in
> > davinci-audio-dma-intfc.c, I commented out
> > AUDIO_INCREMENT_HEAD(s) when AUDIO_QUEUE_EMPTY(s) is true.
> >
> > you can try this, good luck.
> >
> > jp_liu$B!$([EMAIL PROTECTED]
> > 2008-06-25
> > ----- Original Message -----
> > From: Andy Ngo
> > To: andrewa,Phil Quiney,davinci-linux-open-source
> > Sent: 2008-06-25, 09:12:33
> > Subject: Re: RE: Buggy Audio Driver
> >
> >
> >
> >
> > Andrew,
> >
> > I spent many a day debugging the audio driver write
> > lockup issue and to this day, I still haven't figured
> > it out. However, I did pinpoint the hanging problem
> > when closing the device to an "audio_sync" call in the
> > audio_release function in davinci-audio.c. Try this,
> > comment out the call to audio_sync in the function
> > audio_release in
> > linux-davinci-2.6/sound/oss/davinci-audio.c:
> >
> > static int audio_release(struct inode *inode, struct
> > file *file)
> > {
> > audio_state_t *state = file->private_data;
> > audio_stream_t *os = state->output_stream;
> > audio_stream_t *is = state->input_stream;
> > FN_IN;
> > down(&state->sem);
> > if (file->f_mode & FMODE_READ) {
> > audio_discard_buf(is);
> > DMA_FREE(is);
> > is->dma_spinref = 0;
> > if (state->need_tx_for_rx) {
> > os->spin_idle = 0;
> > if (!state->wr_ref) {
> > DMA_FREE(os);
> > os->dma_spinref = 0;
> > }
> > }
> > state->rd_ref = 0;
> > }
> > if (file->f_mode & FMODE_WRITE) {
> > //audio_sync(file); // <== COMMENT this out
> > audio_discard_buf(os);
> > if (!state->need_tx_for_rx || !state->rd_ref) {
> > DMA_FREE(os);
> > os->dma_spinref = 0;
> > }
> > state->wr_ref = 0;
> > }
> > .
> > .
> > .
> > }
> >
> > This works for me and I never get a hang when my
> > application closes the device. This is probably not
> > the proper solution but until someone can write a
> > better audio driver (like porting it to ALSA), this
> > will have to be it for now.
> >
> > As for the write lockup, we're using a recovering
> > logic to detect the stall and just force the audio
> > driver to reset (losing a few seconds of audio). I
> > don't know if this matters but according to the OSS
> > API guide (http://www.opensound.com/pguide), the
> > fragment size should be a power of 2; the default
> > fragment size (AUDIO_FRAGSIZE_DEFAULT) is 3072, which
> > is not a power of 2. I tried changing that to 4096
> > but it didn't help.
> >
> > If anyone out there has found a fix to the write
> > lockup issue, please share!!! Thank you.
> >
> > Regards,
> > Andy
> >
> >
> > ----- Original Message ----
> > From: "[EMAIL PROTECTED]"
> > To: Phil Quiney ;
> > [email protected]
> > Sent: Tuesday, June 24, 2008 12:37:55 PM
> > Subject: Re: RE: Buggy Audio Driver
> >
> > Hi Phil,
> >
> > Thank you for your comments. I am disappointed to say,
> > that the sample code is only one of several methods I
> > have attempted to get working properly. I do attempt
> > to initialise the device prior to calling this
> > function.
> >
> > It is strange that our tests show the program hanging
> > when trying to close the device.
> >
> > I implemented a version which did not close the
> > device, however the OS had just as little luck in
> > trying to close the handle.
> >
> > If you have any code I could test as an audio
> > 'loopthrough' function I would be most interested. I
> > am keen to get something stable going.
> >
> > Will use O_RDWR in future!
> >
> > Regards,
> >
> > Andrew
> >
> >
> > At 10:32 24/06/2008, "Phil Quiney" wrote:
> >
> > > Hi,
> > >
> > > I think your program is not helping by reading too
> > > small chunks.
> > >
> > > You have not configured the speed of the device, the
> > > bits/sample number of channels etc - so what format
> > > is it using by default???
> > >
> > > Your read will block giving plenty of scope for the
> > > output under running as well....
> > >
> > > General advice on audio (initially from a guy at MV)
> > >
> > > 1/ Check for available data input before reading (do
> > > not do blocking reads).. This is not an issue if you
> > > are only doing input but for full duplex it matters.
> > >
> > > 2/ Empty the device by reading as much data as you
> > > can.
> > >
> > > 3/ Read in multiples of the fragment size.
> > >
> > > 4/ Check for available output space before the write
> > > - the write will not block if it can accept the
> > > data.
> > >
> > > 5/ Write in multiples of the fragment size.
> > >
> > > Using the above advice we can usually get several
> > > hours of full duplex audio before it dies.
> > >
> > > I can let you have the audio test program(s) we give
> > > to customers if you want to give that a go.
> > >
> > > As a final note - if you want the code to be
> > > portable across many targets, I suggest you change
> > > the 'open' to be O_RDWR as most OSS audio drivers
> > > will fail to open the second time.
> > >
> > > Regards
> > >
> > > Phil Q
> > >
> > >
> > > Phil Quiney, Senior Software Engineer
> > > Trinity Convergence
> > > Cambridge Business Park
> > > Cowley Road
> > > Cambridge CB4 0WZ, UK
> > > T: +44(0)1223-435536
> > > F: +44(0)1223-435560
> > > www.trinityconvergence.com
> > >
> > >
> > > -----Original Message-----
> > > From:
> > > [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf
> > Of Andrew Armstrong
> > > Sent: 24 June 2008 10:41
> > > To: [email protected]
> > > Subject: Buggy Audio Driver
> > >
> > > Hi Guys,
> > >
> > > I have been playing with the audio driver. All I
> > > want to do is a simple loopthrough function,
> > > however, I am finding that the driver locks up quite
> > > randomly when its file handles are being closed.
> > >
> > > Has anyone else come up with this issue? I have
> > > attached the function I am playing with, if anyone
> > > can replicate the issue I would be most interested.
> > > Sometimes it can run several times with no issue and
> > > other times lock-up each time it is executed.
> > >
> > > Regards,
> > >
> > > Andrew
> > >
> > >
> > > void audioloop(unsigned char timesecs)
> > > {
> > > int fdr;
> > > int fdw;
> > > unsigned char buffer[64];
> > > unsigned char done = 0;
> > >
> > > if( (fdr=open("/dev/sound/dsp",O_RDONLY)) < 0)
> > > {
> > > printf( "Sound Input Port failed!\n");
> > > }
> > > else
> > > {
> > > if( (fdw=open("/dev/sound/dsp",O_WRONLY)) < 0)
> > > {
> > > printf( "Sound Output Port failed!\n");
> > > }
> > > else
> > > {
> > >
> > > time(&starttime);
> > >
> > > while (done==0)
> > > {
> > > read(fdr,buffer,64);
> > > ioctl(fdr, SOUND_PCM_SYNC, 0);
> > > write(fdw,buffer,64);
> > > if (timesecs > 0)
> > > {
> > > time(¤ttime);
> > > if ((int)(currenttime - starttime) > timesecs)
> > > {
> > > done=1;
> > > }
> > > }
> > > }
> > > close (fdr);
> > > }
> > > printf( "Closing sound port ...\n");
> > > close (fdw);
> > > printf( "... Done\n");
> > > }
> > > }
> > >
> > > _______________________________________________
> > > 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
> > >
> >
> >
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
