从本机代码将 PCM 音频数据写入音频设备
是否可以直接从本机代码将 PCM 样本写入 Android 下的音频设备? 我已经能够通过将数据发送到套接字并使用 AudioTrack 播放来重现 PCM 样本。是否可以通过直接从本机代码访问来避免所有这些通往音频设备的路径? 谢谢!
Is it possible to to write PCM samples to audio device under Android directly from native code?
I've been able to reproduce PCM samples by sending data to a socket and playing with AudioTrack. Is it possible to avoid all this path to audio device by accessing directly from native code?
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
是的,您可以尝试直接使用您的音频设备。该访问通过位于 /dev/ 中的 Linux 虚拟设备节点进行。
在我的 HTC Desire 上,这将是
我不知道不同供应商的其他设备如何称呼此设备。不保证该设备节点在重新启动或操作系统更新后具有相同的名称。因此,一旦您的应用程序发布,您将需要进行大量令人讨厌的修补工作。
警告执行以下命令将产生无限的白噪声,除非您杀死“猫”程序或重新启动手机
命令(在已root的手机上)
并将
产生白噪声电话扬声器发出噪音。
由于 cat 是一个 C 程序,您应该能够分析源代码并将其适应您的程序。
问题是:您的设备以及您的应用程序应在其上运行的每个设备都需要获得 root 权限才能实现此目的。
我认为 Android 方式是一种肮脏但最便携、最舒适的通过 NDK 播放声音的方式。
Yes you can try to use your audio devices directly. The access works over Linux virtual device nodes placed in /dev/.
On my HTC Desire this would be
I don't know how other devices of different vendors call this device. Its not guaranteed that this device node has the same name after reboot or OS update. So you will have a lot of nasty patching work to do once your application is shipped.
WARNING executing the following commands will produce an infinitely white noise sound unless you kill your "cat" program or reboot your phone
The command (ON A ROOTED PHONE)
and
will produce white noise come out of the phone speaker.
Since cat is a C program you should be able to analyse the source code and adapt it to your program.
The catch is: your device is required to be rooted to make this happen as well as every device your application should run on.
I guess the Android way is a dirty but most portable and comfortable way to play sounds via NDK.
重新阅读本文时,我问自己为什么我没有想到使用 JNI 从本机代码中简单地使用 AudioTrack...这应该是最好的解决方案。
Re-reading this I ask myself why I didn't think of simply using AudioTrack from native code using JNI... That should be the best solution.