作为一个多媒体技术方面的初学者,我从wav文件的播放开始了解媒体播放的流程。
于是从建立两个线程开始,线程1用来将文件中的数据读到Buffer中去,以后称为读线程,线程2用来将Buffer中的数据送到设备的缓存,以后成为写线程。在最开始的时候,本着从易到难的精神,只开了一个buffer,我的想法很简单,先将数据写进这个Buffer,然后再送入设备进行播放,结果是每个Buffer中间有个空隙,这件事情是明摆着的,只采用一个Buffer肯定会导致这样的结果。在我看来是因为,设备将缓存中的数据播放完以后回头去Buffer取数据时发现Buffer是空的,因而再去读线程将PCM数据写入Buffer,也就是说设备有一段时间是无事可做的,听起来当然是断断续续的了。
听了高手的意见建立了一个包含两个Buffer的队列。
在用缓冲队列播放wav文件的时候却始终遇到一个问题,在播放的时候会在每个buffer读取数据的空隙产生停顿,这不是还和一个Buffer一样?难道采用两个Buffer也不行,要更多的Buffer?在网上查阅一些资料时发现理解上的偏差,两个buffer的切换流程如下所示:
Buffer[0] read;
Buffer[1] read;
Buffer[0] write to device;
Buffer[0]read;
Buffer[1]write to device;
也就是说,在Buffer[0]写入设备缓存之后就立刻再去取数据,也就是要保证在每个时刻都至少有一个Buffer里面有数据。
而我没有预先将Buffer写满,结局自然是和一个Buffer一样,想到这里我信心满满,觉得问题就要解决了,实际上还有很多问题。最终我放弃了建立两个子线程的想法(实际也不需要)。
有关Buffer的切换是想明白了,具体实施起来有两种方法。两种方法本质上是相同的,只不过是在waveOutOpen的时候最后一个参数的设置不同。
方法一:使用CALLBACK_FUNCTION(回调函数)。详见wince help中关于WaveOutProc函数的说明,只需要一个线程,通过回调函数查看系统消息WOM_DONE,来确定Buffer中的数据有没有被播放完毕,如果播放完毕则首先清空设备缓存(waveOutUnprepare),然后写Buffer,将Buffer中的数据送入设备缓存。还要判断文件是否已经读完,如果读完则跳出CallBack函数。
方法二:使用CALLBACK_EVENT。另外建立一个子线程。微软方面提供的文档告诉我们,应该检查dwFlags&&WHDR_DONE 是否为WHDR_DONE,以确保Buffer中的数据已经被播放完毕。当子线程开始执行时要判断这两个参数为真时,才能清空设备缓存。
两者的不同是,方法一中,系统会自动将播放完毕的Buffer地址返回到程序中,当callback函数被调用时可以直接使用;使用方法二,则要不断地判断Buffer中的数据是否已经播放完毕。
ps:采用多少个只要每次填入的数据(播放时间)在1/50~1/70秒以上,就不会出现咔咔的声音,和具体和设备性能以及声卡驱动有关。

2

3

4


5

6

7

8


9

10

11

12

13


14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40


41

42

43

44

45

46


47

48

49

50


51

52

53


54

55

56

57


58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

Walzer评点:
文章给全了用CALLBACK FUNCTION和CALLBACK EVENT两种处理方式的SAMPLE CODE。但要特别注意,这只是个DEMO,在多线程的项目中,WAVEOUT CALLBACK处理中调用WaveOutUnprepare甚至WaveOutWrite是很危险的,具体见我那篇《WaveOutReset的N种死法》。
本文转自Walzer博客园博客,原文链接:http://www.cnblogs.com/walzer/archive/2008/02/20/1074400.html,如需转载请自行联系原作者