Re: [pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
On Tue, 2018-04-10 at 16:10 +0300, Luiz Augusto von Dentz wrote: > 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. Sounds like a thing that the kernel should take care of. As I've been saying, I haven't seen evidence that PulseAudio should be very concerned about the packet timing. > 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. The bluetooth code ignores default-fragment-size-msec, because PulseAudio can't configure arbitrary hardware buffer sizes with bluez like it can with alsa (and even alsa usually ignores that setting, because it's better to adapt the hardware buffer size to client latency requests when possible). -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
Hi Tanu Ajay, On Sat, Apr 7, 2018 at 5:26 PM, Tanu Kaskinen 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
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. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
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 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.de...@gmail.com> wrote: > > > > > Hi Sathish, > > > > > > On Tue, Mar 27, 2018 at 9:39 AM, Sathish Narasimman > > > wrote: > > > > Hi Tanu, > > > > > > > > > > > > On Sat, Mar 17, 2018 at 1:26 AM, Tanu Kaskinen 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 correspondin
Re: [pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
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.de...@gmail.com> wrote: > > > Hi Sathish, > > > > On Tue, Mar 27, 2018 at 9:39 AM, Sathish Narasimman > > wrote: > > > Hi Tanu, > > > > > > > > > On Sat, Mar 17, 2018 at 1:26 AM, Tanu Kaskinen 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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
On Tue, Mar 27, 2018 at 3:32 PM, Luiz Augusto von Dentz < luiz.de...@gmail.com> wrote: > Hi Sathish, > > On Tue, Mar 27, 2018 at 9:39 AM, Sathish Narasimman > wrote: > > Hi Tanu, > > > > > > On Sat, Mar 17, 2018 at 1:26 AM, Tanu Kaskinen 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. > >> > >> -- > >> Tanu > >> > >> https://liberapay.com/tanuk > >> https://www.patreon.com/tanuk > >> ___ > >> pulseaudio-discuss mailing list > >> pulseaudio-discuss@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > > > > > ___ > > pulseaudio-discuss mailing list > > pulseaudio-discuss@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > > > -- > Luiz Augusto von Dentz > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
Hi Sathish, On Tue, Mar 27, 2018 at 9:39 AM, Sathish Narasimman wrote: > Hi Tanu, > > > On Sat, Mar 17, 2018 at 1:26 AM, Tanu Kaskinen 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/bluetooth-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. >> >> -- >> Tanu >> >> https://liberapay.com/tanuk >> https://www.patreon.com/tanuk >> ___ >> pulseaudio-discuss mailing list >> pulseaudio-discuss@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > > > > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > -- Luiz Augusto von Dentz ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
Hi Tanu, On Sat, Mar 17, 2018 at 1:26 AM, Tanu Kaskinen 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? > -- > Tanu > > https://liberapay.com/tanuk > https://www.patreon.com/tanuk > ___ > pulseaudio-discuss mailing list > pulseaudio-discuss@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss > ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Timing interval for Bluetooth Wideband speech
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. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
