I am going to use a different regulator for the 3.3v which will have its own rectifer and filter.
Was planning on having them all turn on at once.
To be safe should one use a separate switch for the 3.3 to allow the +- 5 volts regs to be up and stable? Is one second critical or does if make any difference other than it be delayed at least 1 second?
Was planning on having them all turn on at once.
To be safe should one use a separate switch for the 3.3 to allow the +- 5 volts regs to be up and stable? Is one second critical or does if make any difference other than it be delayed at least 1 second?
Power should all turn on at the same time, the one second delay is created by the uC so the audio clock is running (fpga programmed) before turning on the audio.
Søren, Not easy to do but do you think if the inverter OPAMP was run on +/-5v rails rather than single supply this would fix the problem?
I'm supplying the +-5V through J1 (my onboard 5v regulators are "bypassed")... so I intend to stuff my two bleeder resistors on the -5v 100uF cap as well as at J1 itself... hopefully that helps this.
I'm fairly certain it's the condition that Soren described earlier. The SMD caps for the reference -4v near J6 discharges fairly quickly so the problem must be elsewhere?
I can't read any of the markings on the transistors can you let me know which is the inverting opamp (the part number would be great for me to read the datasheet) near J8? I tried probing the pins of the transistor near J8 but all I get are my +5v value input as well as +4.025v and +3.982v or close to 0v for the rest of the pins. (all positive values?) When the board fails to start properly the +5v is still there but everything else is basically 0v.
I'm trying to find the cap that is keeping the negative reference charged up on power down (unless I've totally misunderstood - which won't be surprising
)All, sorry for derailing the thread suddenly with this odd start-up problem I'm having. FWIW, the first board with all the mods sound really good and I intend to have a comparison with an AYA II as well as a more stock version of the DAM1021 from another local DIYer (hopefully soon!).
Last edited:
I'm supplying the +-5V through J1 (my onboard 5v regulators are "bypassed")... so I intend to stuff my two bleeder resistors on the -5v 100uF cap as well as at J1 itself... hopefully that helps this.
I'm fairly certain it's the condition that Soren described earlier. The SMD caps for the reference -4v near J6 discharges fairly quickly so the problem must be elsewhere?
I can't read any of the markings on the transistors can you let me know which is the inverting opamp (the part number would be great for me to read the datasheet) near J8? I tried probing the pins of the transistor near J8 but all I get are my +5v value input as well as +4.025v and +3.982v or close to 0v for the rest of the pins. (all positive values?) When the board fails to start properly the +5v is still there but everything else is basically 0v.
I'm trying to find the cap that is keeping the negative reference charged up on power down (unless I've totally misunderstood - which won't be surprising
All, sorry for derailing the thread suddenly with this odd start-up problem I'm having. FWIW, the first board with all the mods sound really good and I intend to have a comparison with an AYA II as well as a more stock version of the DAM1021 from another local DIYer (hopefully soon!).
Ristar, PM sent. I have solved the startup issue on my board but my fix may not be suitable for you.
Just an update that bleeder resistors only on the negative rail didn't help matters. But it's definitely the situation that Soren described.
Without the negative rail connected, the fpga starts up properly every single time.
The transistor at J6 (courtesy of wineds) is not getting the signal (from uC? if inverter opamp where is it?) to start sometimes... on unsuccessful attempts it's at essentially 0v on successful starts it's between 0.5 to 0.6V
It's really odd because the power for both +-5V comes on instantaneously (and now the negative rail powers down just a tad faster). So somewhere on my second board the negative voltage is holding charge.
Spikestabber can you share your muting circuit that's based on the diode? wineds has showed me a way to force the transistor to always power on, obviously that means that potentially I could get DC on outputs on start and maybe even on relocks.
Without the negative rail connected, the fpga starts up properly every single time.
The transistor at J6 (courtesy of wineds) is not getting the signal (from uC? if inverter opamp where is it?) to start sometimes... on unsuccessful attempts it's at essentially 0v on successful starts it's between 0.5 to 0.6V
It's really odd because the power for both +-5V comes on instantaneously (and now the negative rail powers down just a tad faster). So somewhere on my second board the negative voltage is holding charge.
Spikestabber can you share your muting circuit that's based on the diode? wineds has showed me a way to force the transistor to always power on, obviously that means that potentially I could get DC on outputs on start and maybe even on relocks.
Are the i2s limitations of the rpi listed in this post applicable to the dam?
https://hifiduino.wordpress.com/2014/11/13/raspberry-pi-b-digital-audio/
https://hifiduino.wordpress.com/2014/11/13/raspberry-pi-b-digital-audio/
I believed in derekr, and justed playing with Raspberry and the DAM, using Volumio. I was going for Voyage, but an update in Volumio allows it to be used as well.
http://www.diyaudio.com/forums/digi...ux-servers-soekris-dam1021-2.html#post4268351
Yes and no.
No, because there are re-clocking algorithms and isolation barriers on dam1021. IMO practically any deficiencies in quality of rpi clock sources and its supply lines can be neglected.
Yes, because if you are not brave enough to mangle with ALSA subsystem code, out of box you are limited to 192kHz sources. Not for a reason stated at that blog. It's not the 19.2Mhz on-board clock limitation. Higher frequencies could be handled as well [1]. At least some changes to core ALSA code are needed [2][3] and a new kernel module needs to be created as well (rpi-dac.c/pcm1794a.c are good candidates for forking).
So unless you're producer and the like, you can happily use dam1021 paired with rpi right now. I have yet to see why using usb-i2s or s/pdif should be a better approach (in terms of sound quality, because in terms of functionality it is pretty useless exercise). Just stick to the newest kernel possible.
[1] https://github.com/raspberrypi/linu...ef202eba/sound/soc/bcm/bcm2835-i2s.c#L360-411
[2] https://github.com/raspberrypi/linu...656ccdc6ef202eba/include/sound/pcm.h#L113-138
[3] https://github.com/raspberrypi/linux/blob/rpi-4.0.y/sound/core/pcm_native.c#L1946-1947
Agree with forta above. Also concur that i2s sounds noticeably better from RPI than using all the extra circuitry and firmware that USB and SPDIF involve. I2s cabling is also much shorter.
Re Volumio vs Voyage, try both and decide which sounds better. Although I haven't got around to trying it myself I believe that Voyage will do DoP. It's worth the journey into Linux to get these distros working with the DAM and RPI.
I am waiting on some PCBs I did via one of the Chinese board houses one of which allows the RPI (2 and B+) to plug in to the DAM - it lies on top of the DAM if you can imagine it. So no i2s cabling, traces are very short and it should be easy to package it all up with a minimum of wiring. Take the DAM's output to a Class D amp, add a microcontroller for IR remote control when Soren enables the isolated RS232s and it should be a nice 'complete music center' project.
Re Volumio vs Voyage, try both and decide which sounds better. Although I haven't got around to trying it myself I believe that Voyage will do DoP. It's worth the journey into Linux to get these distros working with the DAM and RPI.
I am waiting on some PCBs I did via one of the Chinese board houses one of which allows the RPI (2 and B+) to plug in to the DAM - it lies on top of the DAM if you can imagine it. So no i2s cabling, traces are very short and it should be easy to package it all up with a minimum of wiring. Take the DAM's output to a Class D amp, add a microcontroller for IR remote control when Soren enables the isolated RS232s and it should be a nice 'complete music center' project.
With a decent USB to I2S adaptor (amanero/xmos) you are using asynchronous transfer, so how would the length of the cable even matter or affect sound quality in general? The host doesn't care about the sync it just buffers it async to the adaptor which pipes it out to the dam fifo/reclocker. Hey I love this stuff as much as you do, but sometimes you need to lay back and look at how silly this "sounds" when you make such dubious claims. Such claims would only apply to the older synchronous chipsets that are usually limited to 48khz max. Many just use crappy 12mhz crystals and sync from the host.
SPDIF you are right in most cases, however the fifo/reclocking of the dam helps with this as well.
Last edited:
Well, whatever the technical argument my ears prefer the i2s connection every time. In comparison to the isolated or non-isolated async diyinhk XMOS interface. Try it and let us know your view.
Don't understand either how you can base a claim that because it's async and re clocked it's a 'dubious' claim. That smacks of the 'all amps must sound the same because circuitry says so' theory. Also, are you saying that technically you prefer adding a whole layer of circuitry to the interface? Take a listen and see for yourself. And then, if you agree, let's hear a possible explanation....
There are likely other variables at play, and how can you compare something that's entirely in the digital domain to something like an amplifier that can have a ridiculous amount of variations from one design to the next? A more appropriate comparison would be claiming how that expensive HDMI cable creates a better picture on your TV than a dollar store cheapo.
Perhaps try running your USB/xmos via ALSA in Linux if you want a more similar comparison. You stated neither details on how you were using it, other than that it "sounded better".
Don't see the point of carrying this on any further, it's quite a bit off topic and when distilled down it amounts to a belief by you that my claim that, in my system and to my ears, an i2s connection from the RPI to the DAM sounds better than an async USB connection (via ALSA, btw) is dubious because the USB interface is async and as such cannot have any bearing on the sound.
In the absence of any evidence that you have tried it for yourself your position is theoretical and ignores or misses several things including, for example, that an async interface addresses only the timing of the signal. The fact it adds a complex extra layer of circuitry is ignored by you. Your belief that, in this context, you can't compare digital to analog is erroneous - it is still an analog voltage going through that complex extra USB interface and its cable and so is subject to other issues that have a bearing on sound quality. There's lots of threads on this site where USB and its effect on sound are discussed - try searching John Swenson for example.
So, spikestabber, pick your interface poison but, if you have an RPI, please try it for yourself before dismissing i2s on the basis of theory alone. If, after trying it, you still prefer your USB interface I'll respect your ears and refrain from calling your claim dubious......;-))
Now let's return this thread to its intended purpose.
One of the paper referenced in the first post of filter brewing thread states that ultrasonic images of the input signal that pass through the digital filters are beneficial because they are essentially high-frequency noise that mitigates DNL by shifting the output signal a few codes up and down, and the high-frequency analog output filter averages the noise out, providing a more linear signal, much like dither. I thought it has some sense, but it would be better to have "perfect" filter and then add dither deliberately after all the upsampling. Seems that similar method is used in the ADCs. Though the anti-DNL dither probably would be more complex than "standard" LSB dither, from what I've read on the ADC, you would need 2 or 3 signal-relative LSB, as adding noise that doesn't scramble with lower bits of the signal would be pointless.
Would that be possible to implement on the FPGA used?
Would that be possible to implement on the FPGA used?