This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC3200AUDBOOST: System with two streaming devices

Part Number: CC3200AUDBOOST

Hi Vincent,

Is my understanding correct here?

In the wifi_audio_app mDNS advertiser is the speaker device which advertises with the service "CC3200._audio._udp.local." Then the MIC side uses sl_NetAppDnsGetHostByService to detect the speaker device including it's IP address and service port. Is there a reason for mDNS advertising to be done on the speaker side? I think that this can be done on either side. Based on this observation I decided to do the following. 

The streaming device 1 will advertise with the service "CC3200._audio_stream1._udp.local." at PORT 5050" The streaming device 2 will advertise with the service "CC3200._audio_stream2._udp.local." at PORT 5051. 

#ifndef MULTICAST          
                    lRetVal = sendto(g_UdpSock.iSockDesc, \
                                       (char*)(pRecordBuffer->pucReadPtr),PACKET_SIZE,\
                                       0,(struct sockaddr*)&(g_UdpSock.Client),\
                                       sizeof(g_UdpSock.Client));
                    if(lRetVal < 0)
                    {
                        UART_PRINT("Unable to send data\n\r");
                        LOOP_FOREVER();
                    }
 
#else   //MULTICAST

I think I can use sendto function from each streaming device to send the data out. 

On the receiver side I'll use GetServiceList() function or sl_NetAppDnsGetHostByName() to identify IP address of these specific device and the port of service. I can use recvfrom twice to receive each stream from their respective port. I can use receive function twice to read audio data from respective ports. 

Does this understanding make sense to you? 

Thanks

Shavinda 

  • Hi Shavinda,

    The idea behind the speakers advertising themselves on mDNS was that on each LP, the receiving task would be advertising its availability to act as a sink for audio data. 

    You are free to find other methods of connecting devices to one another, and having two devices each advertise a unique mDNS address could work. I don't see anything technically wrong with what you're planning to do, only that you will be losing flexibility due to the unique addresses. The idea behind the example is that both launchpads will be running the same code, and be able to fulfill both speaker and mic roles at the same time. 

    If you were to change the service names to something unique per launchpad, then you will be forced to modify the example code per launchpad, which is a bit onerous. If that was acceptable, then I do not see any issue with using your method.

    Let me know if you need more clarification or have further questions.

    Regards,

    Michael

  • Hi Michael,

    How do you suggest to modify the wifi_audio_example for the following system? I mean do you see a way with minimal code modification?

    The system will consist of two streaming devices which will source and stream a mono audio source. The audio sink (speaker) will receive both audio streams separately and output via the stereo channel as two independent audio streams.

    Thanks

    Shavinda  

  • Shavinda,

    You would need to modify the speaker task. Here you would need to be able to take audio from multiple sources and place them in the ring buffer. If these sources are mono, you should be able to place them as is inside the buffer, and then when you playback, you would setup the I2S for Stereo. Ideally, you would want to make sure you don't place 2 left channel audio streams right next to each other in the buffer because it will sound like the audio sped up. Perhaps you could do a buffer system that can Identify the stream, and ensure it alternates placing audio. This would be on you to implement though.

    Best Regards,

    Vince