-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bt iso data fixes #33766
Bt iso data fixes #33766
Conversation
c282d37
to
bd0fa2c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Commits' titles should be prefixed by the subsystem the commit targets: https://docs.zephyrproject.org/latest/contribute/index.html#commit-guidelines
For the native posix build the sleep calls used i tasks will stall the zephyr instance
native_posix is not meant for hard real time interaction with host hardware. The real time support is only there to support some level of interactive testing, and testing with real host peripherals.
So if you find yourself needing to reconfigure it to awake every ms (as you are doing here), you are beyond the limit of what it ever was meant for. Even if native_posix tries to get rescheduled every ms, the host OS is going to schedule it with whatever priority at whatever tick it has. So you are going to see a lot of jitter in the scheduling.
If you want to interact with something sending a lot of data, you should, hopefully, mostly only need more buffering.
which sets an upper limit on the data processing speed to one packet every 20-30 millisecond.
This sounds a bit funny. @jhedberg can the BT user channel not queue several packets at a time?
True, I think many people use this on a Linux PC, where the tick is typically 250 ticks per second. I do see some jitter, but it seems to be within one tick. My thinking of setting it to 1000 was that if multiple zephyr tasks was using sleep (at leas two does for the current ISO data test application), you could have zephyr execute 4 ticks for every host OS tick. When you start to add tasks to read audio data as well you would have more sleep calls. |
bd0fa2c
to
890a7b1
Compare
890a7b1
to
00f458e
Compare
fd0f930
to
4be8be3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two minor documentation comments, and then some questions regarding the peripheral command.
73047e6
to
a9bc555
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One minor final comment, otherwise LGTM
a9bc555
to
d72c6b4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@aescolar Just to conclude on this. Yes it can process multiple packets per tick, but if you have an ISO interval of 5ms and only have a few ISO buffers in the controller you will get gabs in the data if you only process data every 20-30ms. I did move the configuration of this to the BT-shell native posix test application configuration rather than the global configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aescolar Just to conclude on this. Yes it can process multiple packets per tick, but if you have an ISO interval of 5ms and only have a few ISO buffers in the controller you will get gabs in the data if you only process data every 20-30ms. I did move the configuration of this to the BT-shell native posix test application configuration rather than the global configuration.
Fair enough. I think at this point it is @jhedberg (and maybe also @Vudentz @joerchan) who should approve or request changes.
@joerchan can you please re-review? |
@Casper-Bonde-Bose do you want this in for 2.6? if so please address the review comments. |
For the native posix build the sleep calls used in tasks will stall the zephyr instance which sets an upper limit on the data processing interval to once every 20-30 millisecond. This change reduces the duration of the sleep calls and increases the TICKS_PER_SECOND to allow for shorter sleeps. This is needed to support the data rates needed for LE Audio streaming. The rate is tuned to support up to bidirectional 5ms ISO-intervals. This change also increases the ISO buffer count from 1 to 5 to allow for some buffering in the controller, which is needed for gapless playback and/or use of burst number larger than 1. Signed-off-by: Casper Bonde <casper_bonde@bose.com>
The sequence number is needed in the appliaction layer to detect lost packets in the ISO stream in cases where the timestamp is not included. (Sequence number is mandatory to include where timestamp is optional). The API for the public metadata have been moved to a public header file. As the size of the ISO meta data exceeds the default 4 octets net_buf user_data the public ISO metadata have been moved into a seperate array. The internal metadata is still stored in net_buf user_data. This also fixed the user_data overflow on 32 bit systems, caused by writing the ts into user_data on index 4 to 7, which is outside the 4 allocated bytes. Signed-off-by: Casper Bonde <casper_bonde@bose.com>
d72c6b4
to
cf2e424
Compare
|
The current iso commands in the shell only supports setting up a bidirectional stream or unidirectional for central role. Adding rx/tx/rxtx option to iso listen command to allow for peripheral side configuration of an iso connection. Signed-off-by: Casper Bonde <casper_bonde@bose.com>
cf2e424
to
8fbec49
Compare
One thing that would be nice to add to the bt_iso_recv_info struct is also the packet flags (retrieved with the line Can be appended in this PR, or added in a new PR. |
@Thalley I like this idea, and agree it would be a natural extension. |
|
A few fixes required for proper ISO data processing.
Fixes #31179.