过年在家搭建了 app 的 win 服务端，create install 免费版打包，已经可以使 用了。
架构方面，两个程序组成，都是 win32 api，不需要依赖 dot net。
网上抄的一个 win32 任务栏图标代码，在此基础上加入了之前的跨平台服务端线 程，就跑起来了。
设置界面用的是 IUP 界面库，一个支持 win、gtk、motif 的框架，事件驱动，要 比基础的 win32 gdi 编程好太多，而又不需要依赖 dot net。
之前为了 IPC 通信，还尝试使用了 mail slot，不过当时我的架构不是很好，出 了不少问题，最后也没有继续用下来去，而是直接 findwindow，通过标题栏、 class name 匹配，然后 post message 来通信，感觉也足够了。
学习使用 iup 也花了一些时间，相比之下，为了让 vs2012 支持 xp 而弄的各种 调试，简直让人吐血。
后来我是放弃了 vs2012，改用 vs2010，xp 可是不能放弃的。vs2010 还必须安装 sp1 才行，否则编译下来各种问题，即便是 sp1，也不是每次编译都能顺利通过。
一个 sp1 补丁包就 1.5G，也够吐血的。
忙活的网络播放器有了眉目，音视频同步起来了，之前的问题，在于 audio 播放 一直很不顺利，总是偶尔会卡，或者嗤嗤地想，我一直单独地认为是 audio 播放 的问题，或者是 OpenAL 管理 buffer 的问题。
当然后来也发现 OpenAL 的 buffer 管理也是需要注意的，比如建立了 64 个 buffer，做 streaming，最好是都先全部 queue 上去，再 query 哪些已经 processed，之后 buffer data，之后再 re queue；而不是先 queue 一部分， query 无 processed 之后，queue 新的 buffer，iOS 上面者会造成嗤地噪声，估 计是 OpenAL 管理的问题。
当然 OpenAL 在我这里还有一些未解决的问题，以后再说吧。
接着说不同步的部分，更多的是时钟不同步造成的，也就是延时。
比如主时钟一般都是 video 管着的，而 video 每一帧时间跨度要比 audio 大多 了，一秒才小几十帧，每一帧稍微拖延或快一点，其实我们人眼不敏感，而 audio 呢，普通的 22k 都是差的音频，一般 44.1k，或者 48k，这个时钟相比 video 部 分就要求很精确了，当然这部分其实都是硬件管着，封装出来的 OpenAL 接口也简 单，扔 buffer 进去就行。
问题在于 video 管时钟，video 拖延一点，我们人眼觉得 video 还正常，但是怎 么 audio 就那么刺耳了呢，其实是 audio 的 buffer 数据跟不上了。
在 iOS 平台上面，是 dispatch_after 等这些延时的函数时间非常不精确，虽然 是以 nano seconds 为单位的，但是这个单位只是说能够延时的最小单位，而并不 是精确到这个单位，这两者是有很大区别的。
所以 AV 同步部分就得做很多的时间检测以及补偿，如果是 video 主时钟，就补 偿 video，并不是为了人眼看得舒服（其实真看不出来），而是为了 audio 能够 顺利同步，两边的 buffer 都能够平衡。