The digital return path (ground) should follow the signals for best signal integrity and minimum noise... The I2S signals are designed to run on a single PCB with preferably an adjacent ground plane, the USB is differential mostly (some handshaking is single ended), but the lines still need a return path that makes the smallest loop possible, connecting it to the analogue star point is probably not a good ides. A wiring diagram would help.
DSD256 on Windows
I am attempting to run a Signalyst DSC1 via Win8.1. Is there a driver that can play DSD256 native ASIO? My apologies is this is covered elsewhere.
I am attempting to run a Signalyst DSC1 via Win8.1. Is there a driver that can play DSD256 native ASIO? My apologies is this is covered elsewhere.
Maybe I should rephrase this. Should I be capable of playing DSD256 on Win8.1(driver 2.26) or OSX 10.11? I cannot seem to get non DoP to work in HQPlayer, and am limited to DSD128.
I have been able to play DSD256 with JRiver with OS X.
So heres a couple thoughts, The JLsounds unit is very nice. I have compared both AK, ESS chips with the same (Balanced) I/V stage, and prefer the AK. I feel that you can squeeze a little more top end bandwidth out of the AK because of the internal filtering compared to the ESS that creates a lot more sibilance when unfiltered.
I've noticed the J2 header on the display. Is this for an IR sensor and apple remote? (Please be true, please be true 🙂 )
From what I can tell the xmos requires grounding on the shielding of the USB cable for the initial handshake only. I had a Large amount of noise being injected when the DAC was mounted to wood, now that its mounted to an alloy surface the noise is un-noticable, but that makes me wonder whats the best way to deal with the noise coming from the computer ground? Perhaps a filter could be added to the cable, or is it specifically ground looping?
So heres a couple thoughts, The JLsounds unit is very nice. I have compared both AK, ESS chips with the same (Balanced) I/V stage, and prefer the AK. I feel that you can squeeze a little more top end bandwidth out of the AK because of the internal filtering compared to the ESS that creates a lot more sibilance when unfiltered.
I've noticed the J2 header on the display. Is this for an IR sensor and apple remote? (Please be true, please be true 🙂 )
From what I can tell the xmos requires grounding on the shielding of the USB cable for the initial handshake only. I had a Large amount of noise being injected when the DAC was mounted to wood, now that its mounted to an alloy surface the noise is un-noticable, but that makes me wonder whats the best way to deal with the noise coming from the computer ground? Perhaps a filter could be added to the cable, or is it specifically ground looping?
Last edited:
Has anyone tested the last driver against a Mac/Linux ? Is there any difference now or Linux still-life gives the best result...?
You have one 4V and another 5V PSU, if I understand correctly.. same as me, but I don't have any problem.. I tried old XMOS_AK4396 and new XMOS_AK4490 combo on lot of computers, with different configurations and OS, never had problem with noise..
Are you sure that everything is properly connected, jumpers opened, etc..
Are you sure that everything is properly connected, jumpers opened, etc..
Hmm... OK, thank you. It must be me then, or HQPlayer. Now that I know that it does work, I will experiment more with OSX.
It only makes noise when there is no ground to the standoffs.
Any ideas about the IR and remote?
I found this on the front page of AK4490.
"Five digital filters are integrated into the AK4490: a short delay, sharp roll-off filter and a short delay, slow roll-off filter for minimum delay, a sharp roll-off filter and a slow roll-off filter for no phase shifting, and newly integrated super slow roll-off filter with emphasized characteristics provide a wide range of choice in digital filters."
Meaning that the ISS roll-off filter is the only filter that uses Sound Setting 1,2,3?
Any ideas about the IR and remote?
I found this on the front page of AK4490.
"Five digital filters are integrated into the AK4490: a short delay, sharp roll-off filter and a short delay, slow roll-off filter for minimum delay, a sharp roll-off filter and a slow roll-off filter for no phase shifting, and newly integrated super slow roll-off filter with emphasized characteristics provide a wide range of choice in digital filters."
Meaning that the ISS roll-off filter is the only filter that uses Sound Setting 1,2,3?
DSD256 on JRiver OSX
If you would please, tell me if you are upsampling, or simply playing 4xDSD files on JRiver? I tried briefly last night, but couldn't get it to upsample redbook to DSD256.
If you would please, tell me if you are upsampling, or simply playing 4xDSD files on JRiver? I tried briefly last night, but couldn't get it to upsample redbook to DSD256.
4x thats crazy, Jriver only does 2x = DSD128. I don't know what your after or if the format is widely accepted.
There are a couple of ADCs that do 4x (DSD256), but any actual recordings in DSD256 probably weren't recorded in that format. For pretty much any processing, DSD has to be converted to PCM, and these days it usually is DXD (24 bit, 352.8/384 kHz PCM). Converting back, it is easy to produce "big numbers" formats.
Ha! Yes, I might be crazy...
I am using this with the DSD only DSC1 designed by Signalyst for use with their HQPlayer program. It is optimized for DSD256+, and I've been RB>DSD256 for some time.
I've downloaded the latest JRMC, and it shows it can convert to 1x, 2x and 4x DoP. I've yet to get any of it to work however.
Why I think reclocker isn't effective
I like the concept of reclocking the i2s output from the XMOS after galvanic isolating it. But it doesn't work in this design unfortunately.
[see picture]
By reclocking (basically: sampling) the signal with the MCLK or 2* MCLK delivered by the clocks, the maximum jitter/timing error of the i2s from XMOS to be corrected by reclocking would be one master clock cycle. In our case of 45.1584/49.1520 MHz this would be 22/20 ns. While oscillator jitter is mostly specified in the order of pico seconds, one would assume that reclocking would be very effective if the jitter of XMOS+isolator stays below 20 ns.
But what if it doesn't? What if the variation of the XMOS signal's clocking is bigger than 1 reclock cycle? For bitclock and data lines this won't be a problem, data will be clocked in by DAC still on time, but for LR clock an error of 20 ns means that the next sample is delayed, very bad for Sound Quality.
Because the I2SoverUSB board isn´t immune to transport (different pc or USB cable), as was already argued by SoundCheck, I was wondering why the reclocker didn't solve this, and studied datasheet of XMOS. The XMOS chip clocks are derived from an internal PLL which is supplied with 1V on its own PLL_AVDD pin. In this design this pin is attached to VDD via an RC-filter network. Because PLL is voltage controlled, it's supply has to be stable and noise free, which is not the case when tied to VDD, regardless how good your main supply of the board is and/or local decoupling of the VDD supply pins. Better would be to have a separate supply of PLL_AVDD.
So I decided that the PLL psu needed improvement, and attached (temporary, using hot glue!) a rather big electrolytic of 100u/16V across the SMD cap of the RC filter.
Simply by adding this capacitor I made this USB interface a lot better, I didn't think my setup could sound that good! Now this USB interface really stands out. This also means IMO that there's a big weakness in the current design of the I2SoverUSB board, which should be addressed in future revisions.
[I'm using the I2SoverUSB board with i2s output attached via short ribbon cable to dual AKM AK4399 DAC, using two separate very low noise power supplies for XMOS and reclocker.]
Actually this mod didn't reduce dependency on transport, but it certainly did improve sound, just try it yourself! Any comments welcome.
Nino
I like the concept of reclocking the i2s output from the XMOS after galvanic isolating it. But it doesn't work in this design unfortunately.
[see picture]
By reclocking (basically: sampling) the signal with the MCLK or 2* MCLK delivered by the clocks, the maximum jitter/timing error of the i2s from XMOS to be corrected by reclocking would be one master clock cycle. In our case of 45.1584/49.1520 MHz this would be 22/20 ns. While oscillator jitter is mostly specified in the order of pico seconds, one would assume that reclocking would be very effective if the jitter of XMOS+isolator stays below 20 ns.
But what if it doesn't? What if the variation of the XMOS signal's clocking is bigger than 1 reclock cycle? For bitclock and data lines this won't be a problem, data will be clocked in by DAC still on time, but for LR clock an error of 20 ns means that the next sample is delayed, very bad for Sound Quality.
Because the I2SoverUSB board isn´t immune to transport (different pc or USB cable), as was already argued by SoundCheck, I was wondering why the reclocker didn't solve this, and studied datasheet of XMOS. The XMOS chip clocks are derived from an internal PLL which is supplied with 1V on its own PLL_AVDD pin. In this design this pin is attached to VDD via an RC-filter network. Because PLL is voltage controlled, it's supply has to be stable and noise free, which is not the case when tied to VDD, regardless how good your main supply of the board is and/or local decoupling of the VDD supply pins. Better would be to have a separate supply of PLL_AVDD.
So I decided that the PLL psu needed improvement, and attached (temporary, using hot glue!) a rather big electrolytic of 100u/16V across the SMD cap of the RC filter.
Simply by adding this capacitor I made this USB interface a lot better, I didn't think my setup could sound that good! Now this USB interface really stands out. This also means IMO that there's a big weakness in the current design of the I2SoverUSB board, which should be addressed in future revisions.
[I'm using the I2SoverUSB board with i2s output attached via short ribbon cable to dual AKM AK4399 DAC, using two separate very low noise power supplies for XMOS and reclocker.]
Actually this mod didn't reduce dependency on transport, but it certainly did improve sound, just try it yourself! Any comments welcome.
Nino
Attachments
Your picture has different cap value than what you specified in your text... Which one is the one you currently use?
Thanks
Do
Yes, you're right. Currently I use 100u/16V, don't use ultra low ESR. Check polarity!
Regards,
Nino
Regards,
Nino
Last edited:
Do you have some measurements with and without cap..
Do you have another XMOS board for listening test and compare with 'improved' one..
It would be interesting to see is there any comment from J&L..
I don't have the proper equipment to do these measurements. But improvement is so obvious, I don't think figures are needed to prove the better performance, though measurements would be nice to verify my theory...
It's a small mod, just give it a try, only if you want of course 🙂
It's a small mod, just give it a try, only if you want of course 🙂