[Bug]: cannot setup realtime integration for WMATA

Own Analysis

[X] I cannot find my issue in the documentation

A clear and concise description of what the bug is.
I cannot setup realtime integration because more than 15 stops are found for my zone, even with a radius of 50.

How can I resolve this so I can get realtime train updates?

Provide details on the data source(s)
I just setup the integration with this endpoint

https://api.wmata.com/gtfs/rail-bus-gtfs-static.zip

Config in case of setup using start / stop station
No response
Config in case of setup using location based departures
Lat 38.880826296077004
Long -76.98508772924833

Info on your installed version
Latest hacs on haos
Relevant log output
No response

Not hoped for but .. I was awaintg this at-some-point. The reason to limit is performance related and I just took 15 as 'a' number to limit it. What you can do is change config/custom_components/gtfs2/const.py DEFAULT_MAX_LOCAL_STOPS = 15 and restart HA. The only downside is that with each upgrade (or re-install) of gtfs2 you would need to redo this to setup new stops, I believe it will continue to run but not work for new configurations.

The regular alternative is to introduce multiple local stops but I assume that in this case that would not work as they would all cover the same location

https://github.com/vingerha/gtfs2/wiki/2c.-Acquire-local-stops-&-departures

Got it, ya I'm not too too worried about performance in this case, running on more than a pi :)
I tried to add real time trip updates to a local stop with this endpoint
https://api.wmata.com/gtfs/rail-gtfsrt-tripupdates.pb
Both with and without the protobuf header it results in the senor being unavailable with a red exclamation mark.
Any thoughts? Or I can provide whatever logs may be helpful

Logs?

@vingerha I have this reproduced for two of my providers, but without dox'ing myself can you send me an email so I can send you these privately<EMAIL_ADDRESS>

Please check logs for errors/warnings, I cannot test each individual provider / user / stop as you can understand. I tested wmata in Feb and it worked then

It's not all that valuable information for me to understand, but here are the only errors I get, basically.
WMata works for Specified Stops, but the vicinity-based multi-stop breaks when RealTime is added; it works fine without real time.
2024-11-08 08:59:34.208 DEBUG (MainThread) [custom_components.gtfs2.coordinator] Finished fetching c422ff9d317b87332c8e45da3631fd4a data in 0.314 seconds (success: False)
2024-11-08 08:59:34.208 ERROR (MainThread) [homeassistant.helpers.entity_platform] gtfs2 raises exception ConfigEntryNotReady in forwarded platform sensor; Instead raise ConfigEntryNotReady before calling async_forward_entry_setups

The config not ready is not a good sign, which version are you using?

0.5.4 on 2024.11.0

ok and you use the stop with above lat/lon ?

I am updating the static now and tested realtime so I have access but need your stop detail

error replicated... not sure yet what it is but will try to fix over the w/e

Glad you were able to recreate it. I couldn't figure it out either was racking my brain, best I could think it something is falling out of an async process.
Feel free to @ me if you have anything you want me to test.

I have it working (again), some thing I overlooked when setting up the service call where I missed adding 'headers'
Anyhow, the thing is...it is working wihtout errors but it is not providing any realtime-results and to analyse this is too much for me as it is often a data-provider issue which takes a lot of (unpaid) time.
My proposal is that you use the service/action to generate the realtime pb and refer to that file from the configured local stop (http://...ip-address:8123/local/gtfs2/filename.pb) . When you setup the action, you can select debug_output to have a readable output, this may help identify if your stops are actually represented in the realtime data.
https://github.com/vingerha/gtfs2/wiki/4.-Service-call

In the meantime I discovered why it likely won't work as I am in a different timezone as the wmata agency TZ. Changing TZ is only possible via restarts so will see when I have more motivation. What I did notice is that a setup of 200m around your lat/lon gives 9 stops and when I add realtime, my instance seems to turn inaccessible over time, which I believe to put with the high amount of checks it has to perform.

New update, it works (sort off) with setting the TZ to NY, but I need a bit more time as it does not align well (5h diff) but this may be related to the real TZ I am in (CET)...zooming in, likely publishing new release by tomorrow

You have a dev branch you are working from? I can test and provide more debug output.

I will create a DEV release in the next 10 mins, is easier

By the way, the test of pointing to the scheduled RT also worked, but I'll let you know if the header issue is fixed in the release. Thanks for all the help on this.

I still need to test if it works for regular trips with start and end station... it takes a lot of time but as long as I am fixing bugs it is ok

It's not WMATA but one of my other data sources. I'm not sure why, on one side, it has the key, but the other doesn't. I recreated these stops just to confirm.
RTA-Home-Bus_localstop.rt contains the Error
{"errorCode":401,"errorMessage":"Missing Authorization Header"}
This same feed works fine when manually triggering via service as well as via the specified stop.
2024-11-12 12:10:29.576 DEBUG (SyncWorker_60) [custom_components.gtfs2.gtfs_helper] self rt_data: {'url': 'https://api.goswift.ly/real-time/rtamaryland/gtfs-rt-trip-updates', 'api_key': None, 'api_key_name': 'Authorization', 'api_key_location': 'header', 'accept': None, 'file': 'RTA-Home-Bus_localstop'}, self headers: {'Authorization': '5622XXXXXcf', 'api_key_location': 'header', 'api_key_name': 'Authorization', 'Accept': 'application/x-protobuf'}, self data: {'schedule': <pygtfs.schedule.Schedule object at 0x7fe54ded4230>, 'include_tomorrow': True, 'gtfs_dir': 'gtfs2', 'name': 'RTA-Home-Bus', 'file': 'RTAMaryland', 'offset': 0, 'timerange': 30, 'radius': 1000, 'device_tracker_id': 'zone.home', 'extracting': False, 'gtfs_updated_at': '2024-11-12T17:10:29.568361+00:00'}
2024-11-12 12:10:29.576 DEBUG (SyncWorker_60) [custom_components.gtfs2.gtfs_rt_helper] Getting gtfs rt locally with data: {'url': 'https://api.goswift.ly/real-time/rtamaryland/gtfs-rt-trip-updates', 'api_key': None, 'api_key_name': 'Authorization', 'api_key_location': 'header', 'accept': None, 'file': 'RTA-Home-Bus_localstop'}
2024-11-12 12:10:29.576 DEBUG (SyncWorker_60) [custom_components.gtfs2.gtfs_rt_helper] Getting gtfs rt locally with headers: {'Authorization': None}

Please send me a screenshot of the service call that works, hide the key of course

I see the issue... api_key has already been renamed in headers to the CONF_API_KEY_NAME
            CONF_API_KEY : self._headers.get(CONF_API_KEY,None),
            CONF_API_KEY_NAME : self._headers.get(CONF_API_KEY_NAME, None),

it should be, unless you change the upstream of _headers source
            CONF_API_KEY : self._headers.get(self._headers.get(CONF_API_KEY_NAME, None),None),
            CONF_API_KEY_NAME : self._headers.get(CONF_API_KEY_NAME, None),

Did you install the new release? I have the impression that you did not as the logging changed

And with me it shows fine

Yeah, the easy way to verify is use any feed that doesn't use api_key as the key name. This is why WMATA works fine for me now but my RTA Transit doesn't because swifty uses Authorization instead.

I have no idea right now, as I donot have the key it crashes on the file but I do see that the key_name is properly used at the beginning of the code... will test more

tomorrow...day is at an end for me :)

Have a great night... here is my recommended fix.
custom_components/gtfs2/gtfs_helper.py :991
-            CONF_API_KEY : self._headers.get(CONF_API_KEY,None),
+           CONF_API_KEY : self._headers.get(self._headers.get(CONF_API_KEY_NAME, None),None),

2024-11-12 12:51:17.187 DEBUG (SyncWorker_42) [custom_components.gtfs2.gtfs_helper] self rt_data: {'url': 'https://api.goswift.ly/real-time/rtamaryland/gtfs-rt-trip-updates', 'api_key': '56229404c46187ecc0b71e060516eacf', 'api_key_name': 'Authorization', 'api_key_location': 'header', 'accept': None, 'file': 'RTA-Home-Bus_localstop'}, self headers: {'Authorization': '562xxxxxxeacf', 'api_key_location': 'header', 'api_key_name': 'Authorization', 'Accept': 'application/x-protobuf'}, self data: {'schedule': <pygtfs.schedule.Schedule object at 0x7f1444ddfb60>, 'include_tomorrow': True, 'gtfs_dir': 'gtfs2', 'name': 'RTA-Home-Bus', 'file': 'RTAMaryland', 'offset': 0, 'timerange': 30, 'radius': 1000, 'device_tracker_id': 'zone.home', 'extracting': False, 'gtfs_updated_at': '2024-11-12T17:51:17.171603+00:00'}
2024-11-12 12:51:17.187 DEBUG (SyncWorker_42) [custom_components.gtfs2.gtfs_rt_helper] Getting gtfs rt locally with data: {'url': 'https://api.goswift.ly/real-time/rtamaryland/gtfs-rt-trip-updates', 'api_key': '5622xxxxxxxxeacf', 'api_key_name': 'Authorization', 'api_key_location': 'header', 'accept': None, 'file': 'RTA-Home-Bus_localstop'}
2024-11-12 12:51:17.187 DEBUG (SyncWorker_42) [custom_components.gtfs2.gtfs_rt_helper] Getting gtfs rt locally with headers: {'Authorization': '5622XXXXXXacf'}

Here is a breakdown of the issue.
api_key is not passed in the _headers as it is already written out as the value of api_key in my example api_key = Authorization
In the data below I have bolded the areas that are the issue. If the values of API_KEY and API_KEY_NAME are stored elsewhere, then probably better than reading from the formatted self._headers
2024-11-12 12:10:29.576 DEBUG (SyncWorker_60) [custom_components.gtfs2.gtfs_helper]
self rt_data: {'url': 'https://api.goswift.ly/real-time/rtamaryland/gtfs-rt-trip-updates', 'api_key': None, 'api_key_name': 'Authorization', 'api_key_location': 'header', 'accept': None, 'file': 'RTA-Home-Bus_localstop'},
self headers: {'Authorization': '5622XXXXXcf', 'api_key_location': 'header', 'api_key_name': 'Authorization', 'Accept': 'application/x-protobuf'},
self data: {'schedule': <pygtfs.schedule.Schedule object at 0x7fe54ded4230>, 'include_tomorrow': True, 'gtfs_dir': 'gtfs2', 'name': 'RTA-Home-Bus', 'file': 'RTAMaryland', 'offset': 0, 'timerange': 30, 'radius': 1000, 'device_tracker_id': 'zone.home', 'extracting': False, 'gtfs_updated_at': '2024-11-12T17:10:29.568361+00:00'}

@vingerha thanks, from one unpaid dev to another. Feel free to let me know if you have any updates and I'll test. Pretty good at QA work and breaking things ;)

Will try to re-release later this afternoon, after work...and one cannot learn (much) without breaking things :)

Tested it with wmata local stops and start<>end, did the same for my local provider so covered different TZ. I could not test goswift as not sure where to register for API (and ... too lazy too :) )

Working great for both my data feeds!
Thanks for all your work on this project!

Thx, closing this topic now. I will need to do some drastic debug-log clean up now :)


fix: cannot find module 'tslint'

In case tslint is not installed one would get the following error Cannot find module 'tslint'
This is due tslint is not a direct dependency of typescript-formatter

sorry for late!
I have a question. Why don't you use --no-tslint options?
If we want to use tslint but can not find it, it seems that it is more correct to get an error.

didn't know about that option. Sounds reasonable thanks


Update Swift tutorial

Docs Build status updates of commit 2171467:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

tutorials/ios-swift.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 2171467:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

.openpublishing.publish.config.json
:white_check_mark:Succeeded

tutorials/ios-swift.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Community: add more project roles member/reviewer/approver/maintainer

Description:
In order to lower the threshold for becoming a maintainer, we may need to consider adding more roles in the community, so that contributors can have a staged feedback for their contributions, and get promoted in the community through more efforts:

member
reviewer
approver
maintainer(admin)
steering committee

This requires more teams in envoyproxy:

gateway-steering-committee
gateway-maintainers
gateway-reviewers
gateway-members

# OWNER

leads:
  - gateway-steering-committee

approvers:
  - gateway-maintainers

reviewers:
  - gateway-maintainers
  - gateway-reviewers

members:
  - gateway-maintainers
  - gateway-reviewers
  - gateway-members

cc @envoyproxy/gateway-maintainers

What is the difference between a member and any other person, do they get some kind of permission that any given GitHub user wouldn't have other than us formally recognizing their efforts?
And am I correct in understanding that reviewer exists separately from approver so that whenever someone opens a PR both reviewers and approvers get automatically tagged for a review, but that only approvals from approvers give the PR author merge permissions?

1 to adding a reviewer group who

get atomically tagged for a review
their approval counts towards minimum review count criteria (of 2)

Hey @AliceProxy, sorry for the late reply.

What is the difference between a member and any other person, do they get some kind of permission that any given GitHub user wouldn't have other than us formally recognizing their efforts?

And am I correct in understanding that reviewer exists separately from approver so that whenever someone opens a PR both reviewers and approvers get automatically tagged for a review, but that only approvals from approvers give the PR author merge permissions?

I have updated the issues and simplied the roles with 3 kinds:

Reviewer: In group of gateway-reviewers. We should know that the reviewer role has not write access to the project. They are the active contributors in community who are willing to help maintainers review PRs, and can /lgtm a PR.
Maintainer: In group of gateway-maintainers. The maintainers have write access to the project. They can /approve a PR. Once a PR has /lgtm and /approve, the PR can be merged.
Steering-Committee: In group of gateway-steering-committee, they are in charge of https://github.com/envoyproxy/gateway/blob/main/GOVERNANCE.md.

Also could you elaborate on the permissions of the steering committee group? 🙂

We already have a team https://github.com/orgs/envoyproxy/teams/gateway-steering-committee based on https://github.com/envoyproxy/gateway/blob/main/GOVERNANCE.md. For now, this does not give permissions yet, just a kind of like a group for steering-committee member.

@Xunzhuo can we close this issue ?

@arkodg sure


Provide mechanism to retrieve DSN from configuration

We run Sentry against a few Rails applications. It would be nice if there was a helper method on Raven::Configuration that would allow retrieval of the set DSN so we can use it when setting up the frontend reporter.
Right now we can grab Raven.configuration.release and render it in the view but have to reconstruct the URL (or copy over from our config). My proposal would mean that instead of
Raven.config('url reconstruction / copy from config}', {
          release: "#{Raven.configuration.release}"
        }).install()

you could have something a bit more standard like
Raven.config('Raven.configuration.dsn}', {
          release: "#{Raven.configuration.release}"
        }).install()

Would love to see this implemented. My use case is setting up JS client for frontend error reporting as well.
Currently fetching ENV['SENTRY_DSN'] value. That works, but will silently break frontend error reporting, if that particular ENV variable is no longer used.

sorry for the long waiting, I've added https://github.com/getsentry/raven-ruby/pull/1012 for this


Trial expire info for trial plans only

Description
For testing purposes we showed trial expiration info only when feature flag was enabled and when particular subaccount id was used.
Information should be shown for all trial plans if feature flag is enabled.
Changes proposed in this pull request:

Condition changed

Related issue(s)
https://github.tools.sap/kyma/backlog/issues/2730

/retest all

/test all


Fix the issue with concurrent modification for segment lineage

There has been a minor bug with the segment lineage where we
iterate the lineage entries using .keySet() and we call
map.remove() to delete the entry. This causes to throw
ConcurrentModificationException and this pr addresses the issue.

Codecov Report

Merging #7343 (056dc12) into master (aa5f318) will decrease coverage by 2.28%.
The diff coverage is 100.00%.

@@             Coverage Diff              @@
##             master    #7343      +/-   ##
============================================
- Coverage     71.58%   69.29%   -2.29%
+ Complexity     3371     3195     -176
============================================
  Files          1504     1110     -394
  Lines         74304    52268   -22036
  Branches      10799     7860    -2939
============================================
- Hits          53189    36221   -16968
+ Misses        17499    13450    -4049
+ Partials       3616     2597    -1019

Flag
Coverage Δ

integration1
?

integration2
?

unittests1
69.29% <100.00%> (-0.04%)
:arrow_down:

unittests2
?

Flags with carried forward coverage won't be shown. Click here to find out more.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update aa5f318...056dc12. Read the comment docs.

LGTM


vscode self Markdown Preview not working

VSCode Version:
OS Version:

Steps to Reproduce:

when i update to version 1.43.2，the markdown preview of vscode not working.  and in setting.json, the markdown support are also not support;

I must installed Markdown Preview Enhanced plugins, the preview can work what can i do if i want to use the vscode self preview

Does this issue occur when all extensions are disabled?: Yes/No

Can you please try searching @builtin markdown in the extension view and seeing if the Markdown Language Features extension is enabled

I have the same problem

Can you please try searching @builtin markdown in the extension view and seeing if the Markdown Language Features extension is enabled

it's working... thanks

I have the same problem

i fixed follow the last reply


add Arabic language and RTL support

Describe the Feature
Key Features:

Arabic Translation:

Introduce Arabic localization using the Lingui tool, creating an ar catalog with Arabic translations for the app's strings.
Follow the documented workflow for wrapping strings in Trans and using yarn intl:extract to generate catalogs.

RTL Layout Support:

Automatically enable RTL layout when an RTL language (like Arabic) is selected.
Adjust UI components, such as text alignment, icons, navigation menus, and other visual elements, to fit RTL standards.

Testing:

Verify that the app works seamlessly with Arabic language and RTL layout.
Ensure proper display of text and user interaction in all components.

Attachments
Here are some examples of RTL layout implementations in other apps, demonstrating how text alignment, navigation, and UI components adapt for RTL:

Describe Alternatives
No response
Additional Context

As a native Arabic speaker, I am willing to assist with translation and testing.
Arabic support would significantly expand the app’s user base and improve inclusivity, reflecting Bluesky's commitment to accessibility.
Resources such as Lingui's documentation (https://lingui.dev/) and React Native's RTL guide (https://reactnative.dev/docs/rtl) can be helpful for implementation.

ترجمته ولا باقي؟ إذا للحين، أقدر أساعدك في التدقيق والترجمة


rpmsg socket related update

Summary
rpmsg_socket: connect addrlen can bigger then expect
socket_rpmsg: set poll err instead return err
rpmsg_socket: defalut set POLLERR POLLHUP to events
rpmsg_socket: use sendto_nocopy() instead of send_nocopy()
Impact
rpmsg socket
Testing
VELA

@pkarashchenko look like the ci overload.


[Improvement] Transforms.java is missing private constructor

What would you like to be improved?
Utility classes should have private constructors
How should we improve?
Add a private constructor.

Hi @justinmclean can I help with this one ?

Sure, if you have any issues, just ask for help.

I've seen multiple issues missing private constructor, can you also assign it to me and I can update it to one PR ? Cheers

There is no need to wait for an issue to be assigned to you. Just add a comment you are working on and raise a PR.


[WIP] Create a JSON RPC API for threshold-BLS signing & add the Randomness Move module

Implementation of TBlsSignatureApi and the Move side according to the HLD. Currently computes everything locally, without calling f+1 validators.

@damirka, this is the implementation of the Randomness object we discussed awhile ago. Would appreciate your review of the move related files.
@bmwill, updated the PR after some changes I've done in fastcrypto that blocked this change. I'm planning to fix the TODO on verifying the effects cert in a follow up PR.


How to combine two cols to one

I like to get a table structure like this, but I don't see a possibility in the code to do this since there is no colspan prop. Do you think its possible to implement that? With some hints I could like to create a PR.
Or do you have a better idea?

        First Name
        Last Name
        Action

            John
            Lennon

                <button>Edit</button>

                <button>Delete</button>

Hi, we currently don't support spans. I don't think we want to either for now, as it would add a lot of complexity. I'll look into this the next major version though!


Using test endpoint generated certificates. Why?

Hi,
I thought I was using the test endpoint, but after executing letsencrypt_webfaction I can see a certificate for this particular domain when I go to the SSL Certificates page in the Webfaction control panel. Why did this happen when I was using the test endpoing?
Have I misunderstood something?
Robin
The command I ran:
letsencrypt_webfaction --config ~/le_config.yml --domains example.co.uk,www.example.co.uk --public ~/webapps/example/
This is my le_config.yml:
key_size: 4096
# We need an ACME server to talk to, see github.com/letsencrypt/boulder
endpoint: 'https://acme-v01.api.letsencrypt.org/'
#domains: []
#public: ''
output_dir: '~/le_certs/'
letsencrypt_account_email<EMAIL_ADDRESS>api_url: 'https://api.webfaction.com/'
username: 'myusername'
password: 'mypassword'
servername: ''
cert_name: ''

The test endpoint issues certificates from Let's Encrypt's test root certificate. It will install it in the WebFaction admin interface so that you can test it if you want.
When it works, you can re-run the command without the test endpoint and it will overwrite the test certificate.

OK, that makes complete sense. Thank you.


[example] core_automation_events not working properly on Web

This is a difficult to track issue, I've been investigating it for several hours.
It seems the recording works as expected but the replay does not.
First approach was to the timming system, considering the asynchronous execution on Web, I tried refactoring code to avoid ASYNCIFY (core_automation_events_web.c.md) but it does not seem to be the issue. Also considering that events recording and playing is frames-based. The jump physics on the example confused me but trying just a simple right-left movement also fails.
Investigating a bit further, I noticed there was not call in rcore_web for glfwPollEvents(), that call on rcore_desktop is the one in charge of launching the callbacks that read the inputs. In web it seems is not needed because probably the input reading is also asynchronous, managed by the browser.
As there are no callbacks involved in the automation events process, the key states do not seem to be properly reseted (key_up event) and they are just fixed and played forever, that's my guess.
Thinking about possible approaches to this issue, maybe a separate keys reseting mechanism on automation events playing for web?
Help with this issue is really welcome!

@ubkp Hi! As you were helping a lot lately with web platform, maybe you could take a look to this issue?

@raysan5 Sure thing! I'll review it :+1:

It seems the recording works as expected but the replay does not.

@raysan5 I believe it's the opposite. On my tests here the problem appears to be the recording on PLATFORM_WEB. It's indeed not recording the INPUT_KEY_UP events, thus the generated "automation events" on PLATFORM_WEB don't match the input and end up "malfunctioning" and stuck on the last INPUT_KEY_DOWN.
If you generate a valid automation.rae (e.g.: from a core_automation_events.c compiled for PLATFORM_DESKTOP) and file drop it on the browser's tab running core_automation_events.html compiled for PLATFORM_WEB it will play the automation.rae perfectly.
I've been trying to tweak this condition (L3279) trying to see if it could also be made to handle the async nature of emscripten's KeyCallback, but I've been unsuccessful so far. I'll continue working on it during the weekend.

@ubkp Good catch! I don't know how I missed it! Glad to know that it works as expected if provided the right list of automation events!
Another hot-spot where could be some issue is in the KeyCallback() where the up state should be registered... I also tracked down the callback call to library_glfw.js but I can't see any clear issue in there with the key state parameter...

@raysan5 Finished reviewing KeyCallback() and library_glfw.js. I think those parts are indeed working correctly.
But I think I've found the issue: we're calling RecordAutomationEvent() after PollInputEvents() on EndDrawing() (L890, L932). And PollInputEvents() resets the previousKeyState (L570-L574). So by the time RecordAutomationEvent() tries to check for INPUT_KEY_UP it's gone (L3279).
If we move the if (automationEventRecording) RecordAutomationEvent(); from after PollInputEvents(); (L931-L933) to before it (somewhere around here: L889) we can fix this issue. Tested this change successfully on PLATFORM_WEB and PLATFORM_DESKTOP.
What do you think?

@ubkp oh! good catch! Actually, look at this comment before the automation system redesign! 😆
I got the same doubts about the right place to call it! I think moving it to L867 should be ok!

@raysan5 Haha :laughing:
Awesome, I'll send the PR shortly. :+1:

@ubkp thank you very much for reviewing this issue and finding the problem!


Popper propTypes validation for Virtual Element object throws an error

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Current behavior 😯
When using the Popper and attempting to pass a fake, Virtual Element object in by setting the coordinates for the Popper, I'll get a prop-types warning in the console:

You can see the same one in the codesandbox demo.
This error is very misleading, and if I do some investigative work inside the React prop-types validation routine, I can find that this error is actually the result of React's prop-types validator assuming what was passed in had a shape it was after, when in fact, it was an error object, or error stack passed in by Material-UI.  Here's the actual error stack, by running some console.log statements inside factoryWithTypeCheckers.js while Jest runs:
Error: Invalid prop `anchorEl` supplied to `ForwardRef(PopperUnstyled)`. Expected an HTMLElement.
        at HTMLElementType (/workspaces/inter-afw/node_modules/@mui/utils/HTMLElementType.js:21:12)
        at validate (/workspaces/inter-afw/node_modules/prop-types/factoryWithTypeCheckers.js:389:29)
        at checkType (/workspaces/inter-afw/node_modules/prop-types/factoryWithTypeCheckers.js:219:16)
        at Object.validate (/workspaces/inter-afw/node_modules/@mui/utils/chainPropTypes.js:14:12)
        at checkPropTypes (/workspaces/inter-afw/node_modules/react/cjs/react-jsx-runtime.development.js:601:44)
        at validatePropTypes (/workspaces/inter-afw/node_modules/react/cjs/react-jsx-runtime.development.js:1078:7)
        at jsxWithValidation (/workspaces/inter-afw/node_modules/react/cjs/react-jsx-runtime.development.js:1198:7)
        at jsxWithValidationDynamic (/workspaces/inter-afw/node_modules/react/cjs/react-jsx-runtime.development.js:1215:12)
        at Popper (/workspaces/inter-afw/node_modules/@mui/material/node/Popper/Popper.js:42:43)
        at renderWithHooks (/workspaces/inter-afw/node_modules/react-dom/cjs/react-dom.development.js:14985:18)
        at updateForwardRef (/workspaces/inter-afw/node_modules/react-dom/cjs/react-dom.development.js:17044:20)
        at beginWork (/workspaces/inter-afw/node_modules/react-dom/cjs/react-dom.development.js:19098:16)
        at beginWork$1 (/workspaces/inter-afw/node_modules/react-dom/cjs/react-dom.development.js:23940:14)
        at performUnitOfWork (/workspaces/inter-afw/node_modules/react-dom/cjs/react-dom.development.js:22779:12)
        at workLoopSync (/workspaces/inter-afw/node_modules/react-dom/cjs/react-dom.development.js:22707:5)
        at renderRootSync (/workspaces/inter-afw/node_modules/react-dom/cjs/react-dom.development.js:22670:7)
        at performSyncWorkOnRoot (/workspaces/inter-afw/node_modules/react-dom/cjs/react-dom.development.js:22293:18)

Expected behavior 🤔
The propType for anchorEl should be a valid object and not log a warning message.
Steps to reproduce 🕹
Link to CodeSandbox (a very lightly modified fork of the demo):
https://codesandbox.io/s/virtualelementpopper-material-demo-forked-n2tuj?file=/demo.js
Context 🔦
It's just a warning, but shows up all over the place for me when I run tests.
Your environment 🌎

`npx @mui/envinfo`
    System:
    OS: Linux 5.10 CentOS Linux 8
  Binaries:
    Node: 14.18.1 - /usr/local/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 8.1.3 - /usr/local/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    @emotion/react: ^11.4.1 => 11.7.1
    @emotion/styled: ^11.3.0 => 11.6.0
    @mui/base:  5.0.0-alpha.63
    @mui/icons-material: ^5.0.0 => 5.2.5
    @mui/lab: ^5.0.0-alpha.47 => 5.0.0-alpha.63
    @mui/material: ^5.0.0 => 5.2.7
    @mui/private-theming:  5.2.3
    @mui/styled-engine:  5.2.6
    @mui/styles: ^5.0.0 => 5.2.3
    @mui/system:  5.2.6
    @mui/types:  7.1.0
    @mui/utils:  5.2.3
    @types/react:  17.0.37
    react: ^17.0.2 => 17.0.2
    react-dom: ^17.0.2 => 17.0.2
    typescript: ^4.3.2 => 4.5.4

I am not sure if it relates to this https://github.com/facebook/prop-types/pull/370.

I am not sure if it relates to this facebook/prop-types#370.

Wow, that totally fixed it (upgrading to prop-types 5.8.1)!  I even searched facebook/prop-types first, but I guess he submitted the bug report and the PR literally minutes after I opened this one here.


Add a space to make the example code compile

Working around this issue: https://github.com/dotnet/fsharp/issues/4607

Thanks!


HFP plays silence, bluez-alsa to bluez-alsa

I've only successfully played HFP audio through a TaoTronics Bluetooth to 3.5mm adapter. With other devices (a sound bar, multiple vehicles, etc), the audio "plays" with no errors, etc, but no sound is heard on the device. I'm confident that the SCO routing issues are no longer a factor for this chipset, because it is playing and audible with the TaoTronics even with "bluealsa -p hfp-ag". Because I wasn't sure if I was just unlucky with my playback devices, I decided to connect bluez-alsa (a2dp-source, hfp-ag) on my embedded device to bluez-alsa (a2dp-sink, hfp-hf) on a Raspberry Pi 3. First, I got a2dp audio working and it played on the remote device. However, sco audio does not audibly play (I'm using bluealsa-aplay). I forced connection via HFP profile only, with the same results.
Note that I am not using ofono nor phonesim, and bluealsa is compiled without --enable-ofono.
Due to lack of error messages, I'm having trouble investigating this issue. I'm happy to provide more information or do additional troubleshooting or even code changes.

Are you using the latest master? Because it might work ONLY with latest commits. I haven't tested such scenario, though.

No, I missed those! Thanks! I'll give it a try.

On master I can still play to the TaoTronics, but nothing else. One change in behavior: Playing SCO from bluealsa to bluealsa doesn't play, but now aplay also no longer terminates. Here's what I see on both ends (added some blank lines to separate setup/connect/"playback"):
HFP-AG side:
$ sudo bluealsa -p hfp-ag
bluealsa: ba-adapter.c:151: Freeing adapter: hci0
bluealsa: bluez.c:1105: Creating hands-free profile object: /org/bluez/HFP/AudioGateway
bluealsa: bluez.c:1135: Registering hands-free profile: /org/bluez/HFP/AudioGateway
bluealsa: main.c:353: Acquiring D-Bus service name: org.bluealsa
bluealsa: main.c:358: Starting main dispatching loop

bluealsa: bluez.c:1073: Called: org.bluez.Profile1.NewConnection()
bluealsa: sco.c:154: Created SCO dispatcher [ba-sco-dispatch]: hci0
bluealsa: sco.c:69: Starting SCO dispatcher loop: hci0
bluealsa: bluez.c:997: RFCOMM: HFP Audio Gateway configured for device B8:27:EB:87:AD:65
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: rfcomm.c:593: Starting loop: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:982: Created new thread [ba-rfcomm]: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: ba-transport.c:982: Created new thread [ba-sco]: HFP Audio Gateway (CVSD)
bluealsa: sco.c:194: Starting SCO loop: HFP Audio Gateway (CVSD)
bluealsa: at.c:161: AT message: SET: command:+BRSF, value:628
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+BRSF, value:2528
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 0 -> 2
bluealsa: at.c:161: AT message: TEST: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:("call",(0,1)),("callsetup",(0-3)),("service",(0-1)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5)),("callheld",(0-2))
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 2 -> 5
bluealsa: at.c:161: AT message: GET: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:0,0,0,0,0,0,0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 5 -> 7
bluealsa: at.c:161: AT message: SET: command:+CMER, value:3,0,0,1,0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 7 -> 8
bluealsa: rfcomm.c:124: HFP state transition: 8 -> 9
bluealsa: rfcomm.c:124: HFP state transition: 9 -> 13

bluealsa: bluealsa-dbus.c:139: Called: org.bluealsa.Manager1.GetPCMs()
bluealsa: bluealsa-dbus.c:333: Called: org.bluealsa.PCM1.Open()
bluealsa: ba-transport.c:875: Checking Broadcom internal SCO routing
bluealsa: ba-transport.c:881: Current SCO interface setup: 1 2 0 1 1
bluealsa: ba-transport.c:915: New SCO link: B8:27:EB:87:AD:65: 15 (MTU: R:64 W:64)
bluealsa: ba-transport.c:635: State transition: 2 -> 2
bluealsa: ba-transport.c:863: Reusing SCO: 15
bluealsa: ba-transport.c:931: Closing SCO: 15

aplay (doesn't exit until Ctrl+C pressed):
$ aplay -v -D bluealsa:DEV=B8:27:EB:87:AD:65,PROFILE=sco test.wav
$ aplay -v -D bluealsa:DEV=B8:27:EB:87:AD:65,PROFILE=sco test.wav
bluealsa-pcm.c:625: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Setting constraints
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono
bluealsa-pcm.c:344: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing HW
bluealsa-pcm.c:371: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: FIFO buffer size: 4096
bluealsa-pcm.c:377: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Selected HW buffer: 4 periods x 2000 bytes == 8000 bytes
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
bluealsa-pcm.c:414: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Prepared
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
Plug PCM: Rate conversion PCM (8000, sformat=S16_LE)
Converter: libspeex (builtin)
Protocol version: 10002
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 22050
  exact rate   : 22050 (22050/1)
  msbits       : 16
  buffer_size  : 11025
  period_size  : 2756
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : GETTIMEOFDAY
  period_step  : 1
  avail_min    : 2756
  period_event : 0
  start_threshold  : 11025
  stop_threshold   : 11025
  silence_threshold: 0
  silence_size : 0
  boundary     :<PHONE_NUMBER>469964800
Slave: BlueALSA PCM: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco
BlueALSA BlueZ device: /org/bluez/hci0/dev_B8_27_EB_87_AD_65
BlueALSA Bluetooth codec: 0x1
bluealsa-pcm.c:264: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Starting
bluealsa-pcm.c:137: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Starting IO loop: 8

HFP-HF side:
$ sudo bluealsa -p hfp-hf
bluealsa: ../../src/ba-adapter.c:151: Freeing adapter: hci0
bluealsa: ../../src/bluez.c:1105: Creating hands-free profile object: /org/bluez/HFP/HandsFree
bluealsa: ../../src/bluez.c:1135: Registering hands-free profile: /org/bluez/HFP/HandsFree
bluealsa: ../../src/main.c:353: Acquiring D-Bus service name: org.bluealsa
bluealsa: ../../src/main.c:358: Starting main dispatching loop

bluealsa: ../../src/bluealsa-dbus.c:139: Called: org.bluealsa.Manager1.GetPCMs()

bluealsa: ../../src/bluez.c:1073: Called: org.bluez.Profile1.NewConnection()
bluealsa: ../../src/sco.c:154: Created SCO dispatcher [ba-sco-dispatch]: hci0
bluealsa: ../../src/sco.c:69: Starting SCO dispatcher loop: hci0
bluealsa: ../../src/bluez.c:997: RFCOMM: HFP Hands-Free configured for device 70:2C:1F:32:15:85
bluealsa: ../../src/ba-transport.c:635: State transition: 0 -> 2
bluealsa: ../../src/ba-transport.c:982: Created new thread [ba-rfcomm]: RFCOMM: HFP Hands-Free
bluealsa: ../../src/ba-transport.c:635: State transition: 0 -> 2
bluealsa: ../../src/sco.c:194: Starting SCO loop: HFP Hands-Free (CVSD)
bluealsa: ../../src/ba-transport.c:982: Created new thread [ba-sco]: HFP Hands-Free (CVSD)
bluealsa: ../../src/rfcomm.c:593: Starting loop: RFCOMM: HFP Hands-Free
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+BRSF, value:628
bluealsa: ../../src/bluealsa-dbus.c:333: Called: org.bluealsa.PCM1.Open()
bluealsa: ../../src/at.c:161: AT message: RESP: command:+BRSF, value:2528
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 0 -> 1
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 1 -> 2
bluealsa: ../../src/rfcomm.c:106: Sending AT message: TEST: command:+CIND, value:(null)
bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIND, value:("call",(0,1)),("callsetup",(0-3)),("service",(0-1)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5)),("callheld",(0-2))
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 2 -> 4
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 4 -> 5
bluealsa: ../../src/rfcomm.c:106: Sending AT message: GET: command:+CIND, value:(null)
bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIND, value:0,0,0,0,0,0,0
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 5 -> 6
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 6 -> 7
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+CMER, value:3,0,0,1,0
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 7 -> 8
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 8 -> 9
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 9 -> 13

bluealsa: ../../src/sco.c:95: New incoming SCO link: 70:2C:1F:32:15:85: 8
bluealsa: ../../src/ba-transport.c:931: Closing SCO: 8

bluealsa-aplay:
$ bluealsa-aplay --profile-sco -v 70:2C:1F:32:15:85
Selected configuration:
  BlueALSA service: org.bluealsa
  PCM device: default
  PCM buffer time: 500000 us
  PCM period time: 100000 us
  Bluetooth device(s): 70:2C:1F:32:15:85
  Profile: SCO
bluealsa-aplay: ../../utils/aplay.c:801: Starting main loop
bluealsa-aplay: ../../utils/aplay.c:525: Creating PCM worker 70:2C:1F:32:15:85
bluealsa-aplay: ../../utils/aplay.c:356: Starting PCM loop

This is what it looks like when I play to the TaoTronics Wireless Receiver TT-BR08 (where I can hear the sound):
$ sudo bluealsa -p hfp-ag
bluealsa: ba-adapter.c:151: Freeing adapter: hci0
bluealsa: bluez.c:1105: Creating hands-free profile object: /org/bluez/HFP/AudioGateway
bluealsa: bluez.c:1135: Registering hands-free profile: /org/bluez/HFP/AudioGateway
bluealsa: main.c:353: Acquiring D-Bus service name: org.bluealsa
bluealsa: main.c:358: Starting main dispatching loop

bluealsa: bluez.c:1073: Called: org.bluez.Profile1.NewConnection()
bluealsa: sco.c:154: Created SCO dispatcher [ba-sco-dispatch]: hci0
bluealsa: sco.c:69: Starting SCO dispatcher loop: hci0
bluealsa: bluez.c:997: RFCOMM: HFP Audio Gateway configured for device E9:08:EF:2D:40:33
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: rfcomm.c:593: Starting loop: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:982: Created new thread [ba-rfcomm]: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: ba-transport.c:982: Created new thread [ba-sco]: HFP Audio Gateway (CVSD)
bluealsa: sco.c:194: Starting SCO loop: HFP Audio Gateway (CVSD)
bluealsa: at.c:161: AT message: SET: command:+BRSF, value:191
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+BRSF, value:2528
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 0 -> 2
bluealsa: at.c:161: AT message: TEST: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:("call",(0,1)),("callsetup",(0-3)),("service",(0-1)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5)),("callheld",(0-2))
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 2 -> 5
bluealsa: at.c:161: AT message: GET: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:0,0,0,0,0,0,0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 5 -> 7
bluealsa: at.c:161: AT message: SET: command:+CMER, value:3, 0, 0, 1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 7 -> 8
bluealsa: rfcomm.c:124: HFP state transition: 8 -> 9
bluealsa: rfcomm.c:124: HFP state transition: 9 -> 13
bluealsa: at.c:161: AT message: SET: command:+VGS, value:15
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: at.c:161: AT message: GET: command:+BTRH, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: at.c:161: AT message: SET: command:+XAPL, value:0000-0000-0100,7
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:+XAPL=BlueALSA,0
bluealsa: at.c:161: AT message: SET: command:+IPHONEACCEV, value:2,1,8,2,0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: at.c:161: AT message: CMD: command:+CLCC, value:(null)
bluealsa: Unsupported AT message: CMD: command:+CLCC, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+BIA, value:1,1,0,0,0,0,1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: at.c:161: AT message: SET: command:+CSRSF, value:0,0,0,1,0,0,0
bluealsa: Unsupported AT message: SET: command:+CSRSF, value:0,0,0,1,0,0,0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR

bluealsa: bluealsa-dbus.c:139: Called: org.bluealsa.Manager1.GetPCMs()
bluealsa: bluealsa-dbus.c:333: Called: org.bluealsa.PCM1.Open()
bluealsa: ba-transport.c:875: Checking Broadcom internal SCO routing
bluealsa: ba-transport.c:881: Current SCO interface setup: 1 2 0 1 1
bluealsa: ba-transport.c:635: State transition: 2 -> 2
bluealsa: ba-transport.c:915: New SCO link: E9:08:EF:2D:40:33: 15 (MTU: R:64 W:64)
bluealsa: ba-transport.c:863: Reusing SCO: 15
bluealsa: ba-transport.c:863: Reusing SCO: 15
bluealsa: ba-transport.c:718: PCM drained
bluealsa: a2dp.c:122: PCM read buffer flushed: 0
bluealsa: a2dp.c:122: PCM read buffer flushed: 0
bluealsa: ba-transport.c:955: Closing PCM: 8
bluealsa: ba-transport.c:931: Closing SCO: 15

$ sudo bluetoothctl
Agent registered
[bluetooth]# connect E9:08:EF:2D:40:33
Attempting to connect to E9:08:EF:2D:40:33
[CHG] Device E9:08:EF:2D:40:33 Connected: yes
Connection successful
[CHG] Device E9:08:EF:2D:40:33 ServicesResolved: yes
[TaoTronics TT-BR08]# quit

$ aplay -v -D bluealsa:DEV=E9:08:EF:2D:40:33,PROFILE=sco test.wav
bluealsa-pcm.c:625: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Setting constraints
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono
bluealsa-pcm.c:344: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Initializing HW
bluealsa-pcm.c:371: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: FIFO buffer size: 4096
bluealsa-pcm.c:377: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Selected HW buffer: 4 periods x 2000 bytes == 8000 bytes
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Initializing SW
bluealsa-pcm.c:414: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Prepared
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Initializing SW
Plug PCM: Rate conversion PCM (8000, sformat=S16_LE)
Converter: libspeex (builtin)
Protocol version: 10002
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 22050
  exact rate   : 22050 (22050/1)
  msbits       : 16
  buffer_size  : 11025
  period_size  : 2756
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : GETTIMEOFDAY
  period_step  : 1
  avail_min    : 2756
  period_event : 0
  start_threshold  : 11025
  stop_threshold   : 11025
  silence_threshold: 0
  silence_size : 0
  boundary     :<PHONE_NUMBER>469964800
Slave: BlueALSA PCM: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco
BlueALSA BlueZ device: /org/bluez/hci0/dev_E9_08_EF_2D_40_33
BlueALSA Bluetooth codec: 0x1
bluealsa-pcm.c:264: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Starting
bluealsa-pcm.c:137: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Starting IO loop: 8
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Initializing SW
bluealsa-pcm.c:169: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: IO thread paused: 4
bluealsa-pcm.c:305: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Stopping
bluealsa-pcm.c:105: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: IO thread cleanup
bluealsa-pcm.c:305: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Stopping
bluealsa-pcm.c:384: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Freeing HW
bluealsa-pcm.c:334: /org/bluealsa/hci0/dev_E9_08_EF_2D_40_33/sco: Closing

Another log, this time from a soundbar where I don't hear anything. I'm able to play to this soundbar from my Android phone, where I manually uncheck "Media audio" in the Bluetooth settings for the device, which results in it saying "Connected (no media)". If I play a sound on my phone, it plays over my phone speaker. Then I run the app BTmono and turn that On. If I play a high quality sound on my phone, it then plays to the soundbar (in the poor quality you'd expect from HFP). When I use the same process in my car, it shows up as a phone, so that indicates to me that it is in HFP mode rather than HSP mode. Additionally, I cannot seem to connect to the soundbar in HSP mode, nor is it listed in the capabilities. All that leads me to believe that the Android test is valid.
Anyhow, here are the logs from the bluealsa playback:
$ sudo bluealsa -p hfp-ag
bluealsa: ba-adapter.c:151: Freeing adapter: hci0
bluealsa: bluez.c:1105: Creating hands-free profile object: /org/bluez/HFP/AudioGateway
bluealsa: bluez.c:1135: Registering hands-free profile: /org/bluez/HFP/AudioGateway
bluealsa: main.c:353: Acquiring D-Bus service name: org.bluealsa
bluealsa: main.c:358: Starting main dispatching loop

bluealsa: bluez.c:1073: Called: org.bluez.Profile1.NewConnection()
bluealsa: sco.c:154: Created SCO dispatcher [ba-sco-dispatch]: hci0
bluealsa: sco.c:69: Starting SCO dispatcher loop: hci0
bluealsa: bluez.c:997: RFCOMM: HFP Audio Gateway configured for device 6B:F4:54:06:AC:D1
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: rfcomm.c:593: Starting loop: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:982: Created new thread [ba-rfcomm]: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: ba-transport.c:982: Created new thread [ba-sco]: HFP Audio Gateway (CVSD)
bluealsa: sco.c:194: Starting SCO loop: HFP Audio Gateway (CVSD)
bluealsa: at.c:161: AT message: SET: command:+BRSF, value:031
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+BRSF, value:2528
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 0 -> 2
bluealsa: at.c:161: AT message: TEST: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:("call",(0,1)),("callsetup",(0-3)),("service",(0-1)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5)),("callheld",(0-2))
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 2 -> 5
bluealsa: at.c:161: AT message: GET: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:0,0,0,0,0,0,0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 5 -> 7
bluealsa: at.c:161: AT message: SET: command:+CMER, value:3,0,0,1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 7 -> 8
bluealsa: rfcomm.c:124: HFP state transition: 8 -> 9
bluealsa: rfcomm.c:124: HFP state transition: 9 -> 13
bluealsa: at.c:161: AT message: TEST: command:+CHLD, value:(null)
bluealsa: Unsupported AT message: TEST: command:+CHLD, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+CMEE, value:1
bluealsa: Unsupported AT message: SET: command:+CMEE, value:1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+CLIP, value:1
bluealsa: Unsupported AT message: SET: command:+CLIP, value:1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+CCWA, value:1
bluealsa: Unsupported AT message: SET: command:+CCWA, value:1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+NREC, value:0
bluealsa: Unsupported AT message: SET: command:+NREC, value:0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+VGS, value:15
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: at.c:161: AT message: SET: command:+VGM, value:15
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: at.c:161: AT message: SET: command:+XAPL, value:ABCD-1234-0100,10
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:+XAPL=BlueALSA,0

bluealsa: bluealsa-dbus.c:139: Called: org.bluealsa.Manager1.GetPCMs()
bluealsa: bluealsa-dbus.c:333: Called: org.bluealsa.PCM1.Open()
bluealsa: ba-transport.c:875: Checking Broadcom internal SCO routing
bluealsa: ba-transport.c:881: Current SCO interface setup: 1 2 0 1 1
bluealsa: ba-transport.c:915: New SCO link: 6B:F4:54:06:AC:D1: 15 (MTU: R:64 W:64)
bluealsa: ba-transport.c:635: State transition: 2 -> 2
bluealsa: ba-transport.c:863: Reusing SCO: 15
bluealsa: ba-transport.c:863: Reusing SCO: 15
bluealsa: ba-transport.c:718: PCM drained
bluealsa: a2dp.c:122: PCM read buffer flushed: 0
bluealsa: a2dp.c:122: PCM read buffer flushed: 0
bluealsa: sco.c:464: PCM poll error status: 0x10
bluealsa: ba-transport.c:955: Closing PCM: 8
bluealsa: ba-transport.c:955: Closing PCM: 8
bluealsa: ba-transport.c:931: Closing SCO: 15

This one is trusted, etc and seems to autoconnect from the device, so I don't need to use bluetoothctl to connect.
$ aplay -v -D bluealsa:DEV=6B:F4:54:06:AC:D1,PROFILE=sco test.wav
bluealsa-pcm.c:625: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Setting constraints
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono
bluealsa-pcm.c:344: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing HW
bluealsa-pcm.c:371: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: FIFO buffer size: 4096
bluealsa-pcm.c:377: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Selected HW buffer: 4 periods x 2000 bytes == 8000 bytes
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:414: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Prepared
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
Plug PCM: Rate conversion PCM (8000, sformat=S16_LE)
Converter: libspeex (builtin)
Protocol version: 10002
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 22050
  exact rate   : 22050 (22050/1)
  msbits       : 16
  buffer_size  : 11025
  period_size  : 2756
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : GETTIMEOFDAY
  period_step  : 1
  avail_min    : 2756
  period_event : 0
  start_threshold  : 11025
  stop_threshold   : 11025
  silence_threshold: 0
  silence_size : 0
  boundary     :<PHONE_NUMBER>469964800
Slave: BlueALSA PCM: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco
BlueALSA BlueZ device: /org/bluez/hci0/dev_6B_F4_54_06_AC_D1
BlueALSA Bluetooth codec: 0x1
bluealsa-pcm.c:264: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Starting
bluealsa-pcm.c:137: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Starting IO loop: 8
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:169: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: IO thread paused: 4
bluealsa-pcm.c:305: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Stopping
bluealsa-pcm.c:105: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: IO thread cleanup
bluealsa-pcm.c:305: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Stopping
bluealsa-pcm.c:384: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Freeing HW
bluealsa-pcm.c:334: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Closing

Android phone with BTmono connected to bluealsa on my Raspberry Pi 3 also results in me being able to hear sound from the Pi 3.5mm jack:
$ sudo bluealsa -p hfp-hf
bluealsa: ../../src/ba-adapter.c:151: Freeing adapter: hci0
bluealsa: ../../src/bluez.c:1105: Creating hands-free profile object: /org/bluez/HFP/HandsFree
bluealsa: ../../src/bluez.c:1135: Registering hands-free profile: /org/bluez/HFP/HandsFree
bluealsa: ../../src/main.c:353: Acquiring D-Bus service name: org.bluealsa
bluealsa: ../../src/main.c:358: Starting main dispatching loop

bluealsa: ../../src/bluealsa-dbus.c:139: Called: org.bluealsa.Manager1.GetPCMs()

bluealsa: ../../src/bluez.c:1073: Called: org.bluez.Profile1.NewConnection()
bluealsa: ../../src/sco.c:154: Created SCO dispatcher [ba-sco-dispatch]: hci0
bluealsa: ../../src/sco.c:69: Starting SCO dispatcher loop: hci0
bluealsa: ../../src/bluez.c:997: RFCOMM: HFP Hands-Free configured for device 2C:FD:A1:21:0D:B4
bluealsa: ../../src/ba-transport.c:635: State transition: 0 -> 2
bluealsa: ../../src/ba-transport.c:982: Created new thread [ba-rfcomm]: RFCOMM: HFP Hands-Free
bluealsa: ../../src/ba-transport.c:635: State transition: 0 -> 2
bluealsa: ../../src/ba-transport.c:982: Created new thread [ba-sco]: HFP Hands-Free (CVSD)
bluealsa: ../../src/sco.c:194: Starting SCO loop: HFP Hands-Free (CVSD)
bluealsa: ../../src/rfcomm.c:593: Starting loop: RFCOMM: HFP Hands-Free
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+BRSF, value:628
bluealsa: ../../src/bluealsa-dbus.c:333: Called: org.bluealsa.PCM1.Open()
bluealsa: ../../src/at.c:161: AT message: RESP: command:+BRSF, value: 2919
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 0 -> 1
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 1 -> 2
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+BAC, value:1
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 2 -> 3
bluealsa: ../../src/rfcomm.c:106: Sending AT message: TEST: command:+CIND, value:(null)
bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIND, value: ("call",(0,1)),("callsetup",(0-3)),("service",(0-1)),("signal",(0-5)),("roam",(0,1)),("battchg",(0-5)),("callheld",(0-2))
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 3 -> 4
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 4 -> 5
bluealsa: ../../src/rfcomm.c:106: Sending AT message: GET: command:+CIND, value:(null)
bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIND, value: 0,0,1,5,0,4,0
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 5 -> 6
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 6 -> 7
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+CMER, value:3,0,0,1,0
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 7 -> 8
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 8 -> 9

bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIEV, value: 2,2
bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIEV, value: 2,3
bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIEV, value: 1,1
bluealsa: ../../src/sco.c:95: New incoming SCO link: 2C:FD:A1:21:0D:B4: 8
bluealsa: ../../src/ba-transport.c:863: Reusing SCO: 8
bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIEV, value: 2,0

$ bluealsa-aplay --profile-sco -v 2C:FD:A1:21:0D:B4
Selected configuration:
  BlueALSA service: org.bluealsa
  PCM device: default
  PCM buffer time: 500000 us
  PCM period time: 100000 us
  Bluetooth device(s): 2C:FD:A1:21:0D:B4
  Profile: SCO
bluealsa-aplay: ../../utils/aplay.c:801: Starting main loop

bluealsa-aplay: ../../utils/aplay.c:525: Creating PCM worker 2C:FD:A1:21:0D:B4
bluealsa-aplay: ../../utils/aplay.c:356: Starting PCM loop

There are some feature differences between the bluealsa (+BRSF value 2528) and my Android phone (+BRSF value 2919) AG's. Here is a decoding:
                                        bluealsa   Android
/* AG feature flags */                  2528       2919
#define HFP_AG_FEAT_3WC    (1 << 0)     False      True
#define HFP_AG_FEAT_ECNR   (1 << 1)     False      True
#define HFP_AG_FEAT_VOICE  (1 << 2)     False      True
#define HFP_AG_FEAT_RING   (1 << 3)     False      False
#define HFP_AG_FEAT_VTAG   (1 << 4)     False      False
#define HFP_AG_FEAT_REJECT (1 << 5)     True       True
#define HFP_AG_FEAT_ECS    (1 << 6)     True       True
#define HFP_AG_FEAT_ECC    (1 << 7)     True       False
#define HFP_AG_FEAT_EERC   (1 << 8)     True       True
#define HFP_AG_FEAT_CODEC  (1 << 9)     False      True
#define HFP_AG_FEAT_HFIND  (1 << 10)    False      False
#define HFP_AG_FEAT_ESCO   (1 << 11)    True       True

I believe that difference explains why I don't see these lines on the Android phone:
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+BAC, value:1
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 2 -> 3

On the bluealsa AG, HFP_AG_FEAT_CODEC is NO, due to my not enabling mSBC. Therefore, rfcomm.c:311 automatically knows to use CVSD. And it doesn't send +BAC, because of rfcomm.c:635. I don't see a problem there, it was just a difference in output I noticed between the two.
Another difference is that bluealsa performs this state transition, but with the the Android phone AG it doesn't:
bluealsa: ../../src/rfcomm.c:124: HFP state transition: 9 -> 13

State 9 is HFP_SLC_CONNECTED, and state 13 is HFP_CONNECTED. I see the reason at rfcomm.c:675, where if HFP_AG_FEAT_CODEC is set then there is a break, whereas that doesn't happen otherwise and it falls through to line 681 where it sets the state and then does a bluealsa_dbus_transport_update. I experimented with commenting out rfcomm.c:675 if (t->rfcomm.hfp_features & HFP_AG_FEAT_CODEC), but it didn't seem to make any difference.

The HFP connection establishment with a phone or another bluealsa was not tested extensively. Currently I'm refactoring this part of code. Maybe in a week or two I will publish some enhancements. Right now I've changed the codec selection logic and other minor parts and it seems that the connection works much better. I have to test bluealsa-bluealsa interaction, though. Also, I think, I will add test coverage for such scenario. So, stay tuned :)

@killerkalamari - I see that in the hfp-ag output above, you have modified the bluealsa source to give a SCO mtu of 64; but the hfp-hf debug output unfortunately does not show the mtu. Have you also modified the mtu in the file sco.c as well as ba-transport.c, or are are you using the default of 48? You say the hfp-hf case is playing sound correctly so I guess whatever value for mtu you used must be the correct one. For my own information (i'm still investigating the whole sco mtu mess on linux) could you confirm the mtu value used in your hfp-hf test case? Thanks.

@borine You're right, I did make a single change to MTU (sorry, I am not sure which file right now, but I can look it up Monday), but only to bluealsa HFP-AG; the Raspberry Pi HFP-HF is stock.

@killerkalamari I've pushed some "work in progress" to master. Right now it should be possible to connect phone (Audio Gateway) to bluealsa. I've tested it with few devices (android 6.0 and iPhone 13.) and it seems to work. If you've got access to other phones it would be great if you could check connection with them. Playing between bluez-alsa and bluez-alsa might still not work. The problem is with connection acquisition logic in the SCO thread. I will have to rework it as well, because in the current form it causes more troubles than receiving data from AG (e.g. it's hard to implement proper PCM drain).
@borine Lately, I've been working around mSBC setup, and I've found out that there is a socket option sco_options which returns MTU. Unfortunately, this call also returns wrong value. I haven't check a lot of kernel code around SCO MTU, but it definitely seems like kernel bug...

@Arkq I'm currently thinking that the mtu value obtained from the kernel is unreliable only for USB HCI adapters; UART HCI ones seem to provide a correct value. This is based on my own very limited testing and the few forum posts for bluez and pulseaudio that give sufficient info. If I'm right then the function hci_sco_get_mtu() could make use of the struct hci_dev_info for the adapter to use code such as:
	switch (a->hci.type & 0x0f) {
		case HCI_USB:
			if (voice.setting == BT_VOICE_TRANSPARENT)
				options.mtu = 24;
			else
				options.mtu = 48;
			break;
//		[ any other special cases handled here ]
	}

where a is a pointer the the adapter info.
This is all just conjecture at present - I have no idea if TRANSPARENT streams  require special treatment for UART, for example.
However, if it turns out to be a practical approach, it would mean more embedded boards would have SCO work out-of-the-box with bluealsa rather than needing code patches.
@killerkalamari  your HFP-AG profile host requiring mtu == 64 is that an on-board UART adapter? And the HFP-HF profile host with mtu == 48 (ie default) is that an external USB adapter?
If both are on-board, it would be really helpful if you are able to test the HFP-HF host again, but with bluealsa modified to use an MTU of 64. The place to edit the code has unfortunately just moved again because of the re-factoring, so it might be best to wait a few weeks until @Arkq has the current set of SCO changes complete.
I'm also thinking it might be advantageous to add a command-line option allowing a savvy user to select the correct sco mtu policy for their adapter(s). Pulseaudio does this (actually with a module parameter). It would need more thought on the exact options to offer.
Once the current round of code re-factoring is complete I would be happy to submit a PR with some code with which to invite discussion and maybe even persuade some volunteers to test with a variety of adapters.

I think that most of the refactoring part is done already. Some enhancement might be required, though, because connection process is not reliable... But I think that the changes will be rather cosmetic.
@borine I've got also an UART based BT and the MTU reported by it is also 64 bytes. I haven't tested running bluealsa with such MTU, though. With 48/24 it seems to work fine. However, I will make test with original MTU and see how it will behave :)

@Arkq UART adapters tend to have an mtu size that fills their buffer (eg 64:1 is common for Broadcom/Cypress while 120:1 is common for Texas Instruments). USB tend to have larger buffers, but often smaller mtus (eg 50:8 for Qualcomm/Atheros, 64:8 for Intel).
The value of 64:8 is often generated by the kernel btusb driver as a quirk for controllers that it claims report wrong values. But for me, using a kernel mtu for any USB device crashes the controller whether "quirked" or not.

This is the patch I was using, took it out for now:
--- bluez-alsa-2cd6e4686f7808276480b430fb37df55dfdcc02b.orig/src/ba-transport.c	2019-10-17 13:32:38.942308319 -0700
+++ bluez-alsa-2cd6e4686f7808276480b430fb37df55dfdcc02b/src/ba-transport.c	2019-10-17 14:05:31.618254533 -0700
@@ -673,7 +673,7 @@ int ba_transport_drain_pcm(struct ba_tra
 	 * arbitrary time before releasing transport. In order to make it right,
 	 * there is a requirement for an asynchronous release mechanism, which
 	 * is not implemented - it requires a little bit of refactoring. */
-	usleep(200000);
+	usleep(1000000);

 	debug("PCM drained");
 	return 0;
@@ -839,8 +839,8 @@ static int transport_acquire_bt_sco(stru

 	/* XXX: It seems, that the MTU values returned by the HCI interface
 	 *      are incorrect (or our interpretation of them is incorrect). */
-	t->mtu_read = 48;
-	t->mtu_write = 48;
+	t->mtu_read = 64;
+	t->mtu_write = 64;

 	if (t->type.codec == HFP_CODEC_MSBC)
 		t->mtu_read = t->mtu_write = 24;

I've re-tested the various combos.
Newly working:

bluealsa to bluealsa

Continues to work:

bluealsa to TaoTronics
Android to bluealsa

Still playing silence:

bluealsa to soundbar

By my original bug report, this is resolved, thanks! I was hoping the resolution for bluealsa would also fix the soundbar, but no such luck, I guess. I know you're still in the middle of improving things, so I'll keep watching the commits. In case it's useful, here's the output I get when trying to play to the soundbar:
$ sudo bluealsa -p hfp-ag
bluealsa: ba-adapter.c:151: Freeing adapter: hci0
bluealsa: bluez.c:1105: Creating hands-free profile object: /org/bluez/HFP/AudioGateway
bluealsa: bluez.c:1135: Registering hands-free profile: /org/bluez/HFP/AudioGateway
bluealsa: main.c:353: Acquiring D-Bus service name: org.bluealsa
bluealsa: main.c:358: Starting main dispatching loop

bluealsa: bluez.c:1073: Called: org.bluez.Profile1.NewConnection()
bluealsa: sco.c:154: Created SCO dispatcher [ba-sco-dispatch]: hci0
bluealsa: bluez.c:997: RFCOMM: HFP Audio Gateway configured for device 6B:F4:54:06:AC:D1
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: rfcomm.c:593: Starting loop: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:982: Created new thread [ba-rfcomm]: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: ba-transport.c:982: Created new thread [ba-sco]: HFP Audio Gateway (CVSD)
bluealsa: sco.c:194: Starting SCO loop: HFP Audio Gateway (CVSD)
bluealsa: sco.c:69: Starting SCO dispatcher loop: hci0
bluealsa: at.c:161: AT message: SET: command:+BRSF, value:031
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+BRSF, value:2528
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 0 -> 2
bluealsa: at.c:161: AT message: TEST: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:("call",(0,1)),("callsetup",(0-3)),("service",(0-1)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5)),("callheld",(0-2))
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 2 -> 5
bluealsa: at.c:161: AT message: GET: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:0,0,0,0,0,0,0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 5 -> 7
bluealsa: at.c:161: AT message: SET: command:+CMER, value:3,0,0,1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:124: HFP state transition: 7 -> 8
bluealsa: rfcomm.c:124: HFP state transition: 8 -> 9
bluealsa: rfcomm.c:124: HFP state transition: 9 -> 13
bluealsa: at.c:161: AT message: TEST: command:+CHLD, value:(null)
bluealsa: Unsupported AT message: TEST: command:+CHLD, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+CMEE, value:1
bluealsa: Unsupported AT message: SET: command:+CMEE, value:1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+CLIP, value:1
bluealsa: Unsupported AT message: SET: command:+CLIP, value:1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+CCWA, value:1
bluealsa: Unsupported AT message: SET: command:+CCWA, value:1
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+NREC, value:0
bluealsa: Unsupported AT message: SET: command:+NREC, value:0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:ERROR
bluealsa: at.c:161: AT message: SET: command:+VGS, value:15
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: at.c:161: AT message: SET: command:+VGM, value:15
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: at.c:161: AT message: SET: command:+XAPL, value:ABCD-1234-0100,10
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:+XAPL=BlueALSA,0

bluealsa: bluealsa-dbus.c:139: Called: org.bluealsa.Manager1.GetPCMs()
bluealsa: bluealsa-dbus.c:333: Called: org.bluealsa.PCM1.Open()
bluealsa: ba-transport.c:875: Checking Broadcom internal SCO routing
bluealsa: ba-transport.c:881: Current SCO interface setup: 1 2 0 1 1
bluealsa: ba-transport.c:915: New SCO link: 6B:F4:54:06:AC:D1: 14 (MTU: R:64 W:64)
bluealsa: ba-transport.c:635: State transition: 2 -> 2
bluealsa: ba-transport.c:863: Reusing SCO: 14
bluealsa: ba-transport.c:863: Reusing SCO: 14
bluealsa: ba-transport.c:718: PCM drained
bluealsa: a2dp.c:122: PCM read buffer flushed: 0
bluealsa: a2dp.c:122: PCM read buffer flushed: 0
bluealsa: sco.c:464: PCM poll error status: 0x10
bluealsa: ba-transport.c:955: Closing PCM: 8
bluealsa: ba-transport.c:931: Closing SCO: 14

$ aplay -v -D bluealsa:DEV=6B:F4:54:06:AC:D1,PROFILE=sco test.wav
bluealsa-pcm.c:625: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Setting constraints
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono
bluealsa-pcm.c:344: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing HW
bluealsa-pcm.c:371: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: FIFO buffer size: 4096
bluealsa-pcm.c:377: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Selected HW buffer: 4 periods x 2000 bytes == 8000 bytes
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:414: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Prepared
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
Plug PCM: Rate conversion PCM (8000, sformat=S16_LE)
Converter: libspeex (builtin)
Protocol version: 10002
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 22050
  exact rate   : 22050 (22050/1)
  msbits       : 16
  buffer_size  : 11025
  period_size  : 2756
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : GETTIMEOFDAY
  period_step  : 1
  avail_min    : 2756
  period_event : 0
  start_threshold  : 11025
  stop_threshold   : 11025
  silence_threshold: 0
  silence_size : 0
  boundary     :<PHONE_NUMBER>469964800
Slave: BlueALSA PCM: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco
BlueALSA BlueZ device: /org/bluez/hci0/dev_6B_F4_54_06_AC_D1
BlueALSA Bluetooth codec: 0x1
bluealsa-pcm.c:264: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Starting
bluealsa-pcm.c:137: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Starting IO loop: 8
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Initializing SW
bluealsa-pcm.c:169: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: IO thread paused: 4
bluealsa-pcm.c:305: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Stopping
bluealsa-pcm.c:105: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: IO thread cleanup
bluealsa-pcm.c:305: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Stopping
bluealsa-pcm.c:384: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Freeing HW
bluealsa-pcm.c:334: /org/bluealsa/hci0/dev_6B_F4_54_06_AC_D1/sco: Closing

Audio gateway (obsolete Samsung Artik):
$ sudo hciconfig hci0 version
hci0:	Type: Primary  Bus: UART
	BD Address: 70:2C:1F:32:15:85  ACL MTU: 1021:8  SCO MTU: 64:1
	HCI Version: 4.0 (0x6)  Revision: 0xe0
	LMP Version: 4.0 (0x6)  Subversion: 0x6119
	Manufacturer: Broadcom Corporation (15)

Hands-free (Pi 3):
sudo hciconfig hci0 version
hci0:	Type: Primary  Bus: UART
	BD Address: B8:27:EB:87:AD:65  ACL MTU: 1021:8  SCO MTU: 64:1
	HCI Version: 4.1 (0x7)  Revision: 0x168
	LMP Version: 4.1 (0x7)  Subversion: 0x2209
	Manufacturer: Broadcom Corporation (15)

I'll go ahead and change it to 64 and see what happens.

bluealsa to bluealsa output with the following patch applied to both AG and HF devices. Plays okay, the audio of longer files is momentarily garbled periodically, but I'm guessing that's just a feature of HFP:
--- bluez-alsa-ce960be902ea9dd9d7dd211afd0ec232433b3eda.orig/src/ba-transport.c	2019-11-11 13:18:58.868404453 -0700
+++ bluez-alsa-ce960be902ea9dd9d7dd211afd0ec232433b3eda/src/ba-transport.c	2019-11-11 13:34:46.102692599 -0700
@@ -713,7 +713,7 @@ int ba_transport_drain_pcm(struct ba_tra
 	 * arbitrary time before releasing transport. In order to make it right,
 	 * there is a requirement for an asynchronous release mechanism, which
 	 * is not implemented - it requires a little bit of refactoring. */
-	usleep(200000);
+	usleep(1000000);

 	debug("PCM drained");
 	return 0;
@@ -877,7 +877,9 @@ static int transport_acquire_bt_sco(stru

 	debug("New SCO link: %s: %d", batostr_(&t->d->addr), t->bt_fd);

+	debug("MTU before: R:%zu W:%zu", t->mtu_read, t->mtu_write);
 	t->mtu_read = t->mtu_write = hci_sco_get_mtu(t->bt_fd);
+	debug("MTU after: R:%zu W:%zu", t->mtu_read, t->mtu_write);

 	return t->bt_fd;

--- bluez-alsa-ce960be902ea9dd9d7dd211afd0ec232433b3eda.orig/src/hci.c	2019-11-11 13:18:51.684417398 -0700
+++ bluez-alsa-ce960be902ea9dd9d7dd211afd0ec232433b3eda/src/hci.c	2019-11-11 13:43:24.745751499 -0700
@@ -128,7 +128,7 @@ unsigned int hci_sco_get_mtu(int sco_fd)
 	/* XXX: It seems, that the MTU value returned by kernel
 	 *      is incorrect (or our interpretation of it). */

-	options.mtu = 48;
+	options.mtu = 64;
 	if (voice.setting == BT_VOICE_TRANSPARENT)
 		options.mtu = 24;

$ sudo bluealsa -p hfp-ag
bluealsa: ba-adapter.c:151: Freeing adapter: hci0
bluealsa: bluez.c:1105: Creating hands-free profile object: /org/bluez/HFP/AudioGateway
bluealsa: bluez.c:1135: Registering hands-free profile: /org/bluez/HFP/AudioGateway
bluealsa: main.c:353: Acquiring D-Bus service name: org.bluealsa
bluealsa: main.c:358: Starting main dispatching loop

bluealsa: bluez.c:1073: Called: org.bluez.Profile1.NewConnection()
bluealsa: sco.c:167: Checking Broadcom internal SCO routing
bluealsa: sco.c:173: Current SCO interface setup: 0 2 0 1 1
bluealsa: sco.c:175: Setting SCO routing via transport interface
bluealsa: sco.c:201: Created SCO dispatcher [ba-sco-dispatch]: hci0
bluealsa: sco.c:77: Starting SCO dispatcher loop: hci0
bluealsa: bluez.c:997: RFCOMM: HFP Audio Gateway configured for device B8:27:EB:87:AD:65
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: rfcomm.c:698: Starting loop: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:949: Created new thread [ba-rfcomm]: RFCOMM: HFP Audio Gateway
bluealsa: ba-transport.c:635: State transition: 0 -> 2
bluealsa: ba-transport.c:949: Created new thread [ba-sco]: HFP Audio Gateway (CVSD)
bluealsa: sco.c:242: Starting SCO loop: HFP Audio Gateway (CVSD)
bluealsa: at.c:161: AT message: SET: command:+BRSF, value:628
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+BRSF, value:2272
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:125: RFCOMM: HFP Audio Gateway state transition: 0 -> 2
bluealsa: at.c:161: AT message: TEST: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:("call",(0,1)),("callsetup",(0-3)),("service",(0-1)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5)),("callheld",(0-2))
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:125: RFCOMM: HFP Audio Gateway state transition: 2 -> 5
bluealsa: at.c:161: AT message: GET: command:+CIND, value:(null)
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:+CIND, value:0,0,0,0,0,0,0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:125: RFCOMM: HFP Audio Gateway state transition: 5 -> 7
bluealsa: at.c:161: AT message: SET: command:+CMER, value:3,0,0,1,0
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: rfcomm.c:125: RFCOMM: HFP Audio Gateway state transition: 7 -> 8
bluealsa: rfcomm.c:125: RFCOMM: HFP Audio Gateway state transition: 8 -> 9
bluealsa: rfcomm.c:859: RFCOMM poll timeout
bluealsa: at.c:161: AT message: SET: command:+VGM, value:15
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK
bluealsa: at.c:161: AT message: SET: command:+VGS, value:15
bluealsa: rfcomm.c:106: Sending AT message: RESP: command:(null), value:OK

bluealsa: bluealsa-dbus.c:139: Called: org.bluealsa.Manager1.GetPCMs()
bluealsa: bluealsa-dbus.c:333: Called: org.bluealsa.PCM1.Open()
bluealsa: ba-transport.c:635: State transition: 2 -> 2
bluealsa: ba-transport.c:878: New SCO link: B8:27:EB:87:AD:65: 18
bluealsa: ba-transport.c:880: MTU before: R:0 W:0
bluealsa: hci.c:126: SCO link socket MTU: 18: 64
bluealsa: ba-transport.c:882: MTU after: R:64 W:64
bluealsa: ba-transport.c:718: PCM drained
bluealsa: a2dp.c:122: PCM read buffer flushed: 0
bluealsa: a2dp.c:122: PCM read buffer flushed: 0
bluealsa: sco.c:512: PCM poll error status: 0x10
bluealsa: ba-transport.c:922: Closing PCM: 8
bluealsa: ba-transport.c:922: Closing PCM: 8
bluealsa: sco.c:335: Releasing SCO due to PCM inactivity
bluealsa: ba-transport.c:898: Closing SCO: 18
bluealsa: sco.c:335: Releasing SCO due to PCM inactivity

$ aplay -v -D bluealsa:DEV=B8:27:EB:87:AD:65,PROFILE=sco test.wav
bluealsa-pcm.c:625: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Setting constraints
Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono
bluealsa-pcm.c:344: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing HW
bluealsa-pcm.c:371: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: FIFO buffer size: 4096
bluealsa-pcm.c:377: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Selected HW buffer: 4 periods x 2000 bytes == 8000 bytes
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
bluealsa-pcm.c:414: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Prepared
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
Plug PCM: Rate conversion PCM (8000, sformat=S16_LE)
Converter: libspeex (builtin)
Protocol version: 10002
Its setup is:
  stream       : PLAYBACK
  access       : RW_INTERLEAVED
  format       : S16_LE
  subformat    : STD
  channels     : 1
  rate         : 22050
  exact rate   : 22050 (22050/1)
  msbits       : 16
  buffer_size  : 11025
  period_size  : 2756
  period_time  : 125000
  tstamp_mode  : NONE
  tstamp_type  : GETTIMEOFDAY
  period_step  : 1
  avail_min    : 2756
  period_event : 0
  start_threshold  : 11025
  stop_threshold   : 11025
  silence_threshold: 0
  silence_size : 0
  boundary     :<PHONE_NUMBER>469964800
Slave: BlueALSA PCM: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco
BlueALSA BlueZ device: /org/bluez/hci0/dev_B8_27_EB_87_AD_65
BlueALSA Bluetooth codec: 0x1
bluealsa-pcm.c:264: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Starting
bluealsa-pcm.c:137: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Starting IO loop: 8
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
bluealsa-pcm.c:392: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Initializing SW
bluealsa-pcm.c:169: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: IO thread paused: 4
bluealsa-pcm.c:305: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Stopping
bluealsa-pcm.c:105: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: IO thread cleanup
bluealsa-pcm.c:305: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Stopping
bluealsa-pcm.c:384: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Freeing HW
bluealsa-pcm.c:334: /org/bluealsa/hci0/dev_B8_27_EB_87_AD_65/sco: Closing

$ sudo bluealsa -p hfp-hf
bluealsa: ../../src/ba-adapter.c:151: Freeing adapter: hci0
bluealsa: ../../src/bluez.c:1105: Creating hands-free profile object: /org/bluez/HFP/HandsFree
bluealsa: ../../src/bluez.c:1135: Registering hands-free profile: /org/bluez/HFP/HandsFree
bluealsa: ../../src/main.c:353: Acquiring D-Bus service name: org.bluealsa
bluealsa: ../../src/main.c:358: Starting main dispatching loop

bluealsa: ../../src/bluealsa-dbus.c:139: Called: org.bluealsa.Manager1.GetPCMs()
bluealsa: ../../src/bluez.c:1073: Called: org.bluez.Profile1.NewConnection()
bluealsa: ../../src/sco.c:167: Checking Broadcom internal SCO routing
bluealsa: ../../src/sco.c:173: Current SCO interface setup: 1 2 0 1 1
bluealsa: ../../src/sco.c:77: Starting SCO dispatcher loop: hci0
bluealsa: ../../src/sco.c:201: Created SCO dispatcher [ba-sco-dispatch]: hci0
bluealsa: ../../src/bluez.c:997: RFCOMM: HFP Hands-Free configured for device 70:2C:1F:32:15:85
bluealsa: ../../src/ba-transport.c:635: State transition: 0 -> 2
bluealsa: ../../src/ba-transport.c:949: Created new thread [ba-rfcomm]: RFCOMM: HFP Hands-Free
bluealsa: ../../src/ba-transport.c:635: State transition: 0 -> 2
bluealsa: ../../src/ba-transport.c:949: Created new thread [ba-sco]: HFP Hands-Free (CVSD)
bluealsa: ../../src/bluealsa-dbus.c:333: Called: org.bluealsa.PCM1.Open()
bluealsa: ../../src/rfcomm.c:698: Starting loop: RFCOMM: HFP Hands-Free
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+BRSF, value:628
bluealsa: ../../src/sco.c:242: Starting SCO loop: HFP Hands-Free (CVSD)
bluealsa: ../../src/at.c:161: AT message: RESP: command:+BRSF, value:2272
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 0 -> 1
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 1 -> 2
bluealsa: ../../src/rfcomm.c:106: Sending AT message: TEST: command:+CIND, value:(null)
bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIND, value:("call",(0,1)),("callsetup",(0-3)),("service",(0-1)),("signal",(0-5)),("roam",(0-1)),("battchg",(0-5)),("callheld",(0-2))
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 2 -> 4
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 4 -> 5
bluealsa: ../../src/rfcomm.c:106: Sending AT message: GET: command:+CIND, value:(null)
bluealsa: ../../src/at.c:161: AT message: RESP: command:+CIND, value:0,0,0,0,0,0,0
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 5 -> 6
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 6 -> 7
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+CMER, value:3,0,0,1,0
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 7 -> 8
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 8 -> 9
bluealsa: ../../src/rfcomm.c:859: RFCOMM poll timeout
bluealsa: ../../src/rfcomm.c:627: Updating microphone gain: 15
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+VGM, value:15
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 9 -> 9
bluealsa: ../../src/rfcomm.c:658: Updating speaker gain: 15
bluealsa: ../../src/rfcomm.c:106: Sending AT message: SET: command:+VGS, value:15
bluealsa: ../../src/at.c:161: AT message: RESP: command:, value:OK
bluealsa: ../../src/rfcomm.c:125: RFCOMM: HFP Hands-Free state transition: 9 -> 9
bluealsa: ../../src/sco.c:103: New incoming SCO link: 70:2C:1F:32:15:85: 8
bluealsa: ../../src/hci.c:126: SCO link socket MTU: 8: 64
bluealsa: ../../src/sco.c:412: SCO poll error status: 0x18
bluealsa: ../../src/ba-transport.c:898: Closing SCO: 8

$ bluealsa-aplay --profile-sco 70:2C:1F:32:15:85
bluealsa-aplay: ../../utils/aplay.c:801: Starting main loop

bluealsa-aplay: ../../utils/aplay.c:525: Creating PCM worker 70:2C:1F:32:15:85
bluealsa-aplay: ../../utils/aplay.c:356: Starting PCM loop

bluealsa-aplay: ../../utils/aplay.c:373: Device marked as inactive: 70:2C:1F:32:15:85


Kafka Version : How to set version to 0.9.x

In the add cluster window, i can only select upto version <IP_ADDRESS>. But i have Kafka version 0.9.x. How do i specify this?

0.9.x support is in-progress
https://github.com/yahoo/kafka-manager/pull/195
On Tue, Mar 22, 2016 at 1:13 PM, Abhijit Tomar<EMAIL_ADDRESS>wrote:

In the add cluster window, i can only select upto version <IP_ADDRESS>. But i
have Kafka version 0.9.x. How do i specify this?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/yahoo/kafka-manager/issues/213

This has been merged into master and released as tag <IP_ADDRESS>


Unable to start the provider in Step 1. Getting error Address already in use

While running the command in Windows 10
$ ./gradlew :providers:dropwizard-provider:run
I get the error that the Address is already in use and the build fails. How can i correct this?

Something is running on same port (8080) as provider is trying to start.
You can use TCPView (https://docs.microsoft.com/cs-cz/sysinternals/downloads/tcpview) to find that process on port 8080.
This issues could be closed imo :)


Pin the netty-transport-native-epoll to avoid conflicts

Motivation
Currently the version pinning for netty-transport-native-epoll is not including the native library artifact.
That results, depending on the Maven version, to be picking up an earlier version of transport-native-epoll-4.1.33.Final-linux-x86_64.jar, where the version is 4.1.33 as opposed to 4.1.43 which is the correct expected version.
This results in using Java NIO based transport instead of the more effiecient/performant epoll based one.
This affects 2.5.0 as well.

@merlimat thank you for putting this change. Can you please use "release/2.5.0" for minor releases? We started using milestones for major releases only. Every pull request goes to major releases first and will be labelled for minor releases "release/2.5.1".


Validate translations

This PR adds a JS script called ValidateTranslations that checks whether the provided translations are valid. A GitHub action is also defined to call this script on pushes to any branch.
The script is written in JavaScript as running it as a stand-alone TS file never fully worked. On the one hand, i18n-extract does not provide proper typing, requiring some hacks to get it into TypeScript (e.g. including the source code directly as it required some manual editing to even run). On the other hand, importing other modules did not work out of the box.
The JavaScript file can easily be run through Node, but the Translations.ts file had to be converted to JS for it to be imported. This isn't an impactful change, as they are simple objects where typing is quite irrelevant.
The current checks are: detecting any unused, missing, duplicated or dynamic keys, and failing if any of these are present (with failing only once all checks have been done to prevent rerunning often). Explictly empty keys (such as Papyros.ready) are considered as missing, but this is a special case so whitespace also does the trick.
Closes #53

👍 Looks good. Do we also want to check for unused translations? Maybe in that case, we shouldn't error, but we can add them as annotations to the code, e.g. using https://github.com/pytorch/add-annotations-github-action

Not entirely sure how these annotations would work. Unused translations would only be present in the Translations.js file. How would these be added?
Regarding my question to the issue with dynamic translation keys (with interpolated strings causing the static analysis to deem everything used), how do you think we best tackle that? I think it would be possible to make these explicit, which would make the analysis more useful.

Regarding annotations: the action I linked lets you add github annotations (by writing filename, line number and message to a file). They then show up in the github UI. In this case, I would add such annotation to the lines containing unused translations.
Regarding dynamic translation keys: what is your question exactly? I probably missed it somewhere.

Regarding annotations: the action I linked lets you add github annotations (by writing filename, line number and message to a file). They then show up in the github UI. In this case, I would add such annotation to the lines containing unused translations.

I will take a look then, thanks!

Regarding dynamic translation keys: what is your question exactly? I probably missed it somewhere.

I edited the original post so the question wasn't there anymore. In essence, if dynamic translation keys are used (i.e string interpolation in the translation key like Papyros.${programmingLanguage}) then this script becomes quite useless. It employs static analysis and cannot determine which values could be passed here, so it deems every key used. My question was thus whether we want to forbid dynamic keys. This might be a bit of a hassle for the programmer, but it does allow static analysis to be useful. I opted to indeed let go of dynamic keys and added the forbidDynamic check to the script to make this clear.

Ok now I see. I think this is why they often have nested keys, e.g. papyros.programming_language.${language}, then only do interpolation in such subkeys.

Ok now I see. I think this is why they often have nested keys, e.g. papyros.programming_language.${language}, then only do interpolation in such subkeys.

That indeed sounds like it could work. Do you want me to integrate that, or keep this as this is and merge it?

It seems cleaner to have nested translations to be able to group things, no?

@bmesuere This branch should now also add annotations to files where a certain kind of translation issue was detected. It is thus ready for review and hopefully merging.

@bmesuere Annotations from testing are available on https://github.com/dodona-edu/papyros/actions/runs/1545351976, but I am not exactly sure how to use them properly. Is this our expected output, or am I misinterpreting something?

@bmesuere Annotations are now present in the "files changed" tab. Once you agree with the formatting, I can remove the testing keys and then this can be merged?


Update caching.md

corrected file name

@ramiMSFT
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@gusega Thanks for your contribution!
#sign-off


Enable check for preview release approval in APIView for Python

Enable approval for preview release. We should fail build job if APIView returns error code 202 for a preview version package when release date is set in change log.

Label prediction was below confidence level 0.6 for Model:ServiceLabels: 'Storage:0.09009077,Cosmos:0.045588426,Tables:0.040689252'


Feature request: WebKit timestamps

I would like to be able to parse WebKit timestamps. They are very similar to existing Unix timestamps, but it's a 64-bit value for microseconds since Jan 1, 1601 00:00 UTC.

The idea of the following (shameless reference to someone else's) work could easily be used as a recipe to convert between the two formats:
https://gist.github.com/mariuswatz/9907831


Fix leg calculation

Fixes the calculation for the legs
calcLegs.js now returns the correct values for LowerLeg, which were previously the same as for UpperLeg.
Also fixes a typo for the default side.

Thank you! LGTM


[pt-br] Update br/The-shell-aka-REPL.md

Added a pt-br translation to The-shell-aka-REPL.md

@brakmic why did you keep my suggestions out? 🙁 @paulorasilva did agree they made sense.

@brakmic why did you keep my suggestions out? 🙁 @paulorasilva did agree they made sense.

Sorry, it wasn't intentional. I'm only merging stuff. Not directly involved in the creative process of this repo anymore.
If possible, create a separate PR so I can merge.


Bump dep: docker/distribution

I'm a filthy Windows dev and I needed this: https://github.com/docker/distribution/pull/1716
So I bumped docker/distribution in order to godep restore ./...
                {
			"ImportPath": "github.com/docker/distribution/digest",
			"Comment": "v2.5.0",
			"Rev": "a9b1322edf48b1fb9aee4e5ded7a4f4ac37c6830"
		},
		{
			"ImportPath": "github.com/docker/distribution/reference",
			"Comment": "v2.5.0",
			"Rev": "a9b1322edf48b1fb9aee4e5ded7a4f4ac37c6830"
		},

Unsure if this should have been a PR.

@HakShak is this a bug fix for client-go or because your own project requires that behavior? If it's the latter, depending on your dependency management tool you can override the value client-go requests. For example: https://github.com/kubernetes/client-go/issues/79#issuecomment-281539491

I have definitely done a local commit to godeps to fix this.
As for a bug fix or my own project needs: Any one who tries to build kubernetes/client-go on Windows will fail if they are using godeps to lock to v2.0.0
I'm good with bumping the upstream godeps in my local vendor, but I just assumed someone else would run into this eventually. :)

Okay, this seems like this is an actual bug in client-go. Yes, if can submit a PR to the github.comkubernetes/kubernetes repo, that'd be great!

Should that be just the Godeps.json file, or the entirety of the vendor changes as well?

@HakShak I think you have to use the specialized scripts in the kubernetes repo (haven't updated a dependency in a while). For details, see: https://github.com/kubernetes/community/blob/master/contributors/devel/godep.md

@HakShak Is this still relevant?
If it's a problem affecting anyone who uses client-go on Windows, we should probably fix this ASAP...


[GitHubBrowserSample] RepoFragmentTest broken

Broken by this patch:
https://github.com/googlesamples/android-architecture-components/commit/330481ac0ab6bd7b28230fe7abdac857b155dad1
Locally reverting that change makes the test pass again. @JoseAlcerreca Patch looks benign, any idea why?

Fixed.