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)?
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)?
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 ?
Thanks in advance . please correct me if i am wrong
Regards,
Ajay kv.
On Fri, Apr 6, 2018 at 5:43 PM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20180406/fa4a5bce/attachment-0001.html>
