I2S transcoder
Posted 7th July 2013 at 12:57 PM by abraxalito
Updated 16th September 2013 at 01:32 AM by abraxalito (Schematics added, pic of 2nd build added)
Updated 16th September 2013 at 01:32 AM by abraxalito (Schematics added, pic of 2nd build added)
Here's a circuit that's been a long time in gestation - some logic that converts I2S from 64fs (32bits per sample) down to 32fs (16bits).
Almost all the S/PDIF receiver chips nowadays output a bit clock at 64fs (2.8MHz for RBCD) because the format has the potential to support up to 24bits. When being driven from a CD player though, there's no chance of any useful information occupying those spare bits. As my interest is to run all signals as slow as possible to keep noise to the absolute minimum, 64fs to me is profligate generation of RF when 32fs will do the job. But only the WM8805 supports this format and then only when software programmed.
The other reason for wanting the slower bit clock is that my LAID design relies on shift registers and the 32fs clock gives me twice as good utilization of the serial storage - no bits are being wasted on zero padding.
This circuit is designed to do the job with the fewest standard logic chips I could manage it with - 8, at a total cost around $1. The 'traditional' way to implement such a design would be via serial-parallel and then parallel-serial conversion at half the original clock speed but the number of chips needed to go this route would be higher, mainly because latency is being introduced in the conversion to parallel, latency means storage and storage means chips. Here I present a way of doing this 'on-the-fly' with reduced complexity owing to the omission of any conversion to parallel. If for any reason you're concerned about latency (I'm not), then I reckon this is the lowest latency solution
The central core is 16 bits of shift register (two HC595s) with outputs tapped off into an 8-way mux (HC4051). 5bits of counter (HC161 plus a f/f) keep the mux and other logic sync'd to the incoming audio and increase the operative delay on a clock-by-clock basis. The result is a 'time stretching' function on the incoming datastream
Initial listening tests into a TDA1387 DAC give a more involving sound than when fed with 64fs but I'm blowed if I can put my finger on what the differences are. Needless to say I'm not going to feed any 16bit DACs in future with 64fs
Schematic notes......
IC list 74HC595 * 2; 74HC161; 74HC4051; 74HC86; 74HC04; 74HC74 * 2
For clarity, not all pins are shown. HC74 set/reset (1,4,10 & 13) to logic 1 when not shown. Preset pins on HC161 (3-6) are don't care, enables (7,9 & 10) to logic 1. HC595 MRs (10) to logic1. Unused inputs on logic gates should be tied to 0 or 1.
Update - I've added a photo of the 2nd build - here I've modified the design very slightly to accomodate the EIAJ serial format used by the TDA1545A. One HC74 has been replaced by an HC175 giving the extra cycle of delay to WS. I've also added an HC86 as a buffer stage, so the total's now 9 chips.
Incidentally I just used the SDcard player as a test bed for verifying its operation - I haven't noticed any SQ changes in driving the TDA1543. Recommended for CMOS DACs only
Almost all the S/PDIF receiver chips nowadays output a bit clock at 64fs (2.8MHz for RBCD) because the format has the potential to support up to 24bits. When being driven from a CD player though, there's no chance of any useful information occupying those spare bits. As my interest is to run all signals as slow as possible to keep noise to the absolute minimum, 64fs to me is profligate generation of RF when 32fs will do the job. But only the WM8805 supports this format and then only when software programmed.
The other reason for wanting the slower bit clock is that my LAID design relies on shift registers and the 32fs clock gives me twice as good utilization of the serial storage - no bits are being wasted on zero padding.
This circuit is designed to do the job with the fewest standard logic chips I could manage it with - 8, at a total cost around $1. The 'traditional' way to implement such a design would be via serial-parallel and then parallel-serial conversion at half the original clock speed but the number of chips needed to go this route would be higher, mainly because latency is being introduced in the conversion to parallel, latency means storage and storage means chips. Here I present a way of doing this 'on-the-fly' with reduced complexity owing to the omission of any conversion to parallel. If for any reason you're concerned about latency (I'm not), then I reckon this is the lowest latency solution
The central core is 16 bits of shift register (two HC595s) with outputs tapped off into an 8-way mux (HC4051). 5bits of counter (HC161 plus a f/f) keep the mux and other logic sync'd to the incoming audio and increase the operative delay on a clock-by-clock basis. The result is a 'time stretching' function on the incoming datastream
Initial listening tests into a TDA1387 DAC give a more involving sound than when fed with 64fs but I'm blowed if I can put my finger on what the differences are. Needless to say I'm not going to feed any 16bit DACs in future with 64fs
Schematic notes......
IC list 74HC595 * 2; 74HC161; 74HC4051; 74HC86; 74HC04; 74HC74 * 2
For clarity, not all pins are shown. HC74 set/reset (1,4,10 & 13) to logic 1 when not shown. Preset pins on HC161 (3-6) are don't care, enables (7,9 & 10) to logic 1. HC595 MRs (10) to logic1. Unused inputs on logic gates should be tied to 0 or 1.
Update - I've added a photo of the 2nd build - here I've modified the design very slightly to accomodate the EIAJ serial format used by the TDA1545A. One HC74 has been replaced by an HC175 giving the extra cycle of delay to WS. I've also added an HC86 as a buffer stage, so the total's now 9 chips.
Incidentally I just used the SDcard player as a test bed for verifying its operation - I haven't noticed any SQ changes in driving the TDA1543. Recommended for CMOS DACs only
Total Comments 28
Comments
-
Very nice little experiment - reminds me of an exercise I did some years ago, interfacing a CD player without volume control to the power amp with minimal circuitry. I steer well clear of preamps, and the PGA2320 volume chip looked like it might be an answer which was relatively transparent.
I didn't want to go down the microcontroller route - extra complexity, and the concern with digital fidgeting injecting noise, even though theoretically the processor chip could be put to sleep. So, implemented the logic totally in 74 series chips - just a rough breadboard with spare wallwart power supplies, and a couple of buttons, for Up and Down volume.
Worked quite nicely, considering rough power supplies, demonstrated to me that these volume chips are better than the better pots and perhaps, switching attenuators ...
FrankPosted 9th July 2013 at 10:36 AM by fas42
-
Its not just in theory that micros can be put to sleep - though with today's ARM chips the sleep mode isn't the lowest power as it keeps certain clocks running.Posted 9th July 2013 at 11:59 AM by abraxalito
-
Certainly an interesting circuit abraxalito!
I've recently been thinking about a circuit for sample clock for a SAR 1MSPS ADC ... it's data output is i2c/spi and the only hard part is to generate a single pulse to trigger sample then hold the sample pulse line low until after data is read.
I've been looking at binary counters and similar to achieve this from an OSC. Not come to an idea that I'm happy with yet. The propagation delay uncertainty on counter ICs looks a bit hairy and I'm not convinced I could achieve better with discrete logic gate (NOR, NAND, AND, inverter plus a bunch of flip flops would be needed) chips.
NXP says @5V to expect 20 - 35ns or @2V 60-190ns roughly for the HC161. That variance concerns me.
Have you done any analysis of the variation of those times and the impact on your circuit?Posted 9th July 2013 at 01:17 PM by hochopeper
-
Hmmm, I wouldn't be happy unless all clocks stopped ticking - but, there are always ways of achieving a complete shutdown of unnecessary electrical activity, so it's not really ultimately a problem.
Nice that you got the improvement with the slowdown - wouldn't it be great if one could insert an impressive metric of 'quality', rather than use expressions like "more involving sound" - might get a few people around here to tune in a bit more ... :D
FrankPosted 9th July 2013 at 01:21 PM by fas42
-
No, I haven't - the part I have is from TI and it only shows the maximum tp along with one typical. What was the concern you had - that it would vary over time/temp or part-to-part variations? I guess there'll be some jitter introduced but I haven't had any problems so far with jitter affecting SQ with my DACs.Quote:Originally Posted by hochopeper
Have you done any analysis of the variation of those times and the impact on your circuit?Posted 9th July 2013 at 02:41 PM by abraxalito
-
Variation over time was my concern, the variation from NXP is for t=25degC.Quote:Originally Posted by abraxalito
No, I haven't - the part I have is from TI and it only shows the maximum tp along with one typical. What was the concern you had - that it would vary over time/temp or part-to-part variations? I guess there'll be some jitter introduced but I haven't had any problems so far with jitter affecting SQ with my DACs.
For a 20bit ADC at 1MSPS I believe jitter will need consideration to ensure that it doesn't limit the SNR of the measurement ...
(not recording audio, just fooling around with the idea for a DIY electronics measurement tool)Posted 9th July 2013 at 11:34 PM by hochopeper
-
I saw your posting on the DIY ADC thread, this topic interests me as I plan to develop an SAR-based ADC at some point in the future - primarily for measurement purposes, but eventually for recording.
I don't believe that the figures in the DS about the variation of tp have much to do with short-term variation (i.e. jitter). I agree jitter's a concern - best addressed by using faster logic for this purpose. The lowest jitter logic is probably bipolar, or build this part yourself using discretes. For myself I'd probably kick off with something like LVC (low voltage CMOS) logic and then characterize the performance to see how much jitter was happening in practice.
If you're concerned about variation over time, that's over a rather long timescale I reckon so you feel jitter down to sub-millihertz is a matter of importance? I know Jocko says its important down to 0.1Hz...
Posted 10th July 2013 at 02:42 AM by abraxalito
-
Quote:Originally Posted by abraxalito
I saw your posting on the DIY ADC thread, this topic interests me as I plan to develop an SAR-based ADC at some point in the future - primarily for measurement purposes, but eventually for recording.
I don't believe that the figures in the DS about the variation of tp have much to do with short-term variation (i.e. jitter). I agree jitter's a concern - best addressed by using faster logic for this purpose. The lowest jitter logic is probably bipolar, or build this part yourself using discretes. For myself I'd probably kick off with something like LVC (low voltage CMOS) logic and then characterize the performance to see how much jitter was happening in practice.
If you're concerned about variation over time, that's over a rather long timescale I reckon so you feel jitter down to sub-millihertz is a matter of importance? I know Jocko says its important down to 0.1Hz...
Yeah I guess my comment on variation over time is a rather poor choice of words. I just meant that without an understanding of how that distribution is made up its a bit hard to know.
Knowing your passion for ARM processors, I think you'll be even more interested when you know that I'm planning on sending it all into an ARM AM3359 (perhaps via the PRU-ICSS if necessary)
A bit more reading and thinking to do at my end so I'll leave you to get back to i2s transcoding discussionPosted 10th July 2013 at 11:58 AM by hochopeper
-
Ah I see that ARM is well above my station being an A8. I don't consider TI being true believers in ARM either - they have prevaricated over M4s for what seems like an eternity because they are scared of cannibalizing themselves (their own DSP business). No matter, others truly dedicated to ARM for DSP are inexorably eating their business....
I reckon at 204MHz the LPC4320 (Cortex M4) would be fast enough to do useful work from a 1MHz ADC. Why go so far as an A8?Posted 11th July 2013 at 04:41 AM by abraxalito
Updated 11th July 2013 at 04:45 AM by abraxalito -
OK, I’m not an EE. I spent my career writing software. I’m retired now and I trying to learn how digital circuits work. Maybe I’m missing something but I don’t see how your I2S Transcoder can do anything useful. Did you really build it?Posted 15th September 2013 at 07:52 PM by Tam Lin
-
Yep - have built two incarnations now. I found my schematic has an error which I'll get around to correcting sometime, especially if anyone else wants to build it.Posted 16th September 2013 at 01:09 AM by abraxalito
-
Indeed, the design has a gross error. You’re lucky it works at all. You’re latching the I2S data on the falling edge of CLK. That’s when the data is changing and there is a lot of unrelated circuit noise. The data should be latched on the rising edge when the data is stable and most of the surrounding gates are quiet.
You’re handling of OE1/OE2 is a kludge. A wise engineer once posed this question to me: “When is a clock not a clock?” Answer: “When it comes from combinatorial logic.” TC is not a clock! If you need more bits use a wider counter.
You say you want to minimize circuit noise, RF, etc., yet you have a string of 5 inverters. One inverter is enough to do the job. Relying on propagation times to adjust the timing means the design is broken: Fix the design. Hacks like that have no place in clocked logic.
It may be clever but your transcoder is overly complex and poorly implemented. If your goal is the least number of standard logic chips then you missed the mark. I’m sure it can be done using fewer chips. I’ll post my solution when I have time.Posted 17th September 2013 at 07:52 AM by Tam Lin
-
Thanks for the comments - I look forward to seeing your fewer chip design, however I'm not holding my breath. I'm happy with all my kludges, I don't deny they're kludges but my aim wasn't to produce a design which passes muster as 'proper' synchronous logic.
Incidentally its not 'you're' rather 'your' - ironically, this is an example of the kinds of comments you've made about my design. You could patch your English to correct this mistake, just as I could patch my design to address my kludges. I can't see the point though, can you?
Back to your original remark - you still can't see how it does anything useful? Or have you now seen the light?Posted 17th September 2013 at 08:51 AM by abraxalito
Updated 17th September 2013 at 08:58 AM by abraxalito -
The I2S spec says nothing about the data setup and hold times relative to the falling edge of the bit clock. Your circuit could be latching the data from the previous frame, the following frame, or garbage. I say it's not useful unless it works, as intended, with all implementations of I2S. The fact that you had to add an additional cycle of delay proves my point.
My version of the transcoder: Four chips and ZERO latency! I haven't built it because I have no use for I2S. I just enjoyed the challange. All I have is an anotated timing diagram. I hope you can figure it out.
Posted 19th September 2013 at 06:40 AM by Tam Lin
-
I haven't tried to figure it out as your design fails on a number of points unrelated to whether it works as advertised. Let's assume that it does, however the power budget rules it out. Having looked at the DSs, the current draw for the total will typically be in excess of 100mA. Bear in mind that this design would typically be paired up with an S/PDIF receiver chip - they tend to run on 10-20mA typically so its power budget is way out of line with how it'll be used.
The second point it fails on is chip cost - a quick scan of TI shows you've spent slightly over $20 on your four chips. That's taking chips at 100+ prices (1k+ in the case of the 804), DIYers tend to order much smaller quantities.
Thirdly it fails as a DIY design because of lack of wide availability of the ALS804. According to TI, its only available in Asia but the link they supplied to a distributor did not work so I was unable to verify that.
I disagree with your claim that its (my design I'm speaking of now) only useful if it works with all I2S implementations, I'd observe its useful when functional. Its posted up here in the hope that if it turns out not to work in some implementations, I'll figure out why and the design will evolve.
So in conclusion, I accept you win on chip count, however your design loses on other major parameters, assuming that it does indeed work when built.Posted 19th September 2013 at 02:16 PM by abraxalito
Updated 19th September 2013 at 02:19 PM by abraxalito -
What planet do you come from? Findchips shows 35,183 ALS804 available from distributors, worldwide. In the US there are 705 ready to ship, in prototype quantities, from Avnet, Newark, Mouser, and Digikey, 157 in the EU from Farnell, and 173 in Asia from Element 14.
I chose the ALS parts because my goal was the lowest chip count and ALS has a higher ‘functional density’ than CMOS. I did a couple different variations with all CMOS but the chip count was higher. Incidentally, if you are willing to accept RC one-shots, I am not, you can eliminate the HCT74. If you took the time to understand my circuit you would realize the ALS804 can easily be replaced with a HCT08 and HCT04.
Regardless, latching a data bit on the falling edge of the bit clock is bad practice. And when transcoding in real-time, zero latency is best.Posted 21st September 2013 at 08:37 PM by Tam Lin
-
Update: I priced a 5-chip CMOS version of my transcoder. At quantities of 1 each, from US distributors that have the chips in stock, the total price is $6.05. Doing the same pricing for your original 8 chip version, the total is $1.14. For an additional Lincoln I’d prefer the design that follows best design practice and has zero latency. If you want to cling to your demonstrably faulty but less expensive kludge, so be it.Posted 21st September 2013 at 11:30 PM by Tam Lin
-
You're welcome to cling to your noisy, expensive low chip count paper design if you wish. I'll continue to listen through a quiet and cheap one.
Just as an aside, and this is most likely casting pearls before swine - if you'd like people to take time over understanding your designs, make them relevant to the context. Your approach is rather like the 'objectivist' amplilfier designers (Doug Self springs to mind) who go all-out on THD measurements but don't realize that amplifiers are to be listened through. So here you took chip count as an over-arching priority, despite noting in an earlier comment that I'm concerned about RF noise. Designs are an optimization process over all parameters not just the parameter the designer happens to like at the time. Since you used to be a software engineer I'd recommend 'The design of design' as a book you might gain insight from, from the writer of my favourite software book (Fred P Brooks).Posted 21st September 2013 at 11:40 PM by abraxalito
Updated 22nd September 2013 at 12:22 AM by abraxalito -
Good ref, Richard - I've picked up the gist of what he talks about from a number of reviews - and having been in the software game many years can only nod my head vigorously in agreement with his approach.
Interestingly, I was fortunate enough to be able to work like that over my whole career - I always had full control over design, and implementation of all projects - the spiral, or iterative, evolutionary method was instinctive for me. The key was having an excellent relationship with the crucial, knowledgeable and highly motivated, individual on the customer side ...Posted 22nd September 2013 at 02:15 AM by fas42
Updated 22nd September 2013 at 02:18 AM by fas42 -
Yes Frank, spot on there with your remark about the excellent relationship with the customer being crucial. Such a relationship maintains the reality - that its not about the numbers I can get (ego trip stuff), rather how many of the customer's requirements I can fulfill.
Speaking of the numbers game style of designing, Bruno's another one doing this. Over on his Mola-mola blog he admits getting the final few ppm out of the distortion figure he was getting for his DAC 'is a matter of pride' (i.e. ego). If he asked himself 'which customers will I lose if I leave it as it is?' he might be prompted to ponder further what the point of it was and whether by the excessive devotion to this single metric he was swallowing a camel while straining out his gnats.....Posted 22nd September 2013 at 06:55 AM by abraxalito
