[pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
Luiz Augusto von Dentz
luiz.dentz at gmail.com
Tue Apr 10 13:10:13 UTC 2018
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:
>> 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.
Luiz Augusto von Dentz
More information about the pulseaudio-discuss