There is apparently something about OE that does not fully keep the clock module warmed up and stable when not enabled. Why? Don't know exactly. Allo also apparently found that using the OE on buffer chips after the clock modules was okay enough for use in Katana dac. If anything they were more likely measuring what dac guys sometime refer to as jitter (more or less, far-out phase noise when measured as jitter). That is as opposed to the close-in phase noise Andrea thinks is more important.
Last edited:
This is another jitterati myth. OE does not stop oscillations within the component. Some oscillators have standby function. This stops the oscillations.
You can read more e.g. here: https://www.digikey.fi/en/blog/the-...ndby-and-output-enable-options-in-oscillators
If I turn on my dac to listen to two hours of music. The oscillator will be on and enable for two hours.
In the amanero usb, once you hit play the first time (in the hqplayer) the oscillator turns on/enable and doesn't turn off until you turn off the entire dac and or remove the hqplayer. The oscillator is always on/enable.
The amanero usb only changes oscillator if you change the settings in the hqplayer (which is only adjusted once or is almost never done 44,1Khz or 48Khz). Turn off one and turn on the other. But you have to stop the playback and change the parameters in the settings, so that it changes the oscillators.
In the amanero usb, once you hit play the first time (in the hqplayer) the oscillator turns on/enable and doesn't turn off until you turn off the entire dac and or remove the hqplayer. The oscillator is always on/enable.
The amanero usb only changes oscillator if you change the settings in the hqplayer (which is only adjusted once or is almost never done 44,1Khz or 48Khz). Turn off one and turn on the other. But you have to stop the playback and change the parameters in the settings, so that it changes the oscillators.
Last edited:
You are assuming that the output buffer state does not affect oscillator operation in some way you haven't thought of. Temperature gradients across the IC could change, loading as seen by the oscillator could change (since buffers don't provide complete isolation), etc. Whatever the case, empirical evidence trumps simplified theory.
EDIT: Please be mindful of your tendency towards name-calling (i.e. jitterati myth). Attack the argument if you want, don't shoot the messenger.
Last edited:
I'm not assuming anything and I even gave you a link to a blog to study. Instead of continuing with your jitterati nonsense maybe you should come up with concrete evidence that OE "does not fully keep the clock module warmed up and stable when not enabled" as you claimed.
I just pointed out that your claim has no base. Please, provide concrete evidence to the contrary.
False.
An empirical basis was already described in #2,380.
Also in #2,380, I described what Allo did with Katana dac. It uses NDK SDA clocks which have OE pins. Allo did NOT use the clock OE pins. Instead they added one dedicated NB3L553-D per each of the two dac clocks (a total of two NB3L553-D). OE on the NB3L553-D buffers were used to switch between clocks, NOT OE on the clock modules. IIUC Allo uses a LeCroy scope, most likely one with the jitter measurement package (same method Iancanada uses to measure jitter). I do know that Allo went by measurements alone for making design decisions at the time Katana dac was developed. (Note: so far as I am aware Ian has not performed measurements of clock jitter specifically associated with clock module OE pin switching as Allo apparently did. However Ian no longer requires that particular switching method be used starting with FIFO_Pi ver.3).
EDIT: To further clarify, Allo used only one output on each NB3L553-D. The outputs from the two buffers were OR'ed together to drive the dac chip clock input pin. Only one buffer was enabled at a time. In other words, the buffer chips were used exclusively for clock switching, NOT for driving multiple loads.
Last edited:
Science does not always discount anecdotal evidence, particularly when that is the best information available.
For example, the following anecdote happened first before a now-accepted theory was developed (found by google):
"The soliton phenomenon was first described in 1834 by John Scott Russell (1808–1882) who observed a solitary wave in the Union Canal in Scotland."
Also, obviously interviewing patients for anecdotal evidence is sometimes key to medical diagnosis.
One could go on and on with examples.
Why should it be considered rational to always reject any anecdotal evidence out of hand? To do so in all cases would not be scientific nor would it be rational.
For example, the following anecdote happened first before a now-accepted theory was developed (found by google):
"The soliton phenomenon was first described in 1834 by John Scott Russell (1808–1882) who observed a solitary wave in the Union Canal in Scotland."
Also, obviously interviewing patients for anecdotal evidence is sometimes key to medical diagnosis.
One could go on and on with examples.
Why should it be considered rational to always reject any anecdotal evidence out of hand? To do so in all cases would not be scientific nor would it be rational.
So you still think your anecdotal evidence is better than information given by manufacturers themselves? On that bombshell I'm out of here.
You're looking at a 25 MHz square signal with a 50 MHz oscilloscope. What would you expect to see?
You'd need at least a 500 MHz one to be able to see a clean square wave...
I'm trying to hook up an old Amanero (purchased 11/2013) directly to Twisted Pear Buffalo III. 44k families work good but can not get sound from 48k,96k families. Using JRiver latest WASAPI driver, (ASIO driver did not work at all). Also tried JRiver on Macintosh with same result.
This Amanero was previously used with Hermes/Cronus so had been flashed for Slave mode. I re-flashed default firmware (CLPD 180, CPU firmware DSD512-44-48, and Configuration bits back to master mode). Tried several different firmwares and pretty sure I've got the correct procedure down.
On the Oscilloscope playing 44k gives good signal. Changing to 96k gives flat line on BCLK, FSCLK and DATA. Both give signal on MCLK.
Furthermore going back to 44.1k required a reset by disconnecting and reconnecting module.
I think this means the Amanero is faulty. Is there any way this could be a firmware or driver issue?
Thanks for your consideration,
Mike
This Amanero was previously used with Hermes/Cronus so had been flashed for Slave mode. I re-flashed default firmware (CLPD 180, CPU firmware DSD512-44-48, and Configuration bits back to master mode). Tried several different firmwares and pretty sure I've got the correct procedure down.
On the Oscilloscope playing 44k gives good signal. Changing to 96k gives flat line on BCLK, FSCLK and DATA. Both give signal on MCLK.
Furthermore going back to 44.1k required a reset by disconnecting and reconnecting module.
I think this means the Amanero is faulty. Is there any way this could be a firmware or driver issue?
Thanks for your consideration,
Mike
Is it a real Amanero or a Chinese clone? If real, you might be able to get some support help from Dom at Amanero.
You can contact them at: support@amanero.com
You can contact them at: support@amanero.com
Good suggestion by @Markw4
Dom is always very helpful.
However in my experience it does not sound like a faulty Amanero board - I have used 100+ in my products & never experienced
a board fault like that.
When flashing do you get the done/finished message at the end of each flash process?
Another odd thing is the ASIO driver not working as that is what I use/recommend with all my products using the Amanero.
Sounds like a configuration error in the flashing process or wrong driver in the streamer or server if using Windows.
Dom is always very helpful.
However in my experience it does not sound like a faulty Amanero board - I have used 100+ in my products & never experienced
a board fault like that.
When flashing do you get the done/finished message at the end of each flash process?
Another odd thing is the ASIO driver not working as that is what I use/recommend with all my products using the Amanero.
Sounds like a configuration error in the flashing process or wrong driver in the streamer or server if using Windows.
Yes, it was purchased directly from Amanero Nov. 2013
I was finally able to get Win10 ASIO driver working. (Had to re-install driver). After switching JRiver to the ASIO driver I got sound from my 96k files. Then I noticed that JRiver was converting everything to DSD. I did not set it this way.
Removing the DSD conversion in JRiver results in no sound on 96k files. I am baffled! I guess JRiver knows something I do not.
Thanks for your comments
I was finally able to get Win10 ASIO driver working. (Had to re-install driver). After switching JRiver to the ASIO driver I got sound from my 96k files. Then I noticed that JRiver was converting everything to DSD. I did not set it this way.
Removing the DSD conversion in JRiver results in no sound on 96k files. I am baffled! I guess JRiver knows something I do not.
Thanks for your comments
There are a lot of settings in JRiver.
You might just have to experiment a bit.
https://wiki.jriver.com/index.php/DAC_Settings
You might just have to experiment a bit.
https://wiki.jriver.com/index.php/DAC_Settings