nrf5340 audio DK: transmit two headsets' mic data to one gateway

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

Simonr — Fri, 10 Jan 2025 08:19:19 GMT

Hi Lincoln

I'm sorry but I don't think we should focus on the legacy branch here, there are some issues there and it most likely won't work properly with the USB dongle as is now. We have a plan for extending the USB audio feature on the new demo branch as well, but it will take some time to implement properly, so the best thing would be to watch the branch and be aware of any commits to it regarding USB audio. Sorry for the inconvenience, but I'd say the best way forward is to wait here, as we don't have anything ready right now.

If you need a more solid roadmap/timeline, please contact the local sales manager of your region for details. Let me know if you need assistance reaching out.

Best regards,

Simon

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

lincoln-lu — Fri, 10 Jan 2025 00:54:35 GMT

[quote userid="75734" url="~/f/nordic-q-a/117427/nrf5340-audio-dk-transmit-two-headsets-mic-data-to-one-gateway/517594"]I got some more updates from our developer as well, and now (as per this commit) 96kbps should be working again as well[/quote]

Simonr Thanks you again for auch a quick and awesome update!

I have one more interesting request: I'd like to let the gateway work as a USB audio dongle, that transmits the decoded stereo mic data to recording app like Aducity on PC thru its USB mic interface.

Several days ago, I had done this successfully on your old branch https://github.com/rick1082/sdk-nrf/commits/dual_mic_sample_2_4_2 after I did modified some code. it is true stereo recording, but it sounds a bit noisy, like below:

Here is the file I modified under old branch https://github.com/rick1082/sdk-nrf/commits/dual_mic_sample_2_4_2 :devzone.nordicsemi.com/.../audio_5F00_system.c
I am not sure if the code I modified is 100% correct or not. As I know, the USB output of gateway is more straightfoward and "Presentation compensation

" is NOT NEEDED by function audio_system_decode(), right?

Can you help give me an sample change under your new branch https://github.com/rick1082/sdk-nrf/tree/2t1r_mic_demo to also achieve the USB dongle stereo recording? That will be very helpful! Thanks.

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

Simonr — Thu, 09 Jan 2025 06:45:22 GMT

Hi again Lincoln

I got some more updates from our developer as well, and now (as per this commit) 96kbps should be working again as well.

Also, as of NCS 2.6.1, the packetcraft controller was deprecate, and all newer versions of the NCS use the SoftDevice controller. We can see the controller info from the log here:

-- [00:00:00.370,849] <inf> bt_mgmt_ctlr_cfg: Controller: SoftDevice: Version 6.0 (0x0e), Revision XXXX

So you're using the SoftDevice controller as well.

Best regards,

Simon

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

Simonr — Wed, 08 Jan 2025 15:04:48 GMT

We recommend 124kbps in this demo, as there is an issue with 96kbps that we have not been able to fix on our end.

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

lincoln-lu — Wed, 08 Jan 2025 14:49:32 GMT

[quote userid="75734" url="~/f/nordic-q-a/117427/nrf5340-audio-dk-transmit-two-headsets-mic-data-to-one-gateway/517459"]This is a controller issue that occurs at 96kbps bit rate I'm pretty sure. The developer in charge has updated the demo branch to avoid this, so please try doing a pull of the branch and test again. [/quote]

Yes, I just notice that your developer has commited new code to enable 124kbps, and removed 96kbps today. as below
#CONFIG_BT_AUDIO_BITRATE_UNICAST_SRC=160000
CONFIG_BT_AUDIO_BITRATE_UNICAST_SRC=124000

And I was using the code of 2025-01-07 https://github.com/rick1082/sdk-nrf/tree/2t1r_mic_demo that is defaulted to 96kbps.

Did you mean 96kbps still has known issue and you can not fix it so far? Which bitrate do you recommend then?

[quote userid="75734" url="~/f/nordic-q-a/117427/nrf5340-audio-dk-transmit-two-headsets-mic-data-to-one-gateway/517459"]In addition to this, the new SDC controller that took over from packetcraft, supports a different transport latency, so there's a chance that the data receiving form the gateway is out of order (L, L, R, R, L, R, R, L), so the old sample might not work as intended in NCS 2.9.0[/quote]

I have already been building code of https://github.com/rick1082/sdk-nrf/tree/2t1r_mic_demo by NCS 2.9.0 that was downloaded by VSCode NCS extention.
Can you tell me how to check if I am using the new SDC controller that took over from packetcraft?

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

Simonr — Wed, 08 Jan 2025 12:27:03 GMT

Hi Lincoln

[quote user="lincoln-lu"]I found the voice from left and right headsets are mixed together, instead of true "stereo". Is it because the HW codec CS47L63 on the Audio DK can ONLY support MONO DAC?[/quote]

This is the default behavior of the old sample that you have ported to 2.9.0, as this was a request from another customer at that time. You can check the last commit from that branch for details on what changes were made. Although, even removing the last commit, you'll likely still hear the mix of L and R from the gateway because of the CS47L63 only being able to output one channel, and the codec will mix L and R somewhat before outputting.

[quote user="lincoln-lu"]I see that 2 CIS connections are OK, but each time only one headset's mic data can be decoded by gateway.[/quote]

This is a controller issue that occurs at 96kbps bit rate I'm pretty sure. The developer in charge has updated the demo branch to avoid this, so please try doing a pull of the branch and test again.

In addition to this, the new SDC controller that took over from packetcraft, supports a different transport latency, so there's a chance that the data receiving form the gateway is out of order (L, L, R, R, L, R, R, L), so the old sample might not work as intended in NCS 2.9.0

Best regards,

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

lincoln-lu — Wed, 08 Jan 2025 08:00:44 GMT

Hi Simonr ,

I git cloned the code https://github.com/rick1082/sdk-nrf/tree/2t1r_mic_demo and built gateway and headsets images respectively on my 5340 Audio DKs,
I see that 2 CIS connections are OK, but each time only one headset's mic data can be decoded by gateway. See the log of gateway below

-- [*** Booting nRF Connect SDK v2.9.0-7787b2649840 ***
*** Using Zephyr OS v3.7.99-1f8f3dc29142 ***
-- [00:00:00.267,639] ^[[0m<inf> board_version: ^[[0;32mCompatible board/HW version found: 1.0.0^[[0m^[[0m
-- [00:00:00.299,743] ^[[0m<inf> fw_info: ^[[0;32m
^I nRF5340 Audio nRF5340 Audio DK cpuapp ^I^I^I    
^I NCS base version: 2.9.0 ^I^I^I    
^I Cmake run : Wed Jan 08 15:13:35 2025^[[0m^[[0m
-- [00:00:00.368,103] ^[[0m<inf> bt_mgmt_ctlr_cfg: Controller: SoftDevice: Version 6.0 (0x0e), Revision 8299^[[0m
-- [00:00:00.368,286] ^[[0m<inf> bt_mgmt: Local identity addr: CD:D4:EE:5A:50:14 (random)^[[0m
-- [00:00:00.396,514] ^[[0m<inf> unicast_client: NUS Client module initialized^[[0m
-- [00:00:00.396,575] ^[[0m<inf> main: Chmap lib version: 0.4.0^[[0m
-- [00:00:00.397,186] ^[[0m<inf> bt_mgmt_scan: All bonded slots filled, will not accept new devices^[[0m
-- [00:00:00.398,529] ^[[0m<inf> bt_mgmt_scan: Local addr: CD:D4:EE:5A:50:14 (random). May time out. Updates not printed^[[0m
-- [00:00:00.398,529] ^[[0m<inf> bt_mgmt_scan: Scanning successfully started^[[0m
-- [00:00:00.777,252] ^[[0m<inf> bt_mgmt_scan: Creating connection to bonded device: DE:9C:85:A1:E6:9C (random)^[[0m
-- [00:00:00.785,278] ^[[0m<inf> bt_mgmt: Connected: DE:9C:85:A1:E6:9C (random)^[[0m
-- [00:00:00.785,308] ^[[0m<inf> main: Connection event. Num connections: 1^[[0m
-- [00:00:00.835,235] ^[[1;33m<wrn> bt_conn: conn 0x20005670 failed to establish. RF noise?^[[0m
-- [00:00:00.835,357] ^[[1;33m<wrn> bt_mgmt: Security failed: level 1 err 9 ^[[0m
-- [00:00:00.835,388] ^[[1;33m<wrn> bt_mgmt: Failed to disconnect -128^[[0m
-- [00:00:00.835,418] ^[[1;33m<wrn> bt_gatt: conn 0x20005670 err 0x0e^[[0m
-- [00:00:00.835,601] ^[[0m<inf> bt_mgmt: Disconnected: DE:9C:85:A1:E6:9C (random), reason 0x3e ^[[0m
-- [00:00:00.835,632] ^[[0m<inf> main: Disconnection event. Num connections: 0^[[0m
-- [00:00:00.835,632] ^[[1;33m<wrn> unicast_client: Unknown connection disconnected^[[0m
-- [00:00:00.835,784] ^[[0m<inf> bt_mgmt_scan: All bonded slots filled, will not accept new devices^[[0m
-- [00:00:00.836,608] ^[[0m<inf> bt_mgmt_scan: Local addr: CD:D4:EE:5A:50:14 (random). May time out. Updates not printed^[[0m
-- [00:00:00.836,608] ^[[0m<inf> bt_mgmt_scan: Scanning successfully started^[[0m
-- [00:00:00.841,125] ^[[0m<inf> bt_mgmt_scan: Creating connection to bonded device: DE:9C:85:A1:E6:9C (random)^[[0m
-- [00:00:00.895,141] ^[[0m<inf> bt_mgmt: Connected: DE:9C:85:A1:E6:9C (random)^[[0m
-- [00:00:00.895,172] ^[[0m<inf> main: Connection event. Num connections: 1^[[0m
-- [00:00:00.945,098] ^[[1;33m<wrn> bt_conn: conn 0x20005670 failed to establish. RF noise?^[[0m
-- [00:00:00.945,220] ^[[1;33m<wrn> bt_mgmt: Security failed: level 1 err 9 ^[[0m
-- [00:00:00.945,220] ^[[1;33m<wrn> bt_mgmt: Failed to disconnect -128^[[0m
-- [00:00:00.945,281] ^[[1;33m<wrn> bt_gatt: conn 0x20005670 err 0x0e^[[0m
-- [00:00:00.945,465] ^[[0m<inf> bt_mgmt: Disconnected: DE:9C:85:A1:E6:9C (random), reason 0x3e ^[[0m
-- [00:00:00.945,495] ^[[0m<inf> main: Disconnection event. Num connections: 0^[[0m
-- [00:00:00.945,495] ^[[1;33m<wrn> unicast_client: Unknown connection disconnected^[[0m
-- [00:00:00.945,617] ^[[0m<inf> bt_mgmt_scan: All bonded slots filled, will not accept new devices^[[0m
-- [00:00:00.946,441] ^[[0m<inf> bt_mgmt_scan: Local addr: CD:D4:EE:5A:50:14 (random). May time out. Updates not printed^[[0m
-- [00:00:00.946,472] ^[[0m<inf> bt_mgmt_scan: Scanning successfully started^[[0m
-- [00:00:00.950,042] ^[[0m<inf> bt_mgmt_scan: Creating connection to bonded device: DE:9C:85:A1:E6:9C (random)^[[0m
-- [00:00:00.957,427] ^[[0m<inf> bt_mgmt: Connected: DE:9C:85:A1:E6:9C (random)^[[0m
-- [00:00:00.957,458] ^[[0m<inf> main: Connection event. Num connections: 1^[[0m
-- [00:00:01.047,424] ^[[0m<inf> main: Security changed^[[0m
-- [00:00:01.247,406] ^[[0m<inf> bt_vol_ctlr: VCS discover finished^[[0m
-- [00:00:01.617,614] ^[[0m<inf> main: Set members found: 1 of 2^[[0m
-- [00:00:01.617,736] ^[[0m<inf> bt_mgmt_scan: All bonded slots filled, will not accept new devices^[[0m
-- [00:00:01.618,713] ^[[0m<inf> bt_mgmt_scan: Local addr: CD:D4:EE:5A:50:14 (random). May time out. Updates not printed^[[0m
-- [00:00:01.618,713] ^[[0m<inf> bt_mgmt_scan: Scanning successfully started^[[0m
-- [00:00:01.625,396] ^[[0m<inf> bt_mgmt_scan: Creating connection to bonded device: DE:4B:0A:FC:D7:B8 (random)^[[0m
-- [00:00:01.636,169] ^[[0m<inf> bt_mgmt: Connected: DE:4B:0A:FC:D7:B8 (random)^[[0m
-- [00:00:01.636,199] ^[[0m<inf> main: Connection event. Num connections: 2^[[0m
-- [00:00:01.708,465] ^[[0m<inf> main: Security changed^[[0m
-- [00:00:01.938,476] ^[[0m<inf> bt_vol_ctlr: VCS discover finished^[[0m
-- [00:00:01.997,253] ^[[0m<inf> unicast_client: Service discovery completed^[[0m
-- [00:00:02.308,624] ^[[0m<inf> main: Set members found: 2 of 2^[[0m
-- [00:00:02.557,250] ^[[0m<inf> unicast_client: Discovered 1 source endpoint(s) for device 0^[[0m
-- [00:00:02.588,287] ^[[0m<inf> unicast_client: Service discovery completed^[[0m
-- [00:00:02.617,370] ^[[0m<inf> unicast_client: RIGHT source stream configured^[[0m
-- [00:00:02.617,370] ^[[0m<inf> le_audio: LC3 codec config for source:^[[0m
-- [00:00:02.617,370] ^[[0m<inf> le_audio: ^IFrequency: 48000 Hz^[[0m
-- [00:00:02.617,401] ^[[0m<inf> le_audio: ^IDuration: 10000 us^[[0m
-- [00:00:02.617,401] ^[[0m<inf> le_audio: ^IChannel allocation: 0x2^[[0m
-- [00:00:02.617,401] ^[[0m<inf> le_audio: ^IOctets per frame: 120 (96000 bps)^[[0m
-- [00:00:02.617,401] ^[[0m<inf> le_audio: ^IFrames per SDU: 1^[[0m
-- [00:00:02.767,303] ^[[0m<inf> unicast_client: Stream 0x20003190 started^[[0m
-- [00:00:02.782,989] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.783,996] ^[[0m<inf> audio_datapath: Drft comp state: CALIB^[[0m
-- [00:00:02.784,942] ^[[1;33m<wrn> audio_datapath: Data received, total under-runs: 5^[[0m
-- [00:00:02.786,956] ^[[1;33m<wrn> audio_datapath: I2S RX overrun. Single msg^[[0m
-- [00:00:02.802,978] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.822,967] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.842,987] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.862,976] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.882,965] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.883,972] ^[[0m<inf> audio_datapath: Drft comp state: OFFSET^[[0m
-- [00:00:02.902,954] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.923,675] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.925,964] ^[[1;33m<wrn> audio_datapath: Data received, total under-runs: 6^[[0m
-- [00:00:02.942,932] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.962,951] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:02.982,940] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.002,960] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.022,979] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.042,968] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.062,957] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.082,977] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.102,966] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.122,985] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.142,974] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.162,963] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.182,983] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.202,972] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.222,961] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.228,332] ^[[0m<inf> unicast_client: Discovered 1 source endpoint(s) for device 1^[[0m
-- [00:00:03.242,950] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.262,969] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.269,409] ^[[0m<inf> unicast_client: LEFT source stream configured^[[0m
-- [00:00:03.269,470] ^[[0m<inf> le_audio: LC3 codec config for source:^[[0m
-- [00:00:03.269,470] ^[[0m<inf> le_audio: ^IFrequency: 48000 Hz^[[0m
-- [00:00:03.269,470] ^[[0m<inf> le_audio: ^IDuration: 10000 us^[[0m
-- [00:00:03.269,470] ^[[0m<inf> le_audio: ^IChannel allocation: 0x1^[[0m
-- [00:00:03.269,500] ^[[0m<inf> le_audio: ^IOctets per frame: 120 (96000 bps)^[[0m
-- [00:00:03.269,500] ^[[0m<inf> le_audio: ^IFrames per SDU: 1^[[0m
-- [00:00:03.282,958] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.283,874] ^[[0m<inf> audio_datapath: Drft comp state: LOCKED^[[0m
-- [00:00:03.302,947] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.322,967] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.342,956] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.362,945] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.382,934] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.402,954] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.423,034] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.423,645] ^[[1;33m<wrn> bt_hci_core: opcode 0x206f status 0x0c ^[[0m
-- [00:00:03.423,980] ^[[1;33m<wrn> bt_hci_core: opcode 0x206f status 0x0c ^[[0m
-- [00:00:03.442,932] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.462,951] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.482,940] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.502,929] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.522,949] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.542,938] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.562,927] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.583,068] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.602,935] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.622,955] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.642,944] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.662,933] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.682,952] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.702,941] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.722,961] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.742,950] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.762,939] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.782,928] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.802,947] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.822,937] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.842,926] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.862,945] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.882,934] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.902,954] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.922,943] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.942,932] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.962,951] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:03.982,940] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:04.002,960] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:04.022,949] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m
-- [00:00:04.042,938] ^[[1;33m<wrn> unicast_client: Bad frame received, ch 1^[[0m

Here are the config files I used for gateway and headsets respectively, I just added CONFIG_AUDIO_DEV=2 and CONFIG_AUDIO_DEV=1 for them based on prj.config

devzone.nordicsemi.com/.../cis_5F00_gw_5F00_prj.conf devzone.nordicsemi.com/.../cis_5F00_hs_5F00_prj.conf

Can you look into the issue?

Thanks

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

lincoln-lu — Wed, 08 Jan 2025 00:37:47 GMT

Simonr Thanks for your support!

In fact, during your holiday weeks, I ported the code from the old branch https://github.com/rick1082/sdk-nrf/commits/dual_mic_sample_2_4_2 to NCS 2.9.0 by myself and it seem 'work' at some extend. I can hear the mic data from both left and right headsets on the headphone jack of the 5340 audio DK as Gateway.

Now one thing I want to confirm with you: I connected a stereo headphone to the gateway audio DK's headphone jack, in my left and right ears, I found the voice from left and right headsets are mixed together, instead of true "stereo". Is it because the HW codec CS47L63 on the Audio DK can ONLY support MONO DAC?

Thanks

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

Simonr — Tue, 07 Jan 2025 11:26:58 GMT

Hi Lincoln

So, the demo you link to is an old version with running on the packetcraft controller, which we are no longer able to support unfortunately.

However, one of our devs has made a newer version of the dual mic demo running in the nRF Connect SDK. It's available here, but please note that it is an experimental demo, so we do not have any warranty or guarantees that this project is at a production level quality, and if you decide to use it for development and/or production, thorough testing should be done on your end to make sure it is working as intended. I hope it is helpful, at least for demo purposes.

https://github.com/rick1082/sdk-nrf/tree/2t1r_mic_demo

Best regards,

Simon

RE: nrf5340 audio DK: transmit two headsets' mic data to one gateway

Simonr — Tue, 07 Jan 2025 08:47:38 GMT

Hi Lincoln

I'm so sorry, but it looks like this case fell through the cracks just before the holiday period here in Norway. We've been low on staff the last few weeks. We're now looking into this and will get back to you by end of week with some more information here as I have needed to run this by our developers.

Best regards,

Simon