• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 905 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: use appe to output audio data in android，appe_open is fail when appe_close not be run

user5180768
Prodigy 30 points
Part Number: DRA745


Tool/software: Linux

Hi,

    I use appe to output audio data in android, use appe_open to open a appe_pcm and use appe_close to close it. Now, I meet a problem,

if use "kill -9 (server)" to kill the task which is using appe, it will fail to appe_open when I run the task again,the reason is the appe has be opened.

In the Ti demo, use capture a signal to get the status of "kill server" or "Ctrl + c" , it's ok. But, "kill -9 (server)" is different with "kill server", not signal could be captured.

The "kill -9 (server)" may happen in android. I don't know how to slove the problem. 

Thanks,

  • 0
    TI__Mastermind 42515 points
    Hi,

    I have forwarded your question to an audio expert.

    Regards,
    Yordan
  • 0 in reply to Yordan Kamenov
    Prodigy 30 points

    Hi，

         In the demo provided by TI，it‘s：

         appe_init();

         appe_open(appe_pcm);

         signal(SIGKILL, exit);

         ......

    exit:

        appe_close(appe_pcm);

    But,  if use "kill -9" to kill the task, run the tesk again,  appe_open is fail about "appe_open() failed because APPE port is already occupied with playback",

    the reason is the signal of "kill -9" can not be catched. I want to konw how to slove it.

    thanks,

  • 0 in reply to user5180768
    TI__Genius 9295 points
    Unfortunately, killing the APPE playback stream via SIGKILL doesn't allow for a clean shutdown, so it would be expected that this could potentially cause problems. As APPE is a multi-core solution, the HLOS can’t clean up loose ends on the DSP side when an unconditional plug is pulled.

    Why not using other signals (i.e. SIGTERM)? My understanding is that one uses SIGKILL as a last resort.
  • 0 in reply to Misael Lopez Cruz
    Prodigy 30 points

    Hi Misael,

          Thanks for your reply !

          I had tried to slove it by using other signals, the result was bad. In android, it is poaaible to kill some tasks when the system not enough memory, so "kill -9" will

    be executed by the system. In the google search, I found "kill -9" is special —— the operating system does not allow the task to capture the signal .  I can not control

    the system to kill task by other modes, so use signals can not slove the trouble. 

         Is there any other way to solve this trouble about "appe_open is fail when appe_close not be run" ?

    Thanks,

  • 0 in reply to user5180768
    TI__Genius 9295 points
    Does OOM occur frequently in your system? I mean, the APPE HAL process (in Oreo) or mediaserver process (in earlier versions) would have to be killed for you to encounter this issue. I think those processes are not the first ones to be killed after an OOM condition. Usually it's determined by how long the process has lived and how much memory it has allocated. The APPE HAL runs since boot time and doesn't allocate much memory so shouldn't be one of the first process that are killed.

    Unfortunately a fix for the SIGKILL case in the APPE (and more specifically, in the IPC RingIO component) is not trivial. And I'm not aware of any other possible solution to suggest.