Need thread permissions in primary audio hal

Products Support HiKey
#1

Hi,
I am creating two threads with SCHED_FIFO capability in Primary audio hal to handle BT-HFP. But threads are not creating with that capability, when I debugged i came to know that it need SYS_NICE capability. So can you please help me out on how to enable that.

#2

What board are you using?

#3

Hi,
Hikey board only

#4

Ok… I moved this to the correct topic.

#5

Well… overkill much?
And any particular reason you’re reinventing the wheel?

It actually simplifies things greatly to run everything in a single thread. This ensures that your reads and writes remain synchronized in order to prevent drift between the two threads.

Use the bluetooth side for synchronization.
Perform a blocking read of a fixed size from the bluetooth, i.e., 10 ms, then you do the near side audio processing, then you write the same fixed size back out to the bluetooth.

For the near side audio, you will need to pay attention to the buffers. You don’t want to block on the near side pcm, otherwise everything will turn to crap in a heartbeat. This means that you need to limit your reads/writes on the near side to the available space in the hardware buffer. Always perform related read/write at the same size as each other in order to avoid mucking up the buffers.

Performance wise, you just need to be able to handle a 10 ms cycle at an average rate of under 10 ms. Note that I said AVERAGE rate, because slowdowns are fine as long as they are reasonably short duration – the hardware buffers will take up the slack.

The process works like this;

  1. read 10 ms from the bluetooth (10 ms is the sample length required by webrtc for echo cancellation).
  2. check the buffer status of the local output pcm and adjust the sample you read from the bluetooth to an appropriate length.
  3. write the adjusted sample to the local output pcm.
  4. read the same LENGTH of sample from the local input pcm.
  5. adjust the length of the sample you just read to exactly 10 ms.
  6. write the 10 ms sample to the bluetooth.

There are going to be a few more steps in there, of course, like switching the channel count and sample rate, echo cancellation, buffer pre-filling, etc.

#6

Hi,
I am doing the same, one thread to read from BT and write to speaker, the other thread read from MIC and update to BT. But thread creation is giving a problem for me with SCHED_PRIORITY

#7

And like I said, it simplifies things greatly to do it all in ONE thread rather than 2, and there are NO BENEFITS to running a second thread.

And you don’t need to set the thread priority. If the machine gets bogged down far enough that it can’t handle simple audio, then you have much greater things to worry about than your phone call getting a little crackly.

You asked about hfp before in another thread, and I linked you to a WORKING IMPLEMENTATION. Start there.