Sounds good! If got any new info about it, Dont forget to tell me.
----- Original Message ----- From: "Andrew Armstrong" <[EMAIL PROTECTED]> Cc: "davinci-linux-open-source" <[email protected]>
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 NgoTo: 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 <[EMAIL PROTECTED]> To: Andy Ngo <[EMAIL PROTECTED]>; Andrew Armstrong <[EMAIL PROTECTED]>; PQuiney <[EMAIL PROTECTED]>; davinci-linux-open-source <[email protected]> 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 NgoTo: 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]" <[EMAIL PROTECTED]> To: Phil Quiney <[EMAIL PROTECTED]>; [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
