<div dir="ltr">Hi James,<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Aug 20, 2018 at 8:19 PM James Bottomley <<a href="mailto:James.Bottomley@hansenpartnership.com">James.Bottomley@hansenpartnership.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 2018-08-20 at 19:19 +0530, Sathish Narasimman wrote:<br>
> From: Sathish Narasimman <<a href="mailto:sathish.narasimman@intel.com" target="_blank">sathish.narasimman@intel.com</a>><br>
> <br>
> mSBC-encoded streams for HFP. The Wide Band Speech(WBS) encoding and<br>
> decoding<br>
> is implemeted with this patch. This patch was refered from original<br>
> patch of Joao Paula Rechi Vita and was verified with the supported<br>
> bluetooth controller.<br>
<br>
Which headset did you test this with? When I try it with an LG 900 I<br>
get a huge amount of chop which shreds the audio quality. For this<br>
headset the packet size (MTU) still needs to be set at 48 on both the<br>
send and receive side otherwise the audio doesn't work at all.<br></blockquote><div>I used Jabra EasyGo GNM-OTE4 bluetooth headset.<br></div><div>This patch is refered w.r.t to USB transport.</div><div>For USB transport - As per core spec 5, vol 4, Part B Table 2.1(this was the only reference in core spec for USB transport- please correct me if i am wrong)</div><div>for msbc voice channel it should be 63bytes along with Usb header. So the host</div><div>should send 60 bytes of msbc audio.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What seems to be happening is that the LG insists on running the eSCO<br>
links at full speed but the encoded packets only take about half the<br>
bandwidth, so on the headset receiving side, we get about half as many<br>
mSBC encoded packets with the rest being zero padded.<br>
<br>
The problem occurs because on the receive side you count mSBC packets,<br>
so the reader/writer thread you try to send 1 mSBC encoded packet for<br>
every 1 mSBC packet you receive.<br>
<br>
But in this send loop:<br>
<br>
> + /* Send MTU bytes of it, if there is more it will send later<br>
> */<br>
> + while (u->msbc_info.ebuffer_start + u->write_link_mtu <= u-<br>
> >msbc_info.ebuffer_end) {<br>
> + l = pa_write(u->stream_fd,<br>
> + u->msbc_info.ebuffer + u-<br>
> >msbc_info.ebuffer_start,<br>
> + u->write_link_mtu,<br>
> + &u->stream_write_type);<br>
> +<br>
> + wrote = true;<br>
> + if (l <= 0) {<br>
> + pa_log_debug("Error while writing: l %d, errno %d",<br>
> l, errno);<br>
> + break;<br>
> + }<br>
> +<br>
> + u->msbc_info.ebuffer_start += l;<br>
> + if (u->msbc_info.ebuffer_start >= u-<br>
> >msbc_info.ebuffer_end)<br>
> + u->msbc_info.ebuffer_start = u-<br>
> >msbc_info.ebuffer_end = 0;<br>
> + }<br>
> +<br>
> + pa_memblock_release(u->write_memchunk.memblock);<br>
> +<br>
> + if (wrote && l < 0) {<br>
> +<br>
> + if (errno == EINTR)<br>
> + /* Retry right away if we got interrupted */<br>
> + continue;<br>
> +<br>
> + else if (errno == EAGAIN)<br>
> + /* Hmm, apparently the socket was not writable, give<br>
> up for now */<br>
> + break;<br>
> +<br>
> + pa_log_error("Failed to write data to SCO socket: %s",<br>
> pa_cstrerror(errno));<br>
> + ret = -1;<br>
> + break;<br>
> + }<br>
> +<br>
> + if ((size_t) l != (size_t)u->write_link_mtu) {<br>
> + pa_log_error("Wrote memory block to socket only<br>
> partially! %llu written, wanted to write %llu.",<br>
> + (unsigned long long) l,<br>
> + (unsigned long long) u->write_link_mtu);<br>
> + ret = -1;<br>
> + break;<br>
> + }<br>
> +<br>
> + u->write_index += (uint64_t) u->write_memchunk.length;<br>
> +<br>
> + pa_memblock_unref(u->write_memchunk.memblock);<br>
> + pa_memchunk_reset(&u->write_memchunk);<br>
> +<br>
> + ret = 1;<br>
> + break;<br>
> + }<br>
<br>
Because the mtu is 48 and the mSBC encode size is 60, the transmission<br>
stops after 48 bytes, we now wait for a new mSBC packet to be received,<br>
so we miss the next eSCO transmission window and the headset fills in<br>
with zeros causing the packet to be chopped and the next one to be<br>
discarded as invalid.<br>
<br>
I suspect the only way to get mSBC to work for this type of headset is<br>
to count actual received packets, always to transmit full 60 byte mSBC<br>
packets in adjacent frames and to pad with zeros if we're not ready.<br></blockquote><div>I tried to get the MTU negotiation from the kernel.</div><div>Though getsockopt was not implemented to provide the required MTU from the BT kernel.</div><div>I tried to implement that part to get the right MTU from the BT kernel.</div><div>But the problem here is, the USB transport gets the right MTU from ALT setting.</div><div>which happens after the successfull sco connection(exactly during accept connection or sco_accept).</div><div>So during hf_audio_agent_transport_acquire call we are unable to get the right MTU at this function in backend-ofono.c file.</div><div>This is the reason i had planned to hard code it for now. This patch is purely verified with USB transport</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
James<br>
<br>
_______________________________________________<br>
pulseaudio-discuss mailing list<br>
<a href="mailto:pulseaudio-discuss@lists.freedesktop.org" target="_blank">pulseaudio-discuss@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss</a></blockquote><div><br></div><div>Thansk,</div><div>Sathish N </div></div></div>