Ditch Amanero and use this instead and go directly from USB to 16FS PCM:
https://www.diyaudio.com/community/threads/diy-stm32-usb-i2s-multichannel-board.425257/#post-7959052
No need for any discrete logic. No added ground bounce as it's done in software.
https://www.diyaudio.com/community/threads/diy-stm32-usb-i2s-multichannel-board.425257/#post-7959052
No need for any discrete logic. No added ground bounce as it's done in software.
I don't see any source code?
It correctly outputs the "simultaneous mode" data at BCK = 16 X FS for TDA1541?
It handles either IIS or SPDIF/AES-EBU input?
Thor
Yes, it outputs simultaneous 16FS BCK. I haven't yet tested with TDA1541. I need to blow the dust off my AYA DAC.
Input is USB audio stream (PCM). Direct conversion to 16FS PCM. No intermediate I2S and no SPDIF input.
Input is USB audio stream (PCM). Direct conversion to 16FS PCM. No intermediate I2S and no SPDIF input.
This should be trivial to remedy. It would make a big difference to a lot of people.
You can ask me how I did the "hack" on XMOS for ANY serial data in (IIS via HDMI, SPDIF, anything) with a local clock, no ASRC and re-using mostly the memory etc. from the USB Subsystem.
XMOS and ARM Core are radically different in a lot of ways, but it's likely that at a sufficiently high level of abstraction the ASYNC USB is all the same, with a memory buffer and flow control already programmed.
It just needs adding hooks and a way to input IIS/SPDIF etc. into the memory buffer instead of data from USB (fairly trivial) and an output from flow control to some form of frequency variable clock (VCXO?) to have a global system. Then the same outputs instead output massaged data from Optical, SPDIF or even IIS.
Thor
I2S input and SPDIF input are of course possible but would need changes to the board design.
I have another design with I2S output and input (2+2 channels). That board has also provision for SPDIF input.
I have another design with I2S output and input (2+2 channels). That board has also provision for SPDIF input.
@bohrok2610
May I ask how your implementation of the TDA1541 sim mode signals look like?
According to the datasheet, the pulse width of latch signal should be kind of between the samples, althought the Tfbrl and Trbfl can be zero, maning in case of continious bit clock, it should be 1/2 bit clk period wide:
I've implemented this mode in York first with the 'stop clock' mode, so that the latch pulse is between samples (purple one):
And then I also tried implementation with continious bit clock but the witdth of latch pulse is equal to one period of bit clock.
This is due to limitations of the MCU. Possible to overcome but requires use of different pin so I want to avoid. This is how it looks:
So far experiments show that TDA1541 is totally with that but need to run more experiments to make sure that LSBs are fine.
Can you please share your waveforms?
May I ask how your implementation of the TDA1541 sim mode signals look like?
According to the datasheet, the pulse width of latch signal should be kind of between the samples, althought the Tfbrl and Trbfl can be zero, maning in case of continious bit clock, it should be 1/2 bit clk period wide:
I've implemented this mode in York first with the 'stop clock' mode, so that the latch pulse is between samples (purple one):
And then I also tried implementation with continious bit clock but the witdth of latch pulse is equal to one period of bit clock.
This is due to limitations of the MCU. Possible to overcome but requires use of different pin so I want to avoid. This is how it looks:
So far experiments show that TDA1541 is totally with that but need to run more experiments to make sure that LSBs are fine.
Can you please share your waveforms?
You are reading too much from that TDA1541 datasheet timing diagram. Datasheet does not specify anything about the length of LE pulse. Only that "the converted samples appear at the output at the positive going transition of the latch enable signal". Even the bit clock edges can be aligned with LE pulse edges (0ns minimum tFBRL, tRBFL) so timing wise it seems quite lax compared to e.g. some DS dacs.
Same thing with other DAC chips using LE. E.g. in AD1862, PCM63 or PCM170x datasheets the minimum length of LE is specified, not maximum length. In those DACs LE falling edge is the trigger.
What TDA1541 datasheet timing diagram shows is a stopped clock operation. This is somewhat odd as the datasheet does not state anything else about it.
Same thing with other DAC chips using LE. E.g. in AD1862, PCM63 or PCM170x datasheets the minimum length of LE is specified, not maximum length. In those DACs LE falling edge is the trigger.
What TDA1541 datasheet timing diagram shows is a stopped clock operation. This is somewhat odd as the datasheet does not state anything else about it.
According to the datasheet, the pulse width of latch signal should be kind of between the samples, althought the Tfbrl and Trbfl can be zero, maning in case of continious bit clock, it should be 1/2 bit clk period wide:
Actually, let's look at the datasheet a bit more.
First, unlike the standard way of latching data on the rising edge of BCK, in SIM Mode each bit it latched on the falling edge.
Tfbrl, Trbfl, Thd;dat can all be zero.
Tsu;dat must be at least 32nS, thb/Tlb must be > 46nS.
Tcy must be > 156nS thus max BCK per datasheet is 6.41MHz.
First the implication of Trbfl is that when the falling edge of LE happens is immaterial. Wordselect (LE) hold is also stated as Zero in the TDA1541A datasheet (32nS in TDA1541 non A), meaning once the leading edge of LE/WS is processed what happens on LE is inconsequential.
We need to bring it low eventually to prepare the next LE cycle and this needs to happen at least 32nS before the rising edge, but how long LE stays high is inconsequential.
You can run LE directly as LRCK and I have seen hardware designs that work that way.
So for LE the ONLY thing that matters is the leading edge happens no earlier than the falling edge of BCK is below the threshold of the TDA1541.
The only timing that is relevant to the TDA1541 Jitter in SIM Mode is the LE rising edge.
My own conclusion is that if the LE rising edge is aligned with the BCK rising edge and LE goes low on the falling BCK edge after the MSB (that is when the bit after MSB is latched) all strictures are fulfilled. As we need to detect the MSB anyway to invert it, this minimises hardware logic or programming.
A further indirect conclusion, SIM Mode is likely the TDA1541 "native" format, so when using IIS input additional logic is inserted that converts IIS to SIM internally and BCK runs faster. This logic likely adds additional noise & Jitter on top of what happens in SIM Mode.
Which together with being able to use the slowest BCK and the most limited edge rate makes SIM Mode very desirable when operating the TDA1541, so the option of using 16 Bit IIS while better than nothing, is still too subideal. But it provides a fallback.
As @bohrok2610 does not provide the code under open source nor is there an IIS input, I do not think his design is valid for my context.
So I will continue on the route with a simple HW only solution. Using a CS8412 DIP Footprint and Amanero footprint (X 2) will in my view still provide the greatest flexibility in leveraging PRC sourced items that can defray additional costs materially.
We can get BT/USB 2 IIS (96k/24 max) on Amanero Footprint, USB2IIS on Amanero Footprint (768k/32 max) and WM8805, CS8416, AK4118 and others on CS8412 adaptors. Placing the footprints for a CS8416 & 8-Pin MCU under the CS8412 footprint gives a default solution that can be populated at a PSBA vendor like JLCPCB.
Thor
That hurts less than indirect abuse 🙂 Seriously, don't expect stuff stays within a predefined circle.
Also another reason is the rather strange "Intellectual Property Rights" clause in Forum Rules.
I may be misinterpreting that clause but to me it sounds like jean-pauls would have the IPR 😱
I may be misinterpreting that clause but to me it sounds like jean-pauls would have the IPR 😱
You are correct but still I can have some control. In GitHub it would soon end up in something you can buy at eBay, Taobao or Aliexpress.
From your posts. Do you have the Code on GIT?
There is that. But is that a bad thing? Few people have the skills to make these PCB's by themselves, flash the firmware and all.
Unless of course you personally expect to profit by selling complete boards, with firmware flashed, which is fine, of course.
Thor
Last edited:
By definition open source does not require GIT.
No, I have no intention on selling complete boards. But if no group buy is arranged I may assemble boards for somebody in need.
Seems you are right. Yes, for AD1862/PCM63 it is true, I wasn't sure about TDA1541.
Thanks!
True. It's just what a lot of people use for both open and closed source development.
Hmm, it may be easier to let China do it. Just saying... You can figure out what the margin's are on those boards.
They are usually made by one man shops, perhaps accessing a friends PCBA for a friendly price and nobody is getting rich.
Yes, it would be nice if Chinese asked for permission, but the concept of intellectual property as we have doesn't really exist in their minds and culture (for ordinary Chinese). If someone copies you they think your work/way is better than their own which is high praise.
BTW, not having a go, just saying...
Thor
I'm quite sure China-made boards would not use same components as I have used. Same goes with the multitude of chinese Amanero clones. The unsuspecting buyer thinks he is getting almost the real thing.
Here is a good example of this approach: https://vi.aliexpress.com/item/1005007461262762.html
It's a copy of an open source design. What they don't tell you is that some of these clones use a slower speed-grade FPGA which makes them unusable for the intended purpose (USB HS). From the picture it is impossible to tell if that is the case.
So it does not work? Return for refund.
I had a number of fakes of Ali. I opened a dispute, made my case and was given a refund. Without having to send the fake stuff back.
Thor
I haven't bought it so nothing to return. I've only read about the faulty boards somewhere in the internet.