Clock synchronisation for wireless audio?

[Jon86]

I'm starting work on a project involving wireless digital audio transmission (hopefully using very the cheap and simple NRF24L01), and I've come across what could potentially be a bit of a snag.

If my ADC at one end is running off it's own internal clock, then the micro recieves the data, turns it into packets and sends it via the NRF24L01 to another micro, and outputs it to a DAC and an S/PDIF interface (obviously on a separate clock), won't the (even very slight) mismatch in clock frequency cause an issue?

Obviously I'll need some size of buffer, but if the ADC is clocked faster this will fill up and the output will lag behind, and if it's clocked slower the DAC on the output end will run out of data to convert.

It seems to me that clock synchronisation using these modules is out of the question, so I'm wondering if there's any way to fix this issue without using a different system for wireless transmission?

My only ideas so far are either: bin a few packets here and there to make sure the buffer is always the size it should be, or modify the sample clock slightly in response to buffer capacity. Neither of these seem like real solutions.

I thought this would be a fairly trivial task, as all I need to do is read a sample, transmit it, then send it to an ADC at the other end, but it seems to be getting a bit complicated.

Hopefully my thoughts make at least some sense and I can find a solution to this, Merry Christmas all!

[Jon86]

Would I be correct in thinking I can't recover the source clock because it's a packet based transmission system?

A sample rate converter (or the concept at least) did go through my head, but that seems like it'd have similar issues as I'm actually running two identical sample rates just with a slight error (that I'm unable to calculate). And like you said, it's big thing to get involved in.

I may well be getting into something I'm just not capable of doing at this stage, but it's a project I'm really excited about and I feel like there's got to be a simple way.

[nctnico]

The solution is simple: drop a sample or repeat a sample. Unless you play a perfect sine wave nobody will be able to hear it. Even when playing a sine wave you have to know where you are listening to in order to notice any effect. Every VOIP telephone works this way.

[Jon86]

That's great, exactly the answer I needed to hear.

I didn't expect that it'd be noticable at all, but considering it's audio equipment I wasn't sure if straight up dropping samples is just a complete no-no.

Am I right in thinking that if I'm using a 30ppm oscillator, I could get away with only dropping maybe 2 samples max per second?

44100 * 30ppm = 1.323  (x2, one for each oscillator)

I'll be using it for guitar so obviously I'm dealing with quite simple signals, but I'm sure some testing will quickly reveal whether this will be possible or not.

I'd imagine you could make the jumps less noticable by only doing it to samples very close to 0?

[fchk]

> (hopefully using very the cheap and simple NRF24L01)

Bluetooth audio does exist (even stereo hifi), and there are cheap transmitters and receivers. Why reinventing a square wheel?
Nordic and SiLabs are happy to sell you Bluetooth modules in case the commercial solutions don't work for you.

[Jon86]

Bluetooth would've been my first option, but since I need to transmit some other data on top of the audio, and I need a digital output, I thought I'd be making my life more complicated if I used a bluetooth system. Could easily be wrong there though.

The NRF24L01 seems super easy to build into a design, and there's a great deal of documentation/example code online already.

[SiliconWizard]

The NRF24L01 seems super easy to build into a design, and there's a great deal of documentation/example code online already.

The NRF24L01(+) is a great device, but it's very barebones. It only handles a very low-level protocol on its own, the rest is up to you. It doesn't handle frequency hopping on its own for instance, so you have to either implement that yourself or use a fixed channel, which is less than ideal. Just something to keep in mind. You may have found a ready-made library that handles this right. I remember Nordic used to distribute the "Gazell" protocol, I don't know if it still does nor what kind of license it is.

[David Hess]

If my ADC at one end is running off it's own internal clock, then the micro recieves the data, turns it into packets and sends it via the NRF24L01 to another micro, and outputs it to a DAC and an S/PDIF interface (obviously on a separate clock), won't the (even very slight) mismatch in clock frequency cause an issue?

It is a real problem but there are several ways to handle it.

Dropping or repeating samples is the easiest way if the clock rates are close.

Asynchronous sample rate conversion always works but is very processor intensive when the frequencies are so close together.

The output DAC can be phase locked to the source without too much trouble even when the packet stream is irregular.

Integrated USB audio output solutions often include two or more of the above solutions.