从 Lion 中的 IOAudio kext 调用 proc_selfppid()
我有一个基于Apple的AudioReflectorDriver示例代码的kext（它拦截音频输出并制作副本）。
在 <= 10.6 上，当您在 IOAudioEngine 子类中调用 proc_selfpid() 时，它会报告生成音频的进程的 PID。在 10.7 上，它始终将 coreaudio_d 报告为进程。
发生了什么变化？有谁知道苹果在哪里记录了这一变化？有什么方法可以获取Lion中的原始进程ID吗？
更新...Apple DTS 工程师告诉我：
音频 HAL 在 Lion 中完全重写，这一更改几乎可以肯定是该工作的副作用。我不认为这是故意的更改，而是由 CoreAudio 中较大的架构更改驱动的。严格来说，我不认为 proc_selfpid 曾被记录为在音频上下文中返回有用的内容，因此完全有可能此信息不再可用。
[...]
问题不是内核返回了错误的 pid，而是 CoreAudio 的架构发生了变化，导致音频来自不同的进程。
仍在等待他的回复，看看是否有任何方法可以在 10.7 中获取此信息。
我现在怀疑它没有被记录下来，因为重写没有改变 API。
I've got a kext based on Apple's AudioReflectorDriver sample code (it intercepts audio output and makes a copy).
On <= 10.6, when you call proc_selfpid() inside the IOAudioEngine subclass, it reports the PID of the process that generates the audio. On 10.7, it always reports coreaudio_d as the process.
What changed? Does anyone know where Apple has documented this change? Is there any way to get the originating process ID in Lion?
Update... an Apple DTS engineer has informed me that:
The Audio HAL was completely rewritten in Lion and this change was almost certainly a side effect of that effort. I don't believe that this was a deliberate change, but was instead driven by larger architectural changes in CoreAudio. Strictly speaking, I don't believe that proc_selfpid was ever documented to return something useful in the audio context, so it's entirely possible that this information is simply not available anymore.
[....]
The problem is not that the kernel is returing the wrong pid, but is instead that CoreAudio's architecture has changed such that the audio is coming from a different process.
Still waiting to hear back from him if there's any way to get this info in 10.7.
My suspicion now is that it wasn't documented because the rewrite didn't alter the API.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论