ARM9上音频驱动的问题，急急急！

有个问题困扰很久了，调通了音频驱动和触摸屏，但是发现一个问题，
当在屏幕上快速的画一个弧线时：
1、如果关闭点击屏幕的声音，那么在手写输入和触摸屏测试程序中的弧线都是圆滑的。
2、如果打开点击屏幕的声音，那么在触摸屏测试程序中的弧线是圆滑的，但是手写输入的窗口中的弧线的第一笔变成了一根直线，然后才是弧线。也就是说开始的第一点之后的一些点不见了。
（说明一下，通过232口监视触摸屏的数据，然后在PC的画图软件里面按照每个点的坐标连起来，弧线是圆滑的。）

有那位大侠知道这是什么原因造成的呢。

这个可能和音频驱动没有关系，即使有关系也是跟音频部分硬件的关系，说起来比较牵强，但我认为也不是不可能，毕竟声音是一个比较大的电源消耗，短暂的发声如果电源没有设计好的话，会在电源线上面形成一个抖动，而触摸屏如果是大屏的话，对这种干扰还是比较敏感的。但是你的情况看来又不像是这些的原因。

有点没有说明清楚，实际上触摸屏的驱动返回的数据是正确的，但是是什么导致了手写输入把其中刚开始的数据丢失了。

现在看来按理是应该和你的手写输入程序有点关系，但怪就怪在为什么打开触摸屏点击声的时候才会出现这样的问题。我的QQ：250290456

刚下笔时系统要播放声音,所以要初始化音频硬件,这个过程可能比较常,因而有些TOUCH的数据被丢了.
你看一下,AUDIO的初始化代码能不能精减,播放时如果源是多少K就让硬件按多少K播,这样CPU的消耗会比较少.如果这些都做了还不行,就在这个程序启动后把点击屏幕的声音关掉好了.
这不算问题.

感谢大家的帮忙，我也觉得microsun的分析非常有道理，刚刚试过一边放音乐一边画曲线，没有这样的问题。
因此就目前的情况来看，应该是初始化音频硬件的部分的问题，而且由于硬件的局限不能动态切换声音的采样率，所以还是有点麻烦。

能否问下，在初始化初始化音频硬件的时候有的地方需要延时一段时间，如果时间长了会影响到其他的进程（手写输入）的代码就不会运行了吗。

你看音频和触摸屏是不是共用了硬件，比如都用到了spi，如果是的话，音频驱动初始化的时候就会出现竞争条件，导致在音频初始化的时候触摸屏得不到数据。

问题可以确定是在初始化音频硬件的时候需要延时一段时间，如果这个时间长了就会影响到其他的进程（手写输入）的代码运行，我想问下怎么会出现这样的现象呢。

应该是系统去执行AUDIO的IST了,这个IST用的时间很长,因而TOUCH驱动没有时间响应,把一部分点丢了.

多谢microsun，但是实际上touch的驱动是有返回数据的。
现在我把延时改到2ms，手写可以工作了。
但是如果播放音乐是有声音的，但是点击屏幕时，声音时有时无了。

你什么地方会延时2ms啊,你这具体是个什么流程.

在hwctxt.cpp的HardwareContext::StartOutputDMA()里面，
在这个里面需要初始化音频硬件，需要一定的延时。

可以把大部分初始化的代码放到INIT中,就是说系统启动以后只做一次.
以后STOP时只是它CODEC置为STOP状态,
PLAY时让它RUN就行了.

这样做会比较麻烦，因为还牵扯到录音的问题，以及一些硬件内部的切换。
今天忙了一天，跟手写的厂家沟通了一下，拿到一个测试程序，现在问题比较明朗了。

如果在音频驱动中延时，确实会使系统挂起，结果就是好几个点才产生一个MOUSEMOVE的消息，当前的参数反映的就是最后一个点坐标，前面几个点的数据被放到缓冲区中了，而手写只读取MOUSEMOVE消息的参数作为当前的坐标，从而导致从第一点直接画一根直线到当前点，中间点都没有处理。

其实经过测试发现，即便音频驱动没有延时，但是如果系统这是正好在处理一个优先级高的进程，一样会导致2～3点才产生一个MOUSEMOVE消息，只是间隔比较小不太明显摆了。

不知大家对此有没有什么好办法。

你用什么手写输入法？

这个不是手写识别驱动的问题，是用户UI跟手写的接口的那部分代码，里面只处理了MOUSEMOVE消息的参数，而没有处理缓冲区的数据。

这个帖子 是个好帖

引用第15楼NewTech于2007-12-16 12:19发表的  :
这个不是手写识别驱动的问题，是用户UI跟手写的接口的那部分代码，里面只处理了MOUSEMOVE消息的参数，而没有处理缓冲区的数据。

说得不错， 这是系统响应的问题、用户Draw代码问题；尤其在中文版的系统中，这种现象更加突出

这个与音频的初始化无关的，音频驱动在第一次Load的时候就已经初始化好了。所以，操作Touch的时候，不会涉及到音频初始化，只能用到了Codec的数据采集。
但是，这要当前存在一个线程优先级比Touch IST高，则Touch IST将挂起，但Codec的数据采集仍在继续，且存放在FIFO中。