Hello again Proxy,
This isn't a very typical application for MQTT but it should be
possible.
I think one of the biggest design considerations is the latency you are
aiming for.
- Professional audio systems using AES67 can have latencies as low as 1
millisecond
- Apple's HTTP Live Streaming protocol (used by broadcasters) has a
typical latency of 10 seconds
Wikipedia says:
"VoIP systems typically have a minimum of 20 ms inherent latency and
target 150 ms as a maximum latency for general consumer use."
https://en.wikipedia.org/wiki/Latency_(audio)
So you will need to record the audio in 20ms chunks (for example),
encode it to GSM (or some other codec), then send it over MQTT.
The GSM audio codec uses a Sample Rate of 8khz and a bitrate of 13
kbit/s.
A GSM audio frame is 160 samples long - 20ms of audio and around 33
bytes of data.
On top of that is the MQTT Publish packet headers, including the topic
name - this will increase the overall packet length and bitrate. You
could reduce this overhead by increasing the latency.
Is this for a personal experiment, or building a product that lots of
people will be using?
If you are aiming to build a Voice over IP type application, then you
might be better off looking at SIP/RTP for streaming live audio - this
is what most VoIP phones use.
nick.
> --
> To learn more about MQTT please visit
http://mqtt.org
> ---
> You received this message because you are subscribed to the Google
> Groups "MQTT" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
mqtt+uns...@googlegroups.com.
> To post to this group, send email to
mq...@googlegroups.com.
> Visit this group at
https://groups.google.com/group/mqtt.
> For more options, visit
https://groups.google.com/d/optout.