DM365 Audio Cut out

What exact driver setup are you using (LSP version, etc,)? I am confused because the PSP driver provided with the DM365 2.10.00.06 DVSDK Beta (PSP 2.10.00.005) only supports ALSA, there is no support for OSS, this is mentioned specifically in the constraints section of the 2.00 Davinci Linux Audio Driver User's Guide SPRUG98.

I agree with Bernies comments regarding ALSA.  However, I am still a bit puzzled about what the data in the table represents; I think I can safely assume is time in milliseconds, but does this data represent 7 different runs of your test code?  Or Is it one run with 7 stages; if so, how do these stages differ?  I see a large variation accross the DM365 range and I am puzzled as to why this large difference.  If you can share some of the test code that would be great!

The numbers in the table actually show that the DM365 is doing its job properly, while the DM6467 is not (possibly). 

DM365 Case:
The reason why you're seeing the 45ms followed by a sheer drop-off is a combination of a few things: number of DMA channels allocated to the driver, number of DMA buffers allocated to the sound driver, and the audio buffer size - I've seen this scenario before, and its because your DMA buffer size is two times 4096 = 8192

In a single 8192 buffer (and at 44100Hz, stereo, 16 bit per sample), you can fit 2048 samples, which equals 46.44ms. Assume right now, that all the DMA buffers are completely filled with data, and you enter your write() call - the call will block until a single 8K buffer frees; once its free'ed (which took a buffer's worth of time = 46ms) you write your 4K in; On the next 4K write() call, you still have 4K of space left in the buffer, so return almost immediately; the NEXT time u do a 4K write, you'll have to repeat this waiting process of waiting for an 8K buffer to free up; 

Note that the average of the 45ms + 213us is ~ almost equal to an 8K frame time. So it looks like your DM365 is working correctly. Your best bet is to try writing exactly 8192 frame sizes and see the result. Otherwise, you can also tweak the ALSA buffer sizes to match your latency needs (since 8192 frame size at 8kHz sampling rate will give u quite a big latency)

DM6467:

Here, it looks like something is actually going a little wonky. Did you hear any audio drop-outs? It looks like you serviced that audio driver a little too late some times (17ms followed by 34ms); 17 is pretty close to a 4K frame time for 44100, (correct frame time is 23ms) - is DM6467 using OSS or ALSA? If its OSS, you can find the DMA buffer size pretty easily (its fixed).

Either way, the trick here if you want consistently  correct write() times, write exactly the DMA buffer size.

Will try playing with the ALSA on the DM365 EVM and 6467 EVMs i have on my desk, am curious now as to the behaviour.

Cheers,

Jerry

Jerry, this is great insight; thank you for sharing this detailed analysis with us.