Re: [alsa-devel] DaVinci ASoC DMA stalls
I did have to add a getposition accessor to the DaVinci DMA module, which is used by the pcm_pointer function. Other than that, I believe the ASoC should build. My test is simply to run aplay or speaker-test, then quit and run it again. The first run is audible, the second and subsequent runs are not audible until I provide a manual DMA event trigger.
Mark
Caglar Akyuz wrote:
Mark Lokowich wrote:
I've been using the DaVinci ASoC for a few months and have recently upgraded to the 2.6.26 based DaVinci git kernel. Now my audio DMA stalls more readily after stopping an active stream. I can manually trigger the event by poking the ESR to reactivate the stalled stream, suggesting the problem is in the ASP-to-DMA XEVT interface. This problem is less prevalent in the 2.6.25 based kernel. Any help?
I don't know if this helps but, I am using ASoC code on my DaVinci board with latest git kernel(2.6.27) and I have no visible issues with the ASoC code. However, there may be some code-coverage issue with my usage so if you have any test method to verify that I really don't have your problem I'll be happy to perform some tests.
My real concern is that this code has never been built without any problems here. First there was a separate asoc branch in davinci tree which failed to built. I tried with 2.6.25 and there was again build issues. Finally I wasn't able to build ASoC code with 2.6.27 so I tried to patch it. I think some part of it relies on some dma code which is not present in davinci tree.[1] I don't know if everybody else is patching kernel source to build asoc support, maybe I'm doing something wrong. I'm not sure, just FYI.
Regards, Caglar
[1] http://linux.omap.com/pipermail/davinci-linux-open-source/2008-March/005920....
My test is simply to run aplay or speaker-test, then quit and run it again. The first run is audible, the second and subsequent runs are not audible until I provide a manual DMA event trigger.
When the ASP transmitter is taken out of reset it sends XEVT to the EDMA where it is "captured" in event register (ER). If that event gets cleared out before turning on the EDMA you'll end up with a scenario like you described, i.e. once you kick off a transfer manually it will then run. I haven't looked at the code you're using, but it sounds to me like the (re-)initialization sequence isn't correct.
The best way for the code to work would be for the EDMA to be configured BEFORE the McBSP. That way, even if the EDMA initialization procedure clears the ER bits it won't matter because when the McBSP is subsequently released from reset it will send a new XEVT to the EDMA.
Brad
Griffis, Brad wrote:
My test is simply to run aplay or speaker-test, then quit and run it again. The first run is audible, the second and subsequent runs are not audible until I provide a manual DMA event trigger.
When the ASP transmitter is taken out of reset it sends XEVT to the EDMA where it is "captured" in event register (ER). If that event gets cleared out before turning on the EDMA you'll end up with a scenario like you described, i.e. once you kick off a transfer manually it will then run. I haven't looked at the code you're using, but it sounds to me like the (re-)initialization sequence isn't correct.
The best way for the code to work would be for the EDMA to be configured BEFORE the McBSP. That way, even if the EDMA initialization procedure clears the ER bits it won't matter because when the McBSP is subsequently released from reset it will send a new XEVT to the EDMA.
Brad
Excellent tip, but the ASoC software is doing just what you suggested, starting the DMA prior to starting the ASP. I also found that the latest DMA software also causes buffer underruns when playing Ogg Vorbis files, while the 2.6.25 version doesn't have these issues. I'll keep looking.
Thanks, Mark
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
participants (2)
-
Griffis, Brad -
Mark Lokowich