Do you need 48KHz? If you're only doing 8-bit resolution, presumably sound quality is not paramount.

Halve, or quarter, the sample rate. 12KHz is easily good enough for speech. They only use 8KHz on landline telephone networks. Either discard 3 out of every 4 samples, or average them together. Add all 4, then bit-shift right, twice, for a quick divide by four.

Or you could implement ADPCM as the other poster mentioned. Or the simpler version, DPCM, that's pretty simple, really just the difference between each sample. You could look up a tutorial on it, or maybe get lucky and just paste in somebody else's code!

Since you're only doing speech, where low data rates are acceptable (and desirable), you can use the more simple compression techniques that are possible on a low-powered CPU.

well ultimately I would like to use a more professional compression as used in the most expensive professional wireless mics available. These opperate in 200kHz rf mask sub 1ghz. I am trying to find an open source alternative to Aptx live or commercial versions of opus. But for now while I get the diversity recievers working and timestamp packets working some kind of simple 4 bit low kHz stream will do,  then later I can try to implement CELT or another low latency 5ms frame compression in dsp either included on cortex M4 or perhaps a ti micro / dsp combination like Omap.. I think I will first try the IMA ADCP but first there is some figuring out of the I2S codec timing. I will try to figure out what timer this library is using so i can work out when to do the maths on the samples,  would you do the bit shifting,  maths,  throwing away of samples etc before they enter the circular buffer or afterwards? 

I'd do the decimating, throwing away the samples (actually don't know if there'd be a point in averaging them, but if you do...) just after you acquire them.

I dunno much about codecs, just that DPCM is nice and simple, simple enough for to understand without much experience. Just reading the main site and they mention Bruce Land has been busy again, creating a DAC from a programmable voltage reference. Anyway, his scheme uses DPCM.

https://hackaday.io/project/273-speech-playback-for-microcontroller

And being a professor, he does a nice job of explaining it. He only uses 2 bits for each sample. See if it's any help.

http://hackaday.com/2016/07/30/16-bit-audio-output-via-voltage-reference/

That's the article ^ .

Thanks greenaum, I'll check out bruce's DPCM codec .. basically the simpler the better for me ! just learning C so I don't mind if the audio sounds rubbish etc ! 1 bit 2bit is all good if it works then I can play about with timing,  ring buffers packetising timestamps etc.. a lot to learn here !

the other IMA adpcm link I posted was a red herring.. looks like I have a chance with this IMA_ADPCM library.. It builds in the arduino IDE as long as you include common.h from the files list. it even has encoder options for the samples input signed , unsigned. I'll try using this and report back here if it works

http://yxit.co.uk/source/documentation/classIMA__ADPCM.html

EDIT//

turns out all my shifting etc was working. I tried various differnt decimation techneques using just the passthrough and Serial.print(samples,BIN); which is nice to see the bit stream. It turns out the problem is with the RF driver locking up too much cpu time for anything to happen at all while it sends the packets.

So now looking into schedular library that is supossed to work in arduino zero and due

https://www.arduino.cc/en/Reference/Scheduler

Ah, sorry for the delay in replying. You got it then! 

From your (edited away) code, you look like you're quite new to this programming thing. Well done on creating a practical project and learning as you go, impressive.

Does it matter if the CPU is busy when sending the packets? You mean it's missing out on samples because it's busy? Hm, that's tough. You could use interrupts, maybe, to collect your data, but that might throw off the timing of the RF driver, it might not like being interrupted, since it's kind-of a realtime thing, must happen at specific moments in time. 

Can't think of a solution for that, but there's many wiser than me around here who might. Maybe use DMA to collect the data? Again, depends on how much of a hog the RF driver is, some comms stuff for Arduino uses exact delays coded in. That's assuming I'm understanding the problem. Good luck with it!

I'm using a circular buffer and the samples are entering being read from that buffer until rf24.semd(data,len); is called. disable this and you can even Serial.print 32bit audio samples in binary fliying out of the buffer ! impressive I thought for a little arduino !

So i was hoping that the buffer might ride out the blip in time when the 48 byte packet is sent. but it seams that the I2S audio coming in on SSC ( Synchronous Serial Controller ) is stopping. My latest thinking is that since the SSC is inturrupt driven perhaps the RF inturrupt is conflicting with SSC. In other words throwing inturupts at the same time. Since the SSC driver is bringing in say 22000 samples per second at 22khz in 16bit or 8bit. so timing is crucial for the RH_R24 library i'm using? I think the SSC driver is actually using DMA, but my knolledge of what DMA really is and how its working in the limited memory on an Arduino is zero ! All I know is it stands for Dynamic menmory Access and it can help move data around without hogging CPU ? anyway, I think I will try to read uint32_t ssc_get_status in the SSC driver and see what is actually returns. maybe that will give me clue. I tried the RadioHead forum , they wrote the RadioHead library , RH_R24 driver for the module) and they think the send( ); function is very fast. I'm not sure how I messure that in micros / millis yet, but will try. Yes i'm farily new to C programming. Slowly getting there :) just started to learn about passing variables into functions and classes, although I believe classes are more C++.  the arduino I2S driver is here, https://github.com/delsauce/ArduinoDueHiFi....... the SSC driver documentation is here and I think this holds the key to my timing mistery :) .. http://asf.atmel.com/docs/latest/sam.drivers.ssc.unit_tests.sam3x_ek/html/group__sam__drivers__ssc__group.html#ga8a68bfe46c95c426ef07be3ca618a54b

Ah... As far as DMA goes, it's "direct" memory access. Basically you set source and destination registers in the hardware, and a length register, then tell it "GO!". The DMA's hardware will then copy that many bytes from source to destination. 

At least, that's one use. DMA can do other, similar things. But basically it's hardware that does stuff to whole ranges of memory, one at a time. In the old days a DMA controller was a separate chip, now they're integrated into CPUs, but still work pretty much the same way.

While all this DMA is going on, your CPU is free to carry on, free of hassle. To check when your DMA transfer is finished, you usually check a certain address, or it might be hooked up to trigger an interrupt. DMA is one of the basic concepts a lot of computing hardware is based on, so it's worth learning, and isn't too horrible! I can see it coming in useful for this.

Your previous idea of a scheduler, I dunno if that'd help. Since, presumably, if the scheduler interrupted and temporarily halted the RF routine, the RF transmission might fail.

The prob seems to be the RF driver routine itself.  At least, that's my guess!

Often libraries are built on the very low-level stuff, then layers added on top. So maybe a simple hardware-driving byte send, then that code is used, called, by higher routines that do stuff like checksums, and re-sending if needed. The OSI networking stack model is an example of code like that.

So, perhaps you could use lower-level routines in your code, allowing you to send stuff in shorter bursts, or if not shorter, at least quicker cos you wouldn't be running as much of the overheads of the rest of the code. Of course that means you'd have to implement those higher functions yourself, but your application isn't too complicated in it's demands.

I dunno the routines in question, I'll have a brief look later on. Asking the people who are responsible for it, is just what I would have suggested too.

Maybe try with some dummy stuff? Sending dummy data, but at the same rate, same amount of data? To see if that's the problem.

As for the interrupts clashing, could be. Interrupts can be designed to tolerate being interrupted themselves. They just need to save any registers they use in their own code at the start of the interrupt service routine (ISR). Then restore them after. Interrupts are usually prioritised so that only a higher interrupt can interrupt another one. That might be something to check.

As you mention, classes are C++, and C++ is evil! Stay away, young padawan!

Well, I've been told it has it's uses. Perhaps it does. But the place for object-orientation is not the C language. Now computers are powerful enough to allow nice, friendly-looking languages, something bare and baroque like C isn't the place to start waving paradigms around. In my opinion. 

Anyway, not sure how much help this post of mine has been, but best of luck! Keeping at it, learning, and trying new things is the way forward, and that's what you're doing. Keep checking what's happening in the various parts of your code. Oh, and, rookie mistake (put my hand up), don't connect any hardware to pins 0 and 1 when you're using the Serial.print functions! Since it uses those for it's serial port. Very confusing bug, that was.

It's also worth checking for the odd misplaced ; or } , just in case. Can throw the path of your code right off.

Thanks for this advise , this helps to see the trees from the woods !

Think your totally correct about freeRTOS or other form of schedular etc. for a start freeRTOS requires all librarys used to be threaded capable etc etc .. and  I dought a lot of code i'm borowing from in githib etc is !

I did'nt know interrupts can inturrupt inturrupts, intersesting. One thing I read about the arduino Due is that Inturrupts are all set to priority 0. meaning they are all high priority. So that could also kill off the idea of the schedular doing anything perhaps. on the other hand if inturrupts can inturrupt inturrupts ( need a shorter way to write that ) maybe its possible the RF driver never gets to execute. the I2S code inturrupts it before it gets a chance to run. The code being to large ( slow )

happy you think I don't need to learn about c++ classes , I have to say as I began to study how they work I was thinking , '' this is the work of the devil '' I'm interested in low level hardware things , I dont want to get into high level application progrmaing ! Although I just needed to know roughly what classes where since i was looking at code like this in the arduino I2S library.

void HiFiClass::configureTx( HiFiAudioMode_t audioMode,
HiFiClockMode_t clkMode,
uint8_t bitsPerChannel )

I completely get that it might be a good idea to just send packets from a lower level without the library. I've done this before with TI's CC1101 RF modules and it was'nt to bad to figure out. I think loading the config for SI446x Chip will be a bit tricky but once the chip is initialized it might be plain sailing. interestingly the SI446x has a 64 byte buffer too.. so maybe this would help smooth the movment of samples too. I was planning on writing my own simple packet protocol ( or at least a simple timestamp to go along with the packets that the reciever can check up on )

I have since discovered that the SSC part of the I2S library i'm using seams to use DMA. I found;

//#if (SAM3XA || SAM3U)
#if (SAM3XA_SERIES || SAM3U_SERIES)
/**
* \brief Get Transmit address for DMA operation.
* \param p_ssc Pointer to an SSC instance.
* \return Transmitting address for DMA access.
*/
void *ssc_get_tx_access(Ssc *p_ssc)
{
return (void *)&(p_ssc->SSC_THR);
}

Due is SAM3X / SAM3A ... Up to 17 peripheral DMA (PDC) channels and 6-channel
central DMA plus dedicated DMA for High-Speed USB
Mini Host/Device and Ethernet MAC
Nice :)

and later in the code i found, Ssc *p_ssc being the pointer address to the DMA address returned from function void *ssc_get_tx_access() 

uint32_t ssc_write(Ssc *p_ssc, uint32_t ul_frame)
{
uint32_t ul_timeout = SSC_DEFAULT_TIMEOUT;
while (!(p_ssc->SSC_SR & SSC_SR_TXEMPTY)) {
if (!ul_timeout--) {
return SSC_RC_ERROR;
}
}
p_ssc->SSC_THR = ul_frame;
return SSC_RC_OK;
}

I'll keep examining the code to make sure this is the case. It is possible it just in the SSC code the was borrowed to write the library and yet its not being used of course.

I think like you say the next thing to try would be to write my own code to initialize the modules and write a simple sendRF(data_array,bytes); and recieve function.

like you say I could just send junk for testing and check to see if there are bits missing.

wait a minuete ! my 32bit binary samples are left justified. looking at the binary numbers converted somthing looks wrong. if I copy from uint32_t to a uint8_t with a bit shift of >>24 and mask & 0xFF I should get an 8 bit number. but i'm getting only 11111111 whatever the 32 bit number. How do you convert a LEFT JUSTIFIED 32 bit number to 8 bit ? do I need to right justify first ? and then >>24 ?

Ah, your 32 -> 8 bit problem looks like endianness. I think the ARMs can do either-endian, it's configurable (somewhere), but don't change it, just go with it!

As in, storing 0x12345678 could be stored that way in RAM, or as 0x78563412. There's reasons (and holy wars) for both ways. Do a binary dump of your 32 bit numbers to the screen, see where the relevant bits are. Might be you don't need to >>24, might be the relevant bits are already there.

Maybe the routine that provides those 32 bits stores them the opposite way, I dunno. You could work it out from the theory but you may as well just look! 

You say copying, you mean casting, right?

http://stackoverflow.com/questions/3133376/implicit-typecasting-in-c-converting-32-bit-unsigned-in-to-8-bit-u-int

Nice simple example, though in that case they're after keeping all 32 bits. You presumably need the most significant bits, and to chop off the 24 least significant. 

Actually the example here seems to be doing the same thing you are. So I think you need to see those bits!

Hi, just wanted to say I got it working. I took your advice and send 1 sample every 4. i did'nt average them since i want to work on a better compression later. my mistake was believing that this code was deterining if I had a packet recieved or not. turns out it was pumping out multiples of the same recieved packet !

if (rf24module1.available())
    {    
   uint8_t len = 48;
if (rf24module1.recv(packetmod1, &len))
    {

I numbered the packets now, so first byte in packet has a number from 1 to 25 and make a test that if packetnumber != packetnumber then ignore the packet :)

It audio sounds like rubbish of course but that is to be expected. the samples are being pulling in by the I2S codec from the recieved samples in the circular buffer and this appears to work ok.

Thanks for your help and ideas Greenaum , ben

Well done! Brains and information (the RIGHT information!) help, but persistence is 90% of it. Sorry for not replying for a while. Didn't think it had been so long.

Maybe now your radio problem's solved you could try sending the whole 48KHz after all. Remember to keep a copy of the software version that actually works, a known-working state is invaluable in debugging.

 Sorry that I didn't spot the problem. But again, well done. 

Yes I ment casting. Just examined the codec data sheet more closely. I have SIGNED 24bit LEFT JUSTIFIED in a 32BIT word. but the I2S 32bit word is unsigned. and its possibly non-endian or endian ! this is a puzzle !! I'm already printing the 32 binary and its looking like a 24bit binary sample LEFT justfied, was signed leaving codec but now coming in as unsigned 32bit... 

I'm working on a similar project, here are some things I found useful.

For general ideas about wireless audio streaming system, I found a detailed description in the user guide of the PurePath Wireless Audio with the SoC CC85XX by TI.

There is a possible lossy compression algorithm with almost no latency: IMA ADPCM, with a ratio of 4:1. The loss is white noise audible in some circumstances. The implementation in software is very simple, in hardware there is the VLSI chip VS1053. This chip implements also other compression algorithms (MP3), with better ratios, but more loss, distortion and latency.

Recent improvements of the ADPCM, more adapted to audio and with less noise, are the Fraunhofer Ultra Low Delay (ULD) techniques with few public research papers. It requires more computation, I found 20db less noise than the IMA ADPCM and this is inaudible.

Yes I have used the low latency codecs in CC85xx and eliminated the strange 300khz bias mic problem with the AIC3101 miniDSP coeficiants.. The VLSI has to much lantensy and 2.4ghz is not relieble for a professional radio mic since the higher frequncies dont propergate well through bodys. Lower UHF frequencys are far better for this although the bandwidth is limited at 200khz per audio channel.  APTx and Fraunhofer Ultra Low Delay (ULD) techniques are both commercial solutions for low latency realtime under 10ms encoding decoding end to end for exactly this problem. but they are commercial. CELT is open source but has been comsumed by OPUS and has compile support for ARM Ax and heavy CPU. I am more interested in low power CPU such as M3 or M4 Cortex etc since wireless mic batterys should last for as long as possible. does anyone know of a ULD open source codec that can encode / decode in 5ms frames ? maybe CELT can be used . but I could'nt get it to compile as of yet in arduino DUE as of yet.

just looked up IMA ADPCM and it looks like the m3 cortex could do it.  Not sure if the I2S SSC driver I'm using is using too much inturrupt time or not for the 32bit - 4bit IMA adpcm maths.. I'm thinking I could bit shift to 16bit signed samples then process to IMA adpcm 4 bit on the encoder side and the same in reverse on the decoder.. I could use the circular buffer store incoming samples and build packets with a simple time stamp for reordering on the reciever side.  Although the radiohead library might already be doing that at a lower level.  Will have to check. Does anyone know the best way I can check how much cpu time an inturrupt is using in arduino due? Need to see if the I2S library is a viable option for this. 

mainly due to the fact that 2.4 ghz has dropouts generally when mics move around I have decided to contine working on the project in UHF. more news shortly.