On Mon, 2018-04-02 at 14:56 +0530, Sathish Narasimman wrote: > On Tue, Mar 27, 2018 at 3:32 PM, Luiz Augusto von Dentz < > luiz.dentz at gmail.com> wrote: > > > Hi Sathish, > > > > On Tue, Mar 27, 2018 at 9:39 AM, Sathish Narasimman > > <nsathish41 at gmail.com> wrote: > > > Hi Tanu, > > > > > > > > > On Sat, Mar 17, 2018 at 1:26 AM, Tanu Kaskinen <tanuk at iki.fi> wrote: > > > > > > > > On Thu, 2018-03-15 at 14:49 +0530, Sathish Narasimman wrote: > > > > > Hi, > > > > > > > > > > I would like to know the PulseAudio module that is responsible for > > > > > pushing > > > > > the audio for every 1 millisecond. > > > > > > > > > > For NBS the packets are pushed with 48bytes and 1milli sec interval. > > > > > > > > Where does this 1 ms interval come from? The audio that pulseaudio > > > > writes with SCO is mono, 16-bit, 8000 Hz. With that specification 48 > > > > bytes means 3 ms packets, not 1 ms. > > > > > > > > > But for WBS the timing between 2 SCO packets needs to be *7.5 Milli > > > > > Sec.* > > > > > > > > > > *May I know how to change the packet interval between the 2 SCO > > > > > packets.* > > > > > > > > The write_block_size variable in src/modules/bluetooth/module-bluez5- > > > > device.c controls how big packets pulseaudio writes. That in turn is > > > > calculated based on write_link_mtu, and that comes from the transport > > > > acquire() callback. The ofono backend always returns 48 bytes. The > > > > native backend returns 48 bytes by default, but it can also be > > > > configured to ask the kernel what the real MTU is. > > > > > > > > > > I am able to set the MTU to 60 bytes in the and able to make the SCO > > > connection. > > > But still, the data rate is maintained as 1 msec. > > > > > > Do we need to introduce any latency in the PA? > > > As per core spec 5 , Vol 4 Part B of USB transaction the HCI packet > > > > interval > > > need to be 7.5msec. > > > Do we need to maintain the rate in PA? > > > > I suspect something in btusb.c might be the problem: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bl > > uetooth-next.git/tree/drivers/bluetooth/btusb.c#n1272 > > > > Either the interval of endpoint is wrong or we shouldn't set the ASAP > > flag since that might ignore the interval completely. > > > > > > bInterval is the USB polling interval which should be 1msec. > It is HCI packet interval that needs to be 7.5msec. > > Based on the bInterval the polling happens in the USB driver for every 1 > msec. > As per present implementation the HCI packet of 63bytes is transfered every > 1msec. > Also, I disabled the ASAP flag but it doesn't help to maintain the ALT 6 > HCI packet interval of 7.5msec. > > It looks like the from PA we need to maintain the time interval for WBS. > Please help in the right direction to proceed futher. How have you measured the 1 ms interval? As I explained earlier, PulseAudio writes 48 bytes at a time, and that corresponds to 3 ms of audio with narrowband audio: there's one channel, each sample takes 2 bytes, and the sample rate is 8000 Hz. 48 bytes / 1 / 2 bytes / 8000 Hz = 3 ms The SCO write timing in PulseAudio is actually driven by the microphone input: when PulseAudio gets data from the microphone, it will immediately write a corresponding amount of audio back. The wideband audio is encoded in mSBC, right? Does every mSBC packet carry the same amount of audio (in PCM samples)? Are the packets themselves always the same size? -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk
