[pulseaudio-discuss] Timing interval for Bluetooth Wideband speech

[Luiz Augusto von Dentz]

Hi Tanu Ajay,

On Sat, Apr 7, 2018 at 5:26 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> On Fri, 2018-04-06 at 19:05 +0530, Ajay Kv wrote:
>> Hi,
>>
>> I am following this mail thread. Also trying to make the same in my setup.
>> I have added msbc encoding/decoding in PA  (host) code . PA as BT  HF role
>> connected to  phone  .
>> Once the call is connected  PA  starts writing the audio (pcm data)  to SCO
>> socket  via  msbc encoder/decoder module
>> CVSD has sample rate of 8khz  (48bytes in every 3ms  ,mono )  and MSBC has
>> sample rate of 16khz . So as per
>> bluetooth Specification  msbc encoded data rate should be 60 bytes in every
>> 7.5ms,   ( (60*8 )   *   (1/7.5)   * 10^3  =  64Kbps)
>>
>> Currently with msbc enabled , we receives  240 bytes of pcm on every
>> polling (rendering )  which is decoded to
>> 60 bytes  of msbc encoded frame  ,where 60 is  sco mtu and 240 is the
>> write_block_size .
>>
>> Please find few of my queries regarding this
>> 1: As microphone is writing sco audio as soon as it is available . Do we
>> have any option  to configure
>>     the  stream rate or the clock tick for getting more samples  in PA
>> (timer based) or anywhere in rendering queue or
>>     streaming buffer based on the codec selected (different sample spec)?
>
> Since your use case is connecting to a phone, I guess the microphone is
> an alsa source that module-loopback connects to the bluetooth sink. Is
> that correct?
>
> I don't really understand your question, but I'll try answering
> nevertheless: You should configure the bluetooth sink (and source)
> sample_spec with 16 kHz sample rate when using wideband and with 8 kHz
> when using narrowband. PulseAudio will then resample the microphone
> audio to the target rate automatically.
>
>> 2: Is there a scope for implementing flow control (audio samples) mechanism
>> between PA and BT driver  to achieve
>>      the rate (7.5 msec interval)?
>
> thread_func() in module-bluez5-device.c does the scheduling. As I said
> earlier, currently the scheduling is based on the rate at which the
> kernel provides audio to the source. If you need to change the
> scheduling to use the system clock instead, that's possible by
> modifying thread_func(), but I find it hard to believe that we can't
> rely on the kernel to keep the data rate correct. My understanding of
> the SCO protocol is that both ends of the link somehow agree on a
> common clock, which probably is different than the system clock. I'm
> pretty sure the kernel (or perhaps the hardware, I don't know) is
> responsible for transmitting the data at the correct rate -
> PulseAudio's job is then to just fill the write buffer fast enough so
> that the kernel always has something available when the time comes to
> write a packet. PulseAudio can't know the exact agreed clock rate,
> except by observing at which rate the kernel is producing/consuming
> data from the socket. Why can't PulseAudio do its writes whenever it
> has read data from the kernel like it does now? The reads and writes
> should have the same rate anyway.
>
>> 3: If i add a delay of 7.5msec manually in polling thread (thread_func() -
>> ), will it halt the process to drop the audio packets (RX/TX).
>>     or  the rate and bytes at which PA writes to SCO socket is irrespective
>> of the codec selected ?
>
> If you decide to implement the sink scheduling with the system clock,
> you should calculate the appropriate sleep time that is passed to
> pa_rtpoll_run(). pa_rtpoll_run() may return before the configured
> amount of time has passed (this happens when messages are sent to the
> thread), so before writing anything you need to check if enough time
> has passed since the last write, or if you need to sleep some more.

Just keep in mind the 7.5 msec is specific for USB alternate setting 6
so I don't think we should hard code it as there are other transports
like UART and even controllers which don't support alternate setting
6. Also, like I just responded to Georg, perhaps we should not even be
sleeping for less than default-fragment-size-msec, well assuming that
is what PA uses for processing the audio frames.


> --
> Tanu
>
> https://liberapay.com/tanuk
> https://www.patreon.com/tanuk



-- 
Luiz Augusto von Dentz