Depending on security requirements, you will need to use buffering to prevent audio issues.
But, essentially, if you want to receiver units to synchronize, you will either want to use broadcasting to ensure they both receive the packets simultaneously (anyone will be able to see these packets, not very secure), or you will need to connect to them in a round-robin fashion uploading the next chunk of audio data to each on connection, then proceeding to the next device. (Central and two Peripherals)
Your code on the receivers will need some method of time-tracking to ensure the audio streams remain in sync, buffering to allow for playback faster or slower than the communication medium (audio jack -> BLE, etc). This would involve: Receive chunk of audio data and timestamp for when to play it, synchronize time with Central device, start playing when time occurs and handle circular buffering of the audio or running out of data to playback.
If you don't care about security, you can try Broadcaster + 2 Observers, but for doing extended data packets for larger audio samples, you will want to do a Central device + 2 Peripheral devices, and have the Central multiplex the data to both of them in a time-sensitive fashion.
Thank you, it was a very helpfully answer.
I have now tested the project: Day030_Time_Multiplexed_Central from the 100 projects in 100 days blog, and it work very well.
But, we do not use heavy audio compression, so we need to transfer about 40Kbyte per. second to each device.
The CY8C4248 have 32K of SRAM, so the only way of minimizing the need for a huge audio buffer (in the receiver), is keeping the time multiplex interval as low as possible. But if I reduce the interval in the example to 100ms, I get devices are missing quite often.
Is there somehow to "lock" the Central and Peripheral devices, so they will not spend much overhead for scanning ect. ?
I believe you can save/store the scanned data for the associated device you want to connect to; This allows you to just attempt a connection without scanning first, but doesn't account for updated connection information. (Kind of like direct connect to an IP address instead of checking the DNS IP address first for networking)
Once you have scanned and found the two receivers the first time, you can then store/save the connection information and reuse it to do the time multiplexed connections without first doing a scanning period (this should cut down on timing by several dozen ms I would expect)