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

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

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

我也遇到过这个问题，后来挨个检查播放初始化代码，修改确认减小dealy时间才有所改善，不知道各位有没有其他好的方法

你的codec程序loading太大了吧

是的,人眼对图象的视觉没有耳朵对声音的感觉灵敏.
当然,不同的人对视觉/听觉感觉的灵敏度也是有差异的,就象有的人能提出CD和MP3音质的差别,有的人能在60HZ(甚至75Hz)感觉到屏幕闪烁,而有的人感觉不到.

视频vdeio时候,如果掉帧,我们不会明显感觉到(24fps的标准,但是15fps的看起来也很连贯)
但是音频audio不行, 人耳对声音比较敏感,所以音频的实时性比较高比较严格.

学习学习.............................................................

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

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

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

这个帖子 是个好帖

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

你用什么手写输入法？

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

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

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

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

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

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

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

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

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

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