Is it realistic to stream 12-16 bit audio through SPP bluetooth in realtime?

Question

I have tried to send 12-bit audio to be listened to in real time through the HC05 SPP bluetooth module hooked up to an arduino and DAC over serial with a python RFCOMM socket. I have since learned that Serial Port Protocol is not very great at all for this purpose due to its low bandwidth. I figured I could definitely send the data and then play it out through a DAC, but I doubt an arduino would hold an array the size of a WAV file and maybe not even an mp3 file, but that would defeat the purpose of controlling the audio (play,pause,rewind,etc) from my computer. Would it be more realistic and worthwhile to use an A2DP enabled bluetooth module? Or is it still possible to listen to acceptable quality 12-16 bit audio in real time with SPP? I have tried to use lower bit songs, adjusted baud rates for the arduino and HC-05 serial ports, and tried to adjust the magnitude of the values outputted by the DAC to the audio port and I still seem to get crackly audio. It seems the problem comes down to the low bitrate transfer speed of SPP, or am I wrong?

Answer 1

Is it realistic to stream 12-16 bit audio through SPP bluetooth in realtime?

Sure, at some awfully slow sample rate <= 8 kHz. You'd be better off sending 8-bit audio at a higher sample rate.

Would it be more realistic and worthwhile to use an A2DP enabled bluetooth module?

Yes, absolutely, without question. That's what it's designed for, as I mentioned in your other question.

Or is it still possible to listen to acceptable quality 12-16 bit audio in real time with SPP?

Acceptable is subjective. If it's just voice, you can get away with it. If you want reasonable audio quality for music, almost universally, no, it's not acceptable.

It seems the problem comes down to the low bitrate transfer speed of SPP, or am I wrong?

Without any code to inspect and debug, it's impossible to say what the specific problem is that you're referring to. Undoubtedly, the low bandwidth will not enable good quality audio anyway.

If you must continue to use SPP and simple codecs like PCM, at least use differential PCM to save a bit more bandwidth.