<div dir="ltr"><br><div>Hi,</div><div><br></div><div>I am following this mail thread. Also trying to make the same in my setup.</div><div>I have added msbc encoding/decoding in PA (host) code . PA as BT HF role connected to phone .</div><div>Once the call is connected PA starts writing the audio (pcm data) to SCO socket via msbc encoder/decoder module </div><div>CVSD has sample rate of 8khz (48bytes in every 3ms ,mono ) and MSBC has sample rate of 16khz . So as per<br></div><div>bluetooth Specification msbc encoded data rate should be 60 bytes in every 7.5ms, ( (60*8 ) * (1/7.5) * 10^3 = 64Kbps)</div><div><br></div><div>Currently with msbc enabled , we receives 240 bytes of pcm on every polling (rendering ) which is decoded to<br></div><div>60 bytes of msbc encoded frame ,where 60 is sco mtu and 240 is the write_block_size .</div><div><br></div><div>Please find few of my queries regarding this </div><div>1: As microphone is writing sco audio as soon as it is available . Do we have any option to configure <br></div><div> the stream rate or the clock tick for getting more samples in PA (timer based) or anywhere in rendering queue or </div><div> streaming buffer based on the codec selected (different sample spec)?</div><div><br></div><div>2: Is there a scope for implementing flow control (audio samples) mechanism between PA and BT driver to achieve </div><div> the rate (7.5 msec interval)? </div><div><br></div><div>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).<br></div><div> or the rate and bytes at which PA writes to SCO socket is irrespective of the codec selected ?</div><div><br></div><div>Thanks in advance . please correct me if i am wrong</div><div><br></div><div>Regards,</div><div>Ajay kv.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 6, 2018 at 5:43 PM, Tanu Kaskinen <span dir="ltr"><<a href="mailto:tanuk@iki.fi" target="_blank">tanuk@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, 2018-04-02 at 14:56 +0530, Sathish Narasimman wrote:<br> > On Tue, Mar 27, 2018 at 3:32 PM, Luiz Augusto von Dentz <<br> > <a href="mailto:luiz.dentz@gmail.com">luiz.dentz@gmail.com</a>> wrote:<br> ><br> > > Hi Sathish,<br> > ><br> > > On Tue, Mar 27, 2018 at 9:39 AM, Sathish Narasimman<br> > > <<a href="mailto:nsathish41@gmail.com">nsathish41@gmail.com</a>> wrote:<br> > > > Hi Tanu,<br> > > ><br> > > ><br> > > > On Sat, Mar 17, 2018 at 1:26 AM, Tanu Kaskinen <<a href="mailto:tanuk@iki.fi">tanuk@iki.fi</a>> wrote:<br> > > > ><br> > > > > On Thu, 2018-03-15 at 14:49 +0530, Sathish Narasimman wrote:<br> > > > > > Hi,<br> > > > > ><br> > > > > > I would like to know the PulseAudio module that is responsible for<br> > > > > > pushing<br> > > > > > the audio for every 1 millisecond.<br> > > > > ><br> > > > > > For NBS the packets are pushed with 48bytes and 1milli sec interval.<br> > > > ><br> > > > > Where does this 1 ms interval come from? The audio that pulseaudio<br> > > > > writes with SCO is mono, 16-bit, 8000 Hz. With that specification 48<br> > > > > bytes means 3 ms packets, not 1 ms.<br> > > > ><br> > > > > > But for WBS the timing between 2 SCO packets needs to be *7.5 Milli<br> > > > > > Sec.*<br> > > > > ><br> > > > > > *May I know how to change the packet interval between the 2 SCO<br> > > > > > packets.*<br> > > > ><br> > > > > The write_block_size variable in src/modules/bluetooth/module-<wbr>bluez5-<br> > > > > device.c controls how big packets pulseaudio writes. That in turn is<br> > > > > calculated based on write_link_mtu, and that comes from the transport<br> > > > > acquire() callback. The ofono backend always returns 48 bytes. The<br> > > > > native backend returns 48 bytes by default, but it can also be<br> > > > > configured to ask the kernel what the real MTU is.<br> > > > ><br> > > ><br> > > > I am able to set the MTU to 60 bytes in the and able to make the SCO<br> > > > connection.<br> > > > But still, the data rate is maintained as 1 msec.<br> > > ><br> > > > Do we need to introduce any latency in the PA?<br> > > > As per core spec 5 , Vol 4 Part B of USB transaction the HCI packet<br> > ><br> > > interval<br> > > > need to be 7.5msec.<br> > > > Do we need to maintain the rate in PA?<br> > ><br> > > I suspect something in btusb.c might be the problem:<br> > ><br> > > <a href="https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bl" rel="noreferrer" target="_blank">https://git.kernel.org/pub/<wbr>scm/linux/kernel/git/<wbr>bluetooth/bl</a><br> > > uetooth-next.git/tree/drivers/<wbr>bluetooth/btusb.c#n1272<br> > ><br> > > Either the interval of endpoint is wrong or we shouldn't set the ASAP<br> > > flag since that might ignore the interval completely.<br> > ><br> > ><br> ><br> > bInterval is the USB polling interval which should be 1msec.<br> > It is HCI packet interval that needs to be 7.5msec.<br> ><br> > Based on the bInterval the polling happens in the USB driver for every 1<br> > msec.<br> > As per present implementation the HCI packet of 63bytes is transfered every<br> > 1msec.<br> > Also, I disabled the ASAP flag but it doesn't help to maintain the ALT 6<br> > HCI packet interval of 7.5msec.<br> ><br> > It looks like the from PA we need to maintain the time interval for WBS.<br> > Please help in the right direction to proceed futher.<br> <br> </div></div>How have you measured the 1 ms interval? As I explained earlier,<br> PulseAudio writes 48 bytes at a time, and that corresponds to 3 ms of<br> audio with narrowband audio: there's one channel, each sample takes 2<br> bytes, and the sample rate is 8000 Hz.<br> 48 bytes / 1 / 2 bytes / 8000 Hz = 3 ms<br> <br> The SCO write timing in PulseAudio is actually driven by the microphone<br> input: when PulseAudio gets data from the microphone, it will<br> immediately write a corresponding amount of audio back.<br> <br> The wideband audio is encoded in mSBC, right? Does every mSBC packet<br> carry the same amount of audio (in PCM samples)? Are the packets<br> themselves always the same size?<br> <div class="HOEnZb"><div class="h5"><br> --<br> Tanu<br> <br> <a href="https://liberapay.com/tanuk" rel="noreferrer" target="_blank">https://liberapay.com/tanuk</a><br> <a href="https://www.patreon.com/tanuk" rel="noreferrer" target="_blank">https://www.patreon.com/tanuk</a><br> </div></div></blockquote></div><br></div>