WM8731 codec ( audio codec shield ? )
benbiles opened this issue · 6 comments
Just wondered how hard it would be to add a codec support like the WM8731 to RF24Audio?
would be nice to have to have 24bit 48k audio streamed from one arduino Due / RF24Audio to
another arduino / RF24Audio?
I found this https://github.com/delsauce/ArduinoDueHiFi which I think supports the codecs I2S over I2C
might be a nice addon for people that want more than 8bit audio ?
In its current form, probably not worthwhile, since there is no Due/ARM
support, and I have no immediate plans to develop it. I would also suggest
a completely different process, likely using ack payloads, if looking for
high quality one-to-one audio, since the current library mainly
demonstrates the multicasting capabilities of the radios on AVR devices.
Technically, the radio portion of this would be relatively straight forward
with a one-to-one config, (auto-ack = clean, digital audio, minimal
errors,lower transfer rates, multicasting = higher error rates, lower
quality audio with no error correction for timing, etc. ) however, audio is
complex, so extra features and higher quality audio requires more attention
to the details, and can add complexity to the code.
On Thu, Mar 19, 2015 at 8:31 PM, ben biles notifications@github.com wrote:
Just wondered how hard it would be to add a codec support like the WM8731
to RF24Audio?
would be nice to have to have 24bit 48k audio streamed from one arduino
Due / RF24Audio to
another arduino / RF24Audio?I found this https://github.com/delsauce/ArduinoDueHiFi which I think
supports the codecs I2S over I2Cmight be a nice addon for people that want more than 8bit audio ?
—
Reply to this email directly or view it on GitHub
#6.
I found RF24 has auto-ack on by default but I suppose like you say there is more detail in streaming high quality audio. RTP works in a wi-fi network well but has little or no error correction ( essentially UDP )? so what more attention to detail would add complexiy to the code? If the I2S data from codec could be passed direct to the RF24 library and streamed over the link in byte chunks then it would work? is it the buffer, fifo / memory that would be a problem? or clock / sample rate etc ?
trying to understand what the challenge would be.. any pointers in the right direction would be awsome !! it seams overkill to run an entire OS ( linux ) just to stream digital audio packets from A - B. I'm trying to make a low power battery application..
I'm thinking make byte chunks in an array and send them with NRF24 and include timestamp and use no error correction. only drop data that does not make it within a timeframe?
maybe I should try and write a library from scratch or do you think I should try to use NRF24 ?
RF24 core lib does support ARM devices. To be perfectly honest, I don't
want to get into all the technical aspects, but the main issue with
streaming audio to multiple devices is the timing. There will always be
slight variations in timing between device A and device B, so any audio
streaming needs to deal iwth this. There is usually more than one way, so
the 'best' method is generally dependant on your application requirements
and overall design.
On Thu, Mar 19, 2015 at 10:23 PM, ben biles notifications@github.com
wrote:
I found RF24 has auto-ack on by default but I suppose like you say there
is more detail in streaming high quality audio. RTP works in a wi-fi
network well but has little or no error correction ( essentially UDP )? so
what more attention to detail would add complexiy to the code? If the I2S
data from codec could be passed direct to the RF24 library and streamed
over the link in byte chunks then it would work? is it the buffer, fifo /
memory that would be a problem? or clock / sample rate etc ?
trying to understand what the challenge would be.. any pointers in the
right direction would be awsome !! it seams overkill to run an entire OS (
linux ) just to stream digital audio packets fro A - B. I'm trying to make
a low power battery application..—
Reply to this email directly or view it on GitHub
#6 (comment).
Hi, thanks for replying to me. I'll try and learn more about the timing, clocks, sample rates etc and see where that takes me ! someone wrote a library for the mega and codec shield and adjusted the timing for it, maybe I can learn from that..
Np, one of the reasons I suggested using ack payloads is that it can eliminate problems with timing by having the receiver request the data from the transmitter as needed, but is only good for a one-to-one configuration. This is how my original streaming code worked as per the file here https://github.com/TMRh20/TMRpcm/blob/3703e03b2a14c454378802e676bd53695205502b/TMRpcm/pcmRF.cpp but the data-rate is limited to ~48KB/s @ 1MBPS and ~67KB/s @2MBPS
Of course there are other ways of doing things, this is just one option.
OK, think I understand the advantage of the reciever pulling data from tx. will stdy your code and try and understand it ! not sure I understand how to pull audio data with ack payloads yet..