nrf5340 audio DK setup as a broadcast source from USB looks like it's working but no audio transported.


ncs 3.1.1
trying to use VSCode to compile the LE audio project for an audio DK to run as a broadcast source with USB audio in and I'm possibly having a  build configuration issue?

I'm trying to just use one audio DK as a broadcast source, and get a phone (pixel 8) to point some LE audio earbuds (galaxy buds 2 pro) to the broadcast source and stream audio played by an app on my computer to the USB audio device that the audio DK provides the computer.. 

looking at the setyup instructions I made CONFIG_TRANSPORT_BIS=y in the prj.conf file and I have setup the build configuration to use the files relevant to the basic build target (audio dk)  and the debug version...

Everything SEEMS to work ok, that is the computer finds the USB audio device that the audio DK should be showing, and I can point audio at it. My phone finds the audio stream and will happily point the galaxy buds at the stream, and confirm they are hooked in, and will even show me when the stream pauses/starts on the button push on the audio DK. All LEDS on the audio DK are as expected.  BUT there's no audio in the earbuds. just silence when streaming the broadcast

I am getting this in terms of build problems... on one hand prj.conf (in project root I believe?)  is giving me two issues with variables. one is to do with the atrribute tx count which from what i understand would be nothing to do with the actual streaming audio transport -  then I'm also getting complaints this same named file in sysbuild\ipc_radio as not being used?? and I have another issue with what looks like a related attribute tx count variable in kconfig.gatt in the bluetooth stack code... plus some stuff related to debug logging. 

[{
	"resource": "/c:/ncs/v3.1.1/nrf/applications/nrf5340_audio/prj.conf",
	"owner": "kconfig",
	"severity": 4,
	"message": "CONFIG_BT_SECURITY_ERR_TO_STR was assigned the value y, but got the value n. Missing dependencies:\n(BT_SMP && BT_CONN && BT_HCI_HOST && BT_RPC_STACK) || (BT_SMP && BT_CONN && BT_HCI_HOST && BT_HCI && BT)",
	"startLineNumber": 33,
	"startColumn": 1,
	"endLineNumber": 33,
	"endColumn": 30,
	"origin": "extHost1"
},{
	"resource": "/c:/ncs/v3.1.1/nrf/applications/nrf5340_audio/prj.conf",
	"owner": "kconfig",
	"severity": 4,
	"message": "CONFIG_BT_ATT_TX_COUNT couldn't be set. Missing dependencies:\n(BT_CONN && BT_HCI_HOST && BT_RPC_STACK) || (BT_CONN && BT_HCI_HOST && BT_HCI && BT)",
	"startLineNumber": 79,
	"startColumn": 1,
	"endLineNumber": 79,
	"endColumn": 23,
	"origin": "extHost1"
},{
	"resource": "/c:/ncs/v3.1.1/zephyr/CMakeLists.txt",
	"owner": "nrf-connect",
	"severity": 4,
	"message": "__ASSERT() statements are globally ENABLED",
	"source": "cmake",
	"startLineNumber": 2232,
	"startColumn": 1,
	"endLineNumber": 2232,
	"endColumn": 2147483647
},{
	"resource": "/c:/ncs/v3.1.1/zephyr/subsys/bluetooth/host/Kconfig",
	"owner": "nrf-connect",
	"severity": 4,
	"message": "BT_SECURITY_ERR_TO_STR (defined at C:/ncs/v3.1.1/zephyr/subsys/bluetooth/host/Kconfig:418,",
	"source": "kconfig",
	"startLineNumber": 418,
	"startColumn": 1,
	"endLineNumber": 418,
	"endColumn": 2147483647
},{
	"resource": "/c:/ncs/v3.1.1/zephyr/subsys/bluetooth/host/Kconfig.gatt",
	"owner": "nrf-connect",
	"severity": 4,
	"message": "BT_ATT_TX_COUNT (defined at C:/ncs/v3.1.1/zephyr/subsys/bluetooth/host\\Kconfig.gatt:16,",
	"source": "kconfig",
	"startLineNumber": 16,
	"startColumn": 1,
	"endLineNumber": 16,
	"endColumn": 2147483647
},{
	"resource": "/c:/ncs/v3.1.1/nrf/applications/nrf5340_audio/sysbuild/ipc_radio/prj.conf",
	"owner": "Kconfig no context",
	"severity": 2,
	"message": "The active build context 'build/nrf5340_audio' does not use this file.",
	"startLineNumber": 1,
	"startColumn": 1,
	"endLineNumber": 1,
	"endColumn": 1,
	"origin": "extHost1"
}]



First up I guess - are these warnings even normal and expected for this project in this configuration or am I configuring the build wrong? (should I even be using VScode for this audio dk project??) 

Secondly I'm aware I'm trying to do something where the audio DK is just a tiny (but important) piece of a system with multiple computing devices running all sorts of code.... but I'm kind of stuck as to how to approach getting baseline behavior tested here as the whole thing is just weird out of the box. 

I guess I could modify the project to take analogue audio in and ruin a TRS cable form my laptop's headphone connector to the audio DK? that would chop out one source of issues (and add another) 

I do actually have three audio DKs I can use (which worked a while ago with a much more primitive example project that only worked via command line and might not have even been in a full SDK release... when I set them up as a 1 transmitter and 2 receiver setup that just linked together to work)
so I guess i could build a broadcast receiver to test myy tramnsmitter with - but from what i can tell that project has an auto join feature if I make a receiver and a transmitter with two audio DKs... so it's not really a test for my use case I'm trying to make work. 

Parents Reply Children
  • ok... thanks! I had not seen that the IDE was still a no-go for this, I assumed since it was now in the SDK it would work.... 

    Anyway, I managed to get the script compiling after a few attempts after doing a big uninstall of everything and starting again from scratch

    I don't know why but even though I went for one transmitter and two mono receivers for some reason it's saying the transmitter is MONO_AUDIO and it's completely ignoring one of my two "earbud" mode boards and just not programming it.... (but it IS building the code for it)  

    these were the two commands to build/program 

    python buildprog.py -c app -b debug -d both -t broadcast
    python buildprog.py -c both -b debug -d both -t broadcast -p


    and this was the output during compile and then programming... 

    +------------+----------+---------+--------------+---------------------+---------------------+-------------+
    |    snr     | snr conn |  device | only reboot  | core app programmed | core net programmed |   location  |
    +------------+----------+---------+--------------+---------------------+---------------------+-------------+
    | 1050148285 |  ←[33mFalse←[0m   | headset | Not selected |       Selected      |       Selected      |  FRONT_LEFT |
    | 1050118475 |   ←[32mTrue←[0m   | gateway | Not selected |       Selected      |       Selected      |  MONO_AUDIO |
    | 1050139490 |   ←[32mTrue←[0m   | headset | Not selected |       Selected      |       Selected      | FRONT_RIGHT |
    +------------+----------+---------+--------------+---------------------+---------------------+-------------+
    
    +------------+----------+---------+--------------+---------------------+---------------------+-------------+
    |    snr     | snr conn |  device | only reboot  | core app programmed | core net programmed |   location  |
    +------------+----------+---------+--------------+---------------------+---------------------+-------------+
    | 1050148285 |  False   | headset | Not selected |     Not selected    |     Not selected    |  FRONT_LEFT |
    | 1050118475 |   True   | gateway | Not selected |         Done        |         Done        |  MONO_AUDIO |
    | 1050139490 |   True   | headset | Not selected |         Done        |         Done        | FRONT_RIGHT |
    +------------+----------+---------+--------------+---------------------+---------------------+-------------+


    I have no idea why only one receiver board got programmed, but I do get audio from the eval board transmitter to the eval board receiver  at least, and I could use the button hold on reset trick for the receiver to swap the one that did get programmed from left to right... do you have any comments on if this basic compilation result is what should be expected for a BIS build? 

    I also get the LE audio stream discoverable on my phone and again able to be "connected" to my earbuds - and showing as playing or paused when I play and pause -  but still no audio from the actual earbuds..

    Now, I guess I need to try and see why the BIS mode on the audio-dk is compatible with the BIS earbud build of the demo program and their auto link up mode, not compatible with my pixel/samsung combination.

    Are there any clues to what that might be?? I figure I can't be the first person trying 3rd party testing with an audio DK here




  • I had a go at programming with the DEXTRA_CONF_FILE thing. it did seem to build ok from the command line, though when I went to program, it seemed to program the chip twice?? once with the merged_CPUNET.hex file the commandline build generated at the end, and then again with the merged.hex file form the exact same folder location

    FWIW my build and program commands were:

    west build -b nrf5340_audio_dk/nrf5340/cpuapp --pristine -- -DEXTRA_CONF_FILE=".\broadcast_source\overlay-broadcast_source.conf" -DFILE_SUFFIX=debug

    west flash --erase

    I tried to paste the programming results in here to show the duplicated steps with another file, but it won't post for some reason.. too big a snippet maybe? doesn't say, just won't let me insert it... 


    the programmed broadcast device runs, and communicated with the headset device fine, but I still cant get my phone/earbuds to play the audio even though they show the stream, show it connecting and show it paused/playing there's just no audio. (and that means no test tones either)  so its just the same as the one programmed by batch file... 

    PS I figured out the issue with the second headset not programming before... I had a bad USB cable. noticed when I moved the device and a whole bunch of folder windows opened up... 

  • Julian said:
    I also get the LE audio stream discoverable on my phone and again able to be "connected" to my earbuds - and showing as playing or paused when I play and pause -  but still no audio from the actual earbuds..

    Please try to add CONFIG_BT_AUDIO_PRESENTATION_DELAY_US=40000. The default presentation delay time might be too short for the earbuds since it was prepared for short end-to-end latency for both sides that are using nRF5340 AudioDK. 

  • EXCELLENT! thankyou very much. I added that to the end of prj.conf and the nrf5340 audio dk works as an auracast source for the earbuds now. 

    It's interesting that there seems to be no errors that come back for this setting being too low for the earbuds (at least not visible to the user on the phone) just the earbuds present no audio. I guess things are still a bit bleeding edge with LE audio even after a few years if general release

Related