It is possible to do send audio packets over BLE but there are no standard profiles in BLE that support this. You will have to implement your own custom service for this. You can probably follow this example instead - http://www.cypress.com/documentation/code-examples/ce222046-psoc-6-mcu-bluetooth-low-energy-ble-connectivity-ble-through… . This example demonstrates a custom service and tries to achieve maximum throughput. You can use the Server code to capture Audio sample and send the audio as part of notification. In the client code, process that packet and put on I2S for playback.
Having said this type of BLE streaming is not real-time as you record the packets and send it over BLE only on the next connection event. Unlike classic bluetooth which supports A2DP for audio streaming, BLE does not have a standard streaming service that handles synchronization of the packets. Hence rather than streaming I would term the implementation as Audio/Voice over BLE. Also, note that the BLE throughput with 2 Mbps is around 1.3 Mbps and the mono-audio of 16 Ksps with 16-bit data consumes 256 Kbps bandwidth. The 1.3 Mbps throughput does not include the application layer overhead (it is ATT layer throughput). Hence you may want to consider any additional overhead you plan on top of this.
Some other thoughts -
1. You can consider simple compression technique (like ADPCM) to compress the Audio - an example with PRoC device here: http://www.cypress.com/documentation/development-kitsboards/cy5672-proctm-ble-remote-control-reference-design-kit-guide
2. BLE supports IPSP and using which you can implement VoIP - something we have not tried but if you already have some expertise in that field, you can try that out as well
Let me know if this helps and if you have more queries.
Meenakshi Sundaram R
I am able to send audio from my phone to a psoc using ble.
The main thing I am wondering is whether it is possible to do this with multiple devices with a psoc as the master. ie. connect a master to multiple slaves and send audio to all of them.
Would you happen to know if this is possible or does the increase in data sent cause too much delay for the slaves to hear clear audio?
I have not tried but yes that is possible, you will have to run the audio (GATT) server in the master and audio (GATT) client in the slaves. Once the slaves subscribe/enable notifications you can push the data to all the slaves over notification. Now with proper compression, packet size, number of slaves and task split between the cores you might be able to feed all slaves.
For the best performance (just my thought ) you can probably try the below -
1. Implement BLE in M0+ (single core); implement the data acquisition (DMA preferably), processing in M4;
2. Prepare the packet in M4 and share it with M0+ (IPC pointer)
3. Based on the number of slaves connected and notification enabled, just post the packet to all the slaves notification queue (there is a separate queue for each connection, hence you dont have to worry about managing it).
For BLE, enable DLE (set Tx/Rx payload to 251) and use an MTU of 247 bytes (that lets you transfer 244 bytes of audio per LL packet). Enable 2 Mbps feature as well for even faster transfer. Choose an optimal connection interval based on rate at which data is produced by the PDM, the 244 byte you transfer per notification packet and number of slaves you plan (max 4). For instance, a 16-bit PDM output at 8 Ksps, produces 244 bytes (122 samples) in 15.25 ms. So for transmitting all that is recorded, your connection interval with the slaves should not be more than 15.25 ms. To transmit 244 bytes of notification data over the air or 251 bytes of LL packet over the air including the processing overhead might be around 3-4 ms @24 MHz M0+ (faster M0+ can improve the number but the part where BLE transmits is fixed - around 1.5 ms with 2 Mbps PHY). That means you might have a bit tight timing transmitting the data to 4 slaves with a 15 ms connection interval. You can consider having less number of slaves or reduced PDM data/bit rate or apply compression to reduce the number of bytes transferred.
Meenakshi Sundaram R