Detect silence in S/PDIF stream / Quick'n'dirty S/PDIF decoder

[JJalling]

Hello all,

does anyone have an idea on how I can detect silence in a S/PDIF datastream? I'm building a class-d amplifier, and I want it to go into standby mode if no music has been played for a certain amount of time, and when music is detected, turn on again.

The S/PDIF stream is (for people who doesn't know) basically clock and data combined in a single datastream using differential manchester encodomg. The clock is just above 6MHz (for 48kHz audio).
My best idea right now is implementing a decoder in an FPGA or CPLD, but what about a microcontroller? Anybody who has a good idea?

Thanks
BR Jonas

[Yansi]

Don't explain us what is SPDIF, those who can/wish help will know.  Specify instead, if the class D modulator stage uses the audio signal in analog form, or you are directly processing the digital data into pulse width modulation. 

I have a feeling you have not much idea yourself what to do with the SPDIF data, do you?

The standard approach would be to convert the SPDIF to I2S stream (like using an DIR9001 or STA120 or whatever similar). Then feed this to a DAC and use a standard analog modulator type class D stage.

There is also a handful of microcontrollers that have SPDIF receiver peripherals built in (like for example STM32F446 - which is a great building block for a small decent audio DSP) - but I'd not recommend poking those if you do not have enough programming experience.  The MCU itself can do the detection of "silence" for you.

You can also tap the I2S data after the SPDIF decoder (if you feed the class D modulator the I2S data directly, without having them available in analog signal form) by using a small cheap MCU equipped with I2S slave peripheral and do the silence check there - it's easy. Any small 32bit MCU shall be equipped with I2S today.

[JJalling]

Yes for sure I know what SPDIF is - I have bitbanged it with a SPI controller on a pic, but what does it matter? And why does it matter if the modulator is digital or analog? When the amplifier is in standby, that stage is powered off anyway, so I can't use it for the decoding.

The SPDIF will be converted to I2S by a SRC4392 and then fed into a SHARC dsp, but both of them are powered off because if their relative high power consumption, when the amp is in standby.

The STM32F446 (somehow it didn't pop up in my search) is a possible solution, but I think it's a bit overkill - I was hoping for something in a smalish (3x3mm) package whith a low power consumption.

BR Jonas

[DaJMasta]

My original inkling would be to sample the analog output after conversion, because it's easy to deal with (could even be done all in analog) for this, but as you've mentioned, it leaves all the converters on.

However, I'm not sure you can easily get around this.  Unless you know the SPDIF coding well enough to get a micro bit-banging to identify dead air directly from the digital signal (which, especially if you're looking for very quiet but not necessarily all zeroed data could be very tricky), you're going to need to process it somewhat.  The SRC4392 doesn't actually have a huge power consumption - it could be left on, then it's much easier to get something to decode the I2S output and deal with it from there.

I think the smarter way would be to program the SRC4392 directly, it's got 4 GPIOs which if you can get some code in there, you can certainly use to power down the remainder of the amp when quiet.  Of course, I say that having never attempted to do so - I don't know how much capability those GPIOs have and how much access you really get to the main data stream.


It would be easier if the idling caused the SPDIF connection to terminate automatically or something, but if the connection is active, you'll need to sample it to see the silence at all, and unless you have a custom software solution, that seems to come in the form of dedicated decoders and Cortex M4 class micros... so you'd probably not be saving any power by putting an additional one in control of your main hardware.

[JJalling]

I think the smarter way would be to program the SRC4392 directly, it's got 4 GPIOs which if you can get some code in there, you can certainly use to power down the remainder of the amp when quiet.  Of course, I say that having never attempted to do so - I don't know how much capability those GPIOs have and how much access you really get to the main data stream.

Ahh, you've got a point. It might be possible to use one of the GPIO's on the SRC4392. Or otherwise tap it of, of the decoded I2S data.
Thanks!

BR Jonas

[Fungus]

The STM32F446 (somehow it didn't pop up in my search) is a possible solution, but I think it's a bit overkill - I was hoping for something in a smalish (3x3mm) package whith a low power consumption.

Aaaaand, that's the information that should have been in the original post. 


Could it be 6x6 mm instead? You can get some very small microcontrollers these days and that's what you know, so... 

[amyk]

I wonder if it could be done using all analog filtering, without ever having to actually decode the stream. The spectrum of an "active" SPDIF link would certainly look different from an idle or near-idle one.

[mikeselectricstuff]

I wonder if it could be done using all analog filtering, without ever having to actually decode the stream. The spectrum of an "active" SPDIF link would certainly look different from an idle or near-idle one.

Not easily  as it's manchester code, so hard to do much with in the analogue domain, even by looking at the spectrum.

[Yansi]

The STM32F446 (somehow it didn't pop up in my search) is a possible solution, but I think it's a bit overkill - I was hoping for something in a smalish (3x3mm) package whith a low power consumption.

Aaaaand, that's the information that should have been in the original post. 

The original post is very unclear.

The SPDIF will be converted to I2S by a SRC4392 and then fed into a SHARC dsp, but both of them are powered off because if their relative high power consumption, when the amp is in standby.

That should have been in the first post in the first place.

That way you still need any MCU capable of decoding the SPDIF by itself (ain't cheap or very small anyway), or using a dedicated cheap SPDIF to I2S decoder (or leaving the SRC4392 alive) and then using a small I2S equipped MCU (can be small and cheap, you might even find some 8bit ones I guess) to calculate the rms/peak value of the signal to do the silence detection for you, while leaving the powerhungry SHARC hungry and without power. 

[JJalling]

The STM32F446 (somehow it didn't pop up in my search) is a possible solution, but I think it's a bit overkill - I was hoping for something in a smalish (3x3mm) package whith a low power consumption.

Aaaaand, that's the information that should have been in the original post. 

The original post is very unclear.

The SPDIF will be converted to I2S by a SRC4392 and then fed into a SHARC dsp, but both of them are powered off because if their relative high power consumption, when the amp is in standby.

That should have been in the first post in the first place.

Why? It is not part of the PSU circuit, so why is it important to know what the PSU is powering, when the task is to find a suitable way to decode / detect a specific pattern in the SPDIF stream.

That way you still need any MCU capable of decoding the SPDIF by itself (ain't cheap or very small anyway) ...

So you are saying that it's not possible to do in software without HW support? I don't agree.

... or using a dedicated cheap SPDIF to I2S decoder (or leaving the SRC4392 alive) and then using a small I2S equipped MCU (can be small and cheap, you might even find some 8bit ones I guess) to calculate the rms/peak value of the signal to do the silence detection for you, while leaving the powerhungry SHARC hungry and without power. 

Why would you want to calculate rms/peak? The datastream is all zero, when music is not playing.

Ok, so instead of the question in the first post, let me ask another one: Does anyone have an idea of a suitable chip for decoding a differential manchester encoded datastream with a bitclock of 6.2MHz - this is _not_ related to SPDIF in any way.


Thanks

BR Jonas

[Yansi]

So you are saying that it's not possible to do in software without HW support? I don't agree.

Than stop asking us, go and make it work.

I agree it is possible to software decode it, but it is certainly not a clever nor economic idea. You'd need a very great amount of oversampling of the input signal, if you do not have a hardware support for that. The amount of processing power would get enormous to be able to do that reliably, leading to a beefy and not cheap MCU, that could possibly have the SPDIF HW receiver at the same pricepoint.

Why would you want to calculate rms/peak? The datastream is all zero, when music is not playing.

No it is certainly not. Zero maybe when the cable is disconnected, or the data source deliberately sends out zero samples.

If you are going to design the product that way, expecting zero samples, than screw you and your whole product.

Imagine I will use a humble 16bit audio ADC, converted to the SPDIF stream feeding your device. Do you think the ADC will produce all zero samples, when I will not feed any signal? 

Considering leftover -100dBFS noise from a signal source (regardless what source) as a valid signal to turn your amplifier on, I am sorry, but I don't think it is right.

Ok, so instead of the question in the first post, let me ask another one: Does anyone have an idea of a suitable chip for decoding a differential manchester encoded datastream with a bitclock of 6.2MHz - this is _not_ related to SPDIF in any way.

I've seen some devices from intersil, regarding this. Have a look there.
Like this. But I guess the humble STA120 or DIR9001 will still be the cheapest and simplest option.
http://www.intersil.com/en/products/timing-and-digital/microprocessors-and-peripherals/data-communications/HD-6409.html

[JJalling]

So you are saying that it's not possible to do in software without HW support? I don't agree.

Than stop asking us, go and make it work.

I was hoping that people had done something like it before, so I could get some inspiration. Sort of like the same way that you can use the SPI peripherals to produce SPDIF, maybe there was a similar way to decode it as well.

Why would you want to calculate rms/peak? The datastream is all zero, when music is not playing.

No it is certainly not. Zero maybe when the cable is disconnected, or the data source deliberately sends out zero samples.

Ok, I see your point.

If you are going to design the product that way, expecting zero samples, than screw you and your whole product.

Excuse me, what?

Imagine I will use a humble 16bit audio ADC, converted to the SPDIF stream feeding your device. Do you think the ADC will produce all zero samples, when I will not feed any signal? 

Considering leftover -100dBFS noise from a signal source (regardless what source) as a valid signal to turn your amplifier on, I am sorry, but I don't think it is right.

You are right - I have only used digital sources until now, and all of them send out zero samples when no music is playing. But you have a valid point I hadn't considered before, thanks

Ok, so instead of the question in the first post, let me ask another one: Does anyone have an idea of a suitable chip for decoding a differential manchester encoded datastream with a bitclock of 6.2MHz - this is _not_ related to SPDIF in any way.

I've seen some devices from intersil, regarding this. Have a look there.
Like this. But I guess the humble STA120 or DIR9001 will still be the cheapest and simplest option.
http://www.intersil.com/en/products/timing-and-digital/microprocessors-and-peripherals/data-communications/HD-6409.html

Well, considering your point about "analog" devices producing a SPDIF stream, I know understand why I can't find a simple chip that does the job.

So you suggest to tap the I2S data off of the SRC4392 and do some proper analysis of the audio data? Is this the "correct" way to do it, or am I missing somethin obious?

Thanks

BR Jonas

[Yansi]

No, dedoding the manchester using a software only solution is really not easy. That is also why there is a great amount of MCUs that can produce the SPDIF data stream, rather than decode it.  Also, usually the SPDIF transmitter peripherals are simple, the receivers are very complex peripherals, that either utilize a dedicated analog PLL to recover the bit clock, or use very high oversampling rates to sync to the stream (that's for example how the STM32F446 SPDIFRX peripheral works). 

As the SRC4392 really needs some power (like 0,25 to 0,3W), would it be a solution for you, to use a dedicated SPDIF receiver (DIR9001) to convert to an I2S bus, and thes use a different SRCxxxx chip that has also I2S input and output, to be able to switch it off, while having still the I2S data available?
If I remember the DIR9001 is quite low power (<70mW it seems), that should be left running with a small dedicated MCU, that could evaluate the I2S data.

But I guess it depends also on your budget for the project, if you can affor using a separate chip for the SPDIF decode, separate resampler and a dedicated MCU.

There are also other solutions there, like using a MCU with integrated peripheral SPDIF receiver. The MCU would decode the SPDIF and send out the I2S data. Then you could use the SRCxxxx after it, omitting the need of  separate SPDIF-to-I2S chip.

The STM32F446 also has enough grunt to run the ASRC algorithm inside, allowing to omit the SRC4392 entirely. The integrated SPDIFRX also has 4 selectable inputs I think. But this depends also on your abilities and enough developoment time for this solution.

Bottomnote: Considering that digital SPDIF sources will also produce only zero samples when not playing might be wrong too. Due to calculation inaccuracies, a small amount of noise might be produced for example in some audio processing filters, namely the ones using feedback paths (commonly used biquad cascade equalizers). Also, some audio sources might be only lower bit resolution (16bit), but utilizing noise shaping algorithms to increase the dynamic range a bit, for example at the "volume setting" output stages.

[mikeselectricstuff]

If it's a wake-up on audio thing, it may be feasible to wake up and do some sofwtware decoding to establish if audio is present, maybe using a SPI peripheral to do oversampled deserialisation, perhaps in conjunction with DMA - if you can DMA a long enough oversampled bitstream into a memory, you could decode it in non-realtime to find the sync pattern and then look for audio data.

[Yansi]

I think the problem with the SPI would be that you would not have enough oversampling. Not enough to reliably sync to the stream. But just guessing, never tried, as I think this is riddiculous to do.

For example in the manual for the SPDIFRX peripheral in the STM32F446 which works this exact way, utilizing digital oversampling of the input, they exactly state there should be at least 11x oversampling. I.e. for 12.288MHz symbol rate, you'd need at least 135MHz sampling clock.

Not many MCUs have SPI peripherals able to run more than 25MHz, even less of them over 50MHz.
(the above mentioned STM32F446 is a 180MHz Cortex M4, the integrated SPIs won't run over 45MHz)

[dmills]

How about going slightly sideways and shutting down on the absence of spdif carrier instead of silence? That would be a simple monostable with a time out of a microsecond or so, it will power down when you switch the source off.

Or use an SPDIF receiver and a separate ASRC (It is the ASRC that is power hungry) and power off on loss of lock or on the 'non audio' flag becoming set (A not terribly reliable way to avoid accidentally amplifying a Dolby bitstream, trust me you do that ONCE). 

Regards, Dan.

[Yansi]

That won't help anything either. I guess he wants to power down the majority of his device/amplifier, on loss of audio signal, not loss of the whole signal (that would indeed be very easy).

There are many applications in the wild, that require or it is useful for them to be equipped with  "wake up on audio" and "sleep when no audio".

For example imagine a large auditorium with active speaker reinforcement. You will not loose the AES/EBU (which is the professional SPDIF version) data streams to the speaker boxes from the main mixing desk, but it is still desirable to power the speakers and amplifiers down when there is no audio signal, rather than having a separate switched mains circuit for the amplifiers and active speakers on the walls.

[dmills]

That would wind me up no end (Speaking as an ex theater sound guy)...

Thing is, auditorium speakers often have huge dynamic range, and a mixing desk output will seldom be "digital black", simple mic amp self noise will usually see to that, and that is before we even mention dither, I want to have amplification available right down into the noise floor, and the power a set of idiling speakers consume is negligible compared to the lighting and air handlers..
Further I want the background noise to be constant, hiss that starts just before the cue is a lot more distracting then hiss that is there from when you walk in.

The usual answer is indeed to fit a contactor and kill the power when (actually 5 seconds or so before) the console is switched off, but you want the speakers on any time the console is powered up (Actually best practice is speakers on a few seconds after the console has come up, to avoid any thumps due to DC shifts as preamps and phantom rails become available).

The places you see this done (and it is acceptable) is home subwoofers, but even there switching off on loss of carrier makes better sense to me.

73 Dan.

[mikeselectricstuff]

I think the problem with the SPI would be that you would not have enough oversampling. Not enough to reliably sync to the stream. But just guessing, never tried, as I think this is riddiculous to do.

For example in the manual for the SPDIFRX peripheral in the STM32F446 which works this exact way, utilizing digital oversampling of the input, they exactly state there should be at least 11x oversampling. I.e. for 12.288MHz symbol rate, you'd need at least 135MHz sampling clock.

Not many MCUs have SPI peripherals able to run more than 25MHz, even less of them over 50MHz.
(the above mentioned STM32F446 is a 180MHz Cortex M4, the integrated SPIs won't run over 45MHz)

I don't think you need to sample that fast if you don't care about recovering a stable clock, which we don't for this purpose. Just looking at a 44.1KHz SPDIF signal on the scope, the shortest time interval between transitions is about 200nS.
If you sampled this at slightly more then 10MHz, the shortest bit would give 1 or 2 samples per bit, and the long bits would 3 or 4, and anything longer is the sync period.
 
In fact you may be able to go even lower than that - Silence encodes as a frame of mostly long bit-cells, so you may be able to use a capture peripheral to measure pulse lengths and use an avarage to filter out the few short ones in silent frames.

Actually I think it could be even easier than that. Assuming it is the case that silence always corresponds to mostly long bit-cells ( don't know if this is always the case but appears so in the system I'm looking at) , you could simply use 2 timers, one clocked by the SPDIF stream, to measure the avarage number of transitions in a given time.

I just tried plugging a SPDIF stream into my frequency counter. When muted it shows a stable frequency of 1.413MHz. This increases to about 1.9MHz when there is any audio.
 
You could probably even do this in the analogue domain using an edge-triggered monostable and avaraging the output.

Of course this latter would only work for a true digital silence, not an analogue signal going through an ADC, but with SPI at over twice the minimum bit time you could fully decode frames to determine level.

[Yansi]

That would wind me up no end (Speaking as an ex theater sound guy)...

Thing is, auditorium speakers often have huge dynamic range, and a mixing desk output will seldom be "digital black", simple mic amp self noise will usually see to that, and that is before we even mention dither, I want to have amplification available right down into the noise floor, and the power a set of idiling speakers consume is negligible compared to the lighting and air handlers..
Further I want the background noise to be constant, hiss that starts just before the cue is a lot more distracting then hiss that is there from when you walk in.

The usual answer is indeed to fit a contactor and kill the power when (actually 5 seconds or so before) the console is switched off, but you want the speakers on any time the console is powered up (Actually best practice is speakers on a few seconds after the console has come up, to avoid any thumps due to DC shifts as preamps and phantom rails become available).

The places you see this done (and it is acceptable) is home subwoofers, but even there switching off on loss of carrier makes better sense to me.

73 Dan.

You probably won't realize, but any sensible engineer would add timeout delays for the power off, when signal is lost. It will not power off whenever the signal is under -100dBFS or whatever the level would be set to. If the timeout is long enough, say tens of minutes, it really can not be distractive in any way.
I do not get the complaint about the hiss/noise - that really shall be inaudible. If it is so audible, I'd guess you have got something wrong in there. But I'd leave that maybe for a separate there, if you would mind?

Idling power is not small, just measure some active boxes. It might be few tens of watts per each (talking about such as FBT PSR212A, which have toroidal transformer power supply, class D bass amp and class AB/H high amp). That is not what I would consider small idling consumption, nor does it do good for the amp circuitry to be still under power - not only the power supply caps will likely give way faster, than if the gear would be powered off. (However I admit, from having the opportunity to service and repair few pairs of these boxes, that the long term reliability problems are really elsewhere, than in the power supplies).

Assuming it is the case that silence always corresponds to mostly long bit-cells ( don't know if this is always the case but appears so in the system I'm looking at)

That depends on the output signal offset. As the data are encoded as a two's complement, the samples may idle around 0x000000 or 0xFFFFFF, depending on the offset polarity. It might even fluctuate between these two.

[mikeselectricstuff]

Assuming it is the case that silence always corresponds to mostly long bit-cells ( don't know if this is always the case but appears so in the system I'm looking at)

That depends on the output signal offset. As the data are encoded as a two's complement, the samples may idle around 0x000000 or 0xFFFFFF, depending on the offset polarity. It might even fluctuate between these two.

If it is only ever 000000 or FFFFFF, frequency measurement would probably still be an option, as both would be very stable, so any variation would indicate presence of audio. If you have MCU hardware that can capture pulse lengths, then looking at statistics of those would probably give a good indication

[Yansi]

Then it might be worth a try. But I'd not call that the proper engineering solution.   
What does JJalling think about this pulse length measurement/statistics?

[mikeselectricstuff]

Of course it would be pretty simple to implement in a CPLD - as you don't need to recover a jitter-free  sample clock, a simple >2x oversampling method and state machine would suffice.
However ~10MHz SPI into a 32 bit SPI peripheral is only one transfer every 3.2uS which should be easy enough to read - maybe even decode in real time.
 

[Yansi]

I still think there might be a catch to it. The peripheral in the STM32F446 requires at least 11x oversampling for proper functionality, yet it does not recover any jitter free clocks (maybe only for itself). It just spews out the incoming data using DMA, as the buffers fill. There is no clock output out of the peripheral. (Sidenote: That's why it's a bitch to use that peripheral for real time audio processing, as you need an asynchonous resampling - exactly like the SRC4392 the OP uses - to sync the SPDIF to the local master clock. Still haven't figured out how to do the ASRC by software.)

Just out of my curiosity, what CPLD would you recommend? I don't know of any SMALL (low pin count), CHEAP ones. Altera has none, Xilinx almost none. 44 pin LQFP cannot be considered small, yet I know a fuckton of applications, where a small CPLD would be really a big helper. I don't know about Lattice parts. Have you used them? I have only used Altera MAX series CPLDs in the past, but they were 100 pin packages, nothing I'd recommend for this.

[mikeselectricstuff]

I still think there might be a catch to it. The peripheral in the STM32F446 requires at least 11x oversampling for proper functionality, yet it does not recover any jitter free clocks (maybe only for itself). It just spews out the incoming data using DMA, as the buffers fill. There is no clock output out of the peripheral. (Sidenote: That's why it's a bitch to use that peripheral for real time audio processing, as you need an asynchonous resampling - exactly like the SRC4392 the OP uses - to sync the SPDIF to the local master clock. Still haven't figured out how to do the ASRC by software.)

Just out of my curiosity, what CPLD would you recommend? I don't know of any SMALL (low pin count), CHEAP ones. Altera has none, Xilinx almost none. 44 pin LQFP cannot be considered small, yet I know a fuckton of applications, where a small CPLD would be really a big helper. I don't know about Lattice parts. Have you used them? I have only used Altera MAX series CPLDs in the past, but they were 100 pin packages, nothing I'd recommend for this.

There's a lattice XO2 in 32QFP, and LC4032/64 in QFP44 and 48. Not familiar with Xilinx but XC9536/72 would probably be what to look at.