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
