This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] Linux/DRA745:使用 APPE 在 Android 中输出音频数据,APPE_OPEN 在 APPE_CLOSE 未运行时失败

Guru**** 2595770 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/642310/linux-dra745-use-appe-to-output-audio-data-in-android-appe_open-is-fail-when-appe_close-not-be-run

器件型号:DRA745

工具/软件:Linux

您好!

  我使用 APPE 在 Android 中输出音频数据、使用 APPE_OPEN 打开 APPE_PCM 并使用 APPE_CLOSE 将其关闭。 现在、我遇到了一个问题、

如果使用"kill -9 (server)"来终止使用 APPE 的任务、当我再次运行该任务时 APPE_open 将失败、原因是 APPE 已打开。

在 TI 演示中,使用 捕获信号获取“kill server”或“ctrl + c”的状态,这是可以的。 但是、 "kill -9 (server)"与 "kill server"不同、无法  捕获信号。

"kill -9 (服务器)"可能发生在 Android 中。 我不知道如何解决这个问题。  

谢谢、

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    我已将您的问题转交给音频专家。

    此致、
    Yordan
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好,

       在 ,的演示中、它是‘s:

       APPE_INIT();

       APPE_OPEN (APPE_PCM);

       信号(SIGKILL、EXIT);

       …

    退出:

      APPE_CLOSE (APPE_PCM);

    但是, 如果使用“kill -9”来终止任务,请再次运行 teck, APPE_open 将失败,大约“APPE_open()失败,因为 APPE 端口已被回放占用”,

    原因是 无法捕捉"kill -9"的信号。 我想夸一下怎么爱它。

    谢谢、

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    遗憾的是、通过 SIGKILL 中止 APPE 回放流不允许完全关闭、因此预计这可能会导致问题。 由于 APPE 是一种多核解决方案,当拉动无条件插头时,HLOS 无法清理 DSP 端的松动端。

    为什么不使用其他信号(如 SIGTERM)? 我的理解是、使用 SIGKILL 作为最后的手段。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    尊敬的 Misael:

       感谢您的回复!

       我试图通过使用 其他信号来爱上它、结果很糟糕。 在 Android 中、当系统内存不足时、可以中止某些任务、因此"kill -9 "将会

    由系统执行。 在 Google 搜索中,我发现“kill -9”是 特殊的— —操作系统不允许任务捕获信号。  我无法控制

    系统会通过其他模式来终止任务、因此使用 信号不会带来麻烦。  

       是否有任何其他方法可以解决有关"APPE_CLOSE 不运行时 APPE_OPEN 失败"的问题?

    谢谢、

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您的系统中是否经常出现房间? 我的意思是,APPE HAL 过程(在 Oreo 中)或 MediaServer 过程(在早期版本中)必须被终止才能遇到此问题。 我认为这些进程不是在一个房间条件之后首先被杀害的进程。 通常由进程的寿命以及分配的内存大小决定。 APPE HAL 自引导时间以来一直运行、并且不会分配太多内存、因此不应是第一个被终止的进程之一。

    遗憾的是、APPE (更具体地说、在 IPC RingIO 组件中)中对 SIGKILL 案例的修复并不重要。 我不知道还有其他任何可能的解决方案要推荐。