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

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

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

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

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

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

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

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

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

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

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

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

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

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