• The Vendor's Bazaar forum is for commercial offers and transactions. Only unmoderated members can post here.

    diyAudio provides this forum for the convenience of our members, but makes no warranty nor assumes any responsibility. We do not vet any members. Use of this facility is at your own risk. Customers can post any issues in those threads as long as it is done in a civil manner. All diyAudio rules about conduct apply and will be enforced.

USB to I2S 384Khz - DSD Converter

Jump to Latest
#2,382
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:
#2,383
#2,384
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.
 
Last edited:
#2,385
bohrok2610 said:
This is another jitterati myth.
Click to expand...

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:
#2,386
Markw4 said:
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.
Click to expand...
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.
 
#2,389
bohrok2610 said:
...your claim has no base...
Click to expand...

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:
#2,391
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.
 
#2,393
adiaz said:
All of them when I measure the output signal of the two crystals (22,579 and 24,576) in the oscilloscope, a slightly "bad" signal appears to me. The clock signal, depending on whether one or the other clock is used, looks just as bad.
Click to expand...
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...
 
  • Like
Reactions: adiaz
#2,395
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
 
#2,397
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.
 
#2,398
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
 
You must log in or register to reply here.
Top Bottom