Hi.
Just installed the gadget. I hooked it up to a Raspberry Pi with Archlinux, running
latest 3.12 kernel and squeezelite.
The interface was immediately recognized. That's good.
I got trapped first. No sound.
I figured (RTFM) that I had to bridge the 5V lines without having the DAC board in place.
With the piggyback DAC board in place that 5V connection gets automatically established.
Now its time to apply proper power supplies and cabling.
Without it (just using a standard USB cable and USB power) my good old Squeezebox
makes a better job on the SPDIF output.
Please let me know what high quality 5V PS you guys use. As far as I understand I need 2 of them. On top of that I need a 7.5 supply. Hmmh.
What do you guys recommend as 7.5V supply for the 5102 DAC!!?
Thx.
Just installed the gadget. I hooked it up to a Raspberry Pi with Archlinux, running
latest 3.12 kernel and squeezelite.
The interface was immediately recognized. That's good.
I got trapped first. No sound.
I figured (RTFM) that I had to bridge the 5V lines without having the DAC board in place.
With the piggyback DAC board in place that 5V connection gets automatically established.
Now its time to apply proper power supplies and cabling.
Without it (just using a standard USB cable and USB power) my good old Squeezebox
makes a better job on the SPDIF output.
Please let me know what high quality 5V PS you guys use. As far as I understand I need 2 of them. On top of that I need a 7.5 supply. Hmmh.
What do you guys recommend as 7.5V supply for the 5102 DAC!!?
Thx.
Last edited:
Hi,
If you will use your XMOS board with PCM5102, you are going to need only one 5V PS and one 7.5V PS. On the PCM5102 board there is an embedded 5V regulator for the oscillators and reclock of the XMOS board.
If you will use only XMOS board, you are going to need two 5V PS.
Note: If you are going to use adjustable with trimmer potentiometer power supply (not recommended), please adjust the loaded output voltage and then connect to the XMOS board.
Regards,
Joro
If you will use your XMOS board with PCM5102, you are going to need only one 5V PS and one 7.5V PS. On the PCM5102 board there is an embedded 5V regulator for the oscillators and reclock of the XMOS board.
If you will use only XMOS board, you are going to need two 5V PS.
Note: If you are going to use adjustable with trimmer potentiometer power supply (not recommended), please adjust the loaded output voltage and then connect to the XMOS board.
Regards,
Joro
Hi there.
I today I worked on my SPDIF installation. (For the time being I skip the DAC board)
I run a RPI with Arch and squeezelite and a FullDigital Amp (a tweaked DDX320 from HifiMeDiy)
I basically hooked up 2 * 12000mAh EASY-Accs ( those batteries you use for mobile device charging) on each side to avoid as many gLoops as possible.
The Raspberry Pi that I'm currently using for testing is hooked up to another supply (5V from mains though). Here I'll catch a dirty ground.
The USB cable is filtered, the 5V lead is cut.
Bottom line. This setup beats my SqueezeBox Touch. A nice improvement.
Though what I experience is not night and day appart. That doesn't mean much. My SBTouch was performing quite well with all the tweaks in place.
If I do the math: 50€ for the RPI (incl. case etc), 60€ for the batteries, and 80€ for the
SPDIF interface (Joro: could you please give your product a name such as JoroIF of JoroDac. ) . Bottom line the transport will cost me around 200€. That's not bad.
That's actually quite good. 30% less than my good old SB Touch - The stock price without any mods!
However. Why Am I not that enthusiastic!?!?
1. The 2-battery supply (for best sound and isolation) is kind of complex and annoying to
handle. Until I find a potentially better solution, if have to manage that.
One of those batteries need 100mA minimum current to stay on.
The isolated part of the IF stays below that. I had to load another USB port with
75R to get up to the 100mA.
2. The interface exhibits very nasty turn on/off plops. E.g. if I reboot the PI.
I guess something is missing there. This is almost a NoGo for the product,
unless I get that solved.
(If anybody knows a solution or has an idea of how to get this Plop thing resolved please let me know)
Next Wednesday I'm gonna compare the interface against an Audiophilleo II.
Cheers
I today I worked on my SPDIF installation. (For the time being I skip the DAC board)
I run a RPI with Arch and squeezelite and a FullDigital Amp (a tweaked DDX320 from HifiMeDiy)
I basically hooked up 2 * 12000mAh EASY-Accs ( those batteries you use for mobile device charging) on each side to avoid as many gLoops as possible.
The Raspberry Pi that I'm currently using for testing is hooked up to another supply (5V from mains though). Here I'll catch a dirty ground.
The USB cable is filtered, the 5V lead is cut.
Bottom line. This setup beats my SqueezeBox Touch. A nice improvement.
Though what I experience is not night and day appart. That doesn't mean much. My SBTouch was performing quite well with all the tweaks in place.
If I do the math: 50€ for the RPI (incl. case etc), 60€ for the batteries, and 80€ for the
SPDIF interface (Joro: could you please give your product a name such as JoroIF of JoroDac.
) . Bottom line the transport will cost me around 200€. That's not bad.That's actually quite good.
30% less than my good old SB Touch - The stock price without any mods! However. Why Am I not that enthusiastic!?!?
1. The 2-battery supply (for best sound and isolation) is kind of complex and annoying to
handle. Until I find a potentially better solution, if have to manage that.
One of those batteries need 100mA minimum current to stay on.
The isolated part of the IF stays below that. I had to load another USB port with
75R to get up to the 100mA.
2. The interface exhibits very nasty turn on/off plops. E.g. if I reboot the PI.
I guess something is missing there. This is almost a NoGo for the product,
unless I get that solved.
(If anybody knows a solution or has an idea of how to get this Plop thing resolved please let me know)
Next Wednesday I'm gonna compare the interface against an Audiophilleo II.
Cheers
Last edited:
Hi,
High quality sound requires some sacrifices . XMOS board can be used with an external power supply (alone) for oscillators and reclock. The USB part to be powered by USB host, thus galvanic insulation will work.
All of the potential of I2SoverUSB ( like that, I named XMOS board some time ago ) reveals when using I2S output (with a maximum short cable). This is because the receiver of S/PDIF has a PPL for recovering the clock.
Sorry, but my English is not so good, so could you please explain this with another words, I can't get it.
Unfortunately I have no opportunity to try each test unit (I don't have RPI), so could you be so kind to test the I2SoverUSB and the DAC5102 board with your RPI and under Windows OS if you have the opportunity, and share if there are still these issues.
Regards,
Joro
High quality sound requires some sacrifices
. XMOS board can be used with an external power supply (alone) for oscillators and reclock. The USB part to be powered by USB host, thus galvanic insulation will work.All of the potential of I2SoverUSB ( like that, I named XMOS board some time ago
) reveals when using I2S output (with a maximum short cable). This is because the receiver of S/PDIF has a PPL for recovering the clock.Sorry, but my English is not so good, so could you please explain this with another words, I can't get it.
Unfortunately I have no opportunity to try each test unit (I don't have RPI), so could you be so kind to test the I2SoverUSB and the DAC5102 board with your RPI and under Windows OS if you have the opportunity, and share if there are still these issues.
Regards,
Joro
* The Easy-ACC batteries that I use are meant for mobile device charging.
They come with several USB outputs to load multiple devices at once.
Obviously they have a chip inside that measures the charging current.
If that current gets below 100mA the Easy-ACC turns off.
Obviously I'm using the battery for a different purpose.
Feeding the isolated part of your board with that battery causes less then 100mA load, thus the battery turns off.
The XMOS part draws more then 100mA. That's why the 2nd battery stays on.
To generate an artificial load, to get above 100mA, I had to hook up a resistor
on another USB port of that Easy-ACC. And that worked.
* Connecting the XMOS section and the Raspberry Pi to the same power supply,
even with external cabling (no USB power), causes slight degradation of sound.
That's also been mentioned earlier in the thread by somebody else. That could be a sign, that the isolation part and reclocker doesn't really work at 100%.
And that there's still space for improvement. Though I guess your competition is not much better, if any better at all. However. I can hear the difference easily.
* I do not own a Windows PC. The RPI works well on my Teac DAC though. No Plops.
Somehow you , the XMOS , might sent a garbage signal out when turning the USB transport on/off.
When turning the RPI off and leavng the SPDIF IF on, it's rather like starting a machine Plop gun. I'm a bit concerned that this might kill my speakers.
Cheers
They come with several USB outputs to load multiple devices at once.
Obviously they have a chip inside that measures the charging current.
If that current gets below 100mA the Easy-ACC turns off.
Obviously I'm using the battery for a different purpose.
Feeding the isolated part of your board with that battery causes less then 100mA load, thus the battery turns off.
The XMOS part draws more then 100mA. That's why the 2nd battery stays on.
To generate an artificial load, to get above 100mA, I had to hook up a resistor
on another USB port of that Easy-ACC. And that worked.
* Connecting the XMOS section and the Raspberry Pi to the same power supply,
even with external cabling (no USB power), causes slight degradation of sound.
That's also been mentioned earlier in the thread by somebody else. That could be a sign, that the isolation part and reclocker doesn't really work at 100%.
And that there's still space for improvement. Though I guess your competition is not much better, if any better at all. However. I can hear the difference easily.
* I do not own a Windows PC. The RPI works well on my Teac DAC though. No Plops.
Somehow you , the XMOS , might sent a garbage signal out when turning the USB transport on/off.
When turning the RPI off and leavng the SPDIF IF on, it's rather like starting a machine Plop gun. I'm a bit concerned that this might kill my speakers.
Cheers
Last edited:
When power supply is common, the interferences from one access to another, and vice versa. The way of the noise is not only through the galvanic barrier, here affects the electromagnetic interference. Galvanic isolation unfortunately can not cope with them. To reduce the electromagnetic interference are required electromagnetic screens thru capacitors and things are going to increase seriously the price of the device.
There are few people who could catch the difference when using separate power supply for the USB power part (you're from the lucky ones) for this I provide opportunity so one can use separate power supply for the USB part. For this I recommend necessarily completely self-power supply for oscillators and reclock and for those who can hear the difference option for external power supply for the USB part. I personally do not hear the difference, but some of my friends hear it and that's why I embed this feature (obviously I was not wrong
).Could you please directly pull out the USB cable (this would be equivalent if you power off the RPI, which you already done that). Are there the same plops? I just tested the S/PDIF output under Win7 with different receivers (receiver Harman Kardon, S/PDIF input of HD970CD and DAC Denon DA500) - no plops, when disconnecting the USB cable directly, as well as turning the computer on and off.
Could you please try XMOS + PCM5102 +RPI. Are there the same plops?
Regards,
Joro
Hi folks.
Does anybody of you know which kernel/Alsa revision initially supported the XMOS chip
that's been used in the JoroIF?
I just installed an ArchLinux image on a Cubieboard 3. That comes with 1.0.25 drivers on a 3.4
kernel. The JoroIF is not recognized. My Teac DAC works fine though.
My Raspberry with kernel 3.12 has no issues handling JoroIF on the RPI side.
Looks like an outdated driver issue to me.
Thx
Cheers
Does anybody of you know which kernel/Alsa revision initially supported the XMOS chip
that's been used in the JoroIF?
I just installed an ArchLinux image on a Cubieboard 3. That comes with 1.0.25 drivers on a 3.4
kernel. The JoroIF is not recognized. My Teac DAC works fine though.
My Raspberry with kernel 3.12 has no issues handling JoroIF on the RPI side.
Looks like an outdated driver issue to me.
Thx
Cheers
Last edited:
Hi Joro,
I have recently received the XMOS/AK4396 board and my intention is to get the most out of this combination not only by applying the external power supply.
Although the board should be difficult to work with (extremely compact, mostly smd components) I think it is possible to further improve the output section of the AK4396 board at least by installing the better components (capacitors).
As long as I could notice (I'm not an expert nor I have any technical background) all is done mostly as per AKM datasheet.
It still would be very useful if you could post the schematic of the filtering/output section of the AK4396 DAC chip.
Thanks and regards,
Goran
I have recently received the XMOS/AK4396 board and my intention is to get the most out of this combination not only by applying the external power supply.
Although the board should be difficult to work with (extremely compact, mostly smd components) I think it is possible to further improve the output section of the AK4396 board at least by installing the better components (capacitors).
As long as I could notice (I'm not an expert nor I have any technical background) all is done mostly as per AKM datasheet.
It still would be very useful if you could post the schematic of the filtering/output section of the AK4396 DAC chip.
Thanks and regards,
Goran
Hi.
I still don't get the interface to work on my Cubieboard3.
dmesg is printing:
It seems that the device gets initially not properly recognized on hw level. That's before the driver gets loaded..
I compared "lsusb -vv" of my TEAC and the JoroIF. Lot of very different settings
on both interfaces. Joro if you're interested I can sent you both printouts.
I also figured that the interface claims 500mA USB power, even though its externally powered.
Cheers
I still don't get the interface to work on my Cubieboard3.
dmesg is printing:
Code:
[ 5734.222880] usb 2-1.4.3: new full-speed USB device number 4 using sw-ohci
[ 5734.321820] usb 2-1.4.3: device descriptor read/64, error -62
[ 5734.541824] usb 2-1.4.3: device descriptor read/64, error -62
[ 5734.742866] usb 2-1.4.3: new full-speed USB device number 5 using sw-ohci
[ 5734.841822] usb 2-1.4.3: device descriptor read/64, error -62
[ 5735.061823] usb 2-1.4.3: device descriptor read/64, error -62
[ 5735.262866] usb 2-1.4.3: new full-speed USB device number 6 using sw-ohci
[ 5735.691208] usb 2-1.4.3: device not accepting address 6, error -62
[ 5735.802869] usb 2-1.4.3: new full-speed USB device number 7 using sw-ohci
[ 5736.231213] usb 2-1.4.3: device not accepting address 7, error -62
[ 5736.243358] hub 2-1.4:1.0: unable to enumerate USB device on port 3
[ 5756.112881] usb 2-1.4.3: new full-speed USB device number 8 using sw-ohci
[ 5756.211836] usb 2-1.4.3: device descriptor read/64, error -62
[ 5756.431830] usb 2-1.4.3: device descriptor read/64, error -62
[ 5756.632875] usb 2-1.4.3: new full-speed USB device number 9 using sw-ohci
[ 5756.731823] usb 2-1.4.3: device descriptor read/64, error -62
[ 5756.951822] usb 2-1.4.3: device descriptor read/64, error -62
[ 5757.152952] usb 2-1.4.3: new full-speed USB device number 10 using sw-ohci
[ 5757.581308] usb 2-1.4.3: device not accepting address 10, error -62
[ 5757.692955] usb 2-1.4.3: new full-speed USB device number 11 using sw-ohci
[ 5758.121320] usb 2-1.4.3: device not accepting address 11, error -62
[ 5758.133365] hub 2-1.4:1.0: unable to enumerate USB device on port 3
[ 5778.002960] usb 2-1.4.3: new full-speed USB device number 12 using sw-ohci
[ 5778.101828] usb 2-1.4.3: device descriptor read/64, error -62
[ 5778.321826] usb 2-1.4.3: device descriptor read/64, error -62
[ 5778.522952] usb 2-1.4.3: new full-speed USB device number 13 using sw-ohci
[ 5778.621824] usb 2-1.4.3: device descriptor read/64, error -62
[ 5778.841822] usb 2-1.4.3: device descriptor read/64, error -62
[ 5779.042955] usb 2-1.4.3: new full-speed USB device number 14 using sw-ohci
[ 5779.481292] usb 2-1.4.3: device not accepting address 14, error -62
[ 5779.582952] usb 2-1.4.3: new full-speed USB device number 15 using sw-ohci
[ 5780.021314] usb 2-1.4.3: device not accepting address 15, error -62
[ 5780.039358] hub 2-1.4:1.0: unable to enumerate USB device on port 3
[ 5799.892957] usb 2-1.4.3: new full-speed USB device number 16 using sw-ohci
[ 5800.011824] usb 2-1.4.3: device descriptor read/64, error -62
[ 5800.231827] usb 2-1.4.3: device descriptor read/64, error -62
[ 5800.432953] usb 2-1.4.3: new full-speed USB device number 17 using sw-ohci
[ 5800.531825] usb 2-1.4.3: device descriptor read/64, error -62
[ 5800.751815] usb 2-1.4.3: device descriptor read/64, error -62
[ 5800.952950] usb 2-1.4.3: new full-speed USB device number 18 using sw-ohci
[ 5801.391298] usb 2-1.4.3: device not accepting address 18, error -62
[ 5801.492955] usb 2-1.4.3: new full-speed USB device number 19 using sw-ohci
[ 5801.931300] usb 2-1.4.3: device not accepting address 19, error -62
[ 5801.949353] hub 2-1.4:1.0: unable to enumerate USB device on port 3
[ 5820.018508] usb 2-1: USB disconnect, device number 2It seems that the device gets initially not properly recognized on hw level. That's before the driver gets loaded..
I compared "lsusb -vv" of my TEAC and the JoroIF. Lot of very different settings
on both interfaces. Joro if you're interested I can sent you both printouts.
I also figured that the interface claims 500mA USB power, even though its externally powered.
Cheers
Last edited:
Ok folks. Update.
I guess I tracked it down myself.
I just figured that this Cubietruck with the current -- manufacturer supplied -- kernel and drivers (3.4.75+) (sunxi) doesn't come with ehci drivers.
That gives me - with the ohci driver - a max rate of 12Mbit/s on my USB port for the time being.
JoroIF won't get along with this.
Of course they sell the device with USB 2.0 support. But that's the problem with most of this embedded boards. The HW (specs) look great. The SW is all but finished.
A continuous work in progress.You'll be lucky if all the drivers will be available at all. It can take years. But that was the same with the Raspberry in the beginning.
Bottom line. Buy a board with the largest community support. And not the one with the largest feature list -- unless you know it's all working.
Let see if I get any feedback about (planned) ehci support for this Cubietruck.
It still makes me wonder how Teac manages to handle Full Speed and High Speed mode on the same interface !?!?
(Probably something for Joro to figure out!?!? Joro: I can sent you the interface parameters if you like. They look really different compared to yours.)
I'll keep you posted.
Cheers
PS: That great Cubietruck board currently supports 16bit only on its Toslink output! And no way to change it as it seems. Feels like being 20 years back in time.
I guess I tracked it down myself.
I just figured that this Cubietruck with the current -- manufacturer supplied -- kernel and drivers (3.4.75+) (sunxi) doesn't come with ehci drivers.
That gives me - with the ohci driver - a max rate of 12Mbit/s on my USB port for the time being.
JoroIF won't get along with this.
Of course they sell the device with USB 2.0 support. But that's the problem with most of this embedded boards. The HW (specs) look great. The SW is all but finished.
A continuous work in progress.You'll be lucky if all the drivers will be available at all. It can take years. But that was the same with the Raspberry in the beginning.
Bottom line. Buy a board with the largest community support. And not the one with the largest feature list -- unless you know it's all working.
Let see if I get any feedback about (planned) ehci support for this Cubietruck.
It still makes me wonder how Teac manages to handle Full Speed and High Speed mode on the same interface !?!?
(Probably something for Joro to figure out!?!?
Joro: I can sent you the interface parameters if you like. They look really different compared to yours.)I'll keep you posted.
Cheers
PS: That great Cubietruck board currently supports 16bit only on its Toslink output! And no way to change it as it seems. Feels like being 20 years back in time.
Last edited:
Hi,
The voltage is not high. It's good to measure the voltage of fully charged battery, when the battery is plug to the charger, the voltage mustn't be higher than 5.5V. If on the discharged battery voltage falls below 4.8V, you may have some deterioration of the sound (only for power supply of the AK4396).
Yesterday, I borrow from a friend of mine RPI with installed raspbian pi kernel 3.10 and vlc 2.0.3. I checked all the situations, which Soundcheck has been tested. I did not notice any plops when power on/off RPI using both S/PDIF (with receivers listed in my previous post) and analog outputs from PCM5102 board. My conclusion is that there are a variety of software cores for RPI and there may be problems with some of them. According to my friend who is more familiar with the software for RPI all cores should work if one write the needed code.
Problems that I noticed - during playing, if you read some information - the sound stops and the indicator for CPU load is on the maximum. Approximately maximum CPU load is reached during 96kHz playing, at higher sample rates the sound stops (obviously, CPU performance influence), this is of course in this compilation of the kernel.
In near future I will try to test other kernels.
Of course if you change the type of capacitor you will change the type of sound signature. You can experiment , the used components are not bad at all, for the filter are used these components: Farnell numbers 9752897, 9752900, 1215927, 1215936.
I can not escape from the datasheet But approximation of the filter is synthesized by me.
No problem.
This could help me.
@Soundcheck could you please test the RPI and the Cubietruck with the Teac on 192kHz?
PS: Could you please share, what Teac you are using?
Regards,
Joro
The voltage is not high. It's good to measure the voltage of fully charged battery, when the battery is plug to the charger, the voltage mustn't be higher than 5.5V. If on the discharged battery voltage falls below 4.8V, you may have some deterioration of the sound (only for power supply of the AK4396).
Yesterday, I borrow from a friend of mine RPI with installed raspbian pi kernel 3.10 and vlc 2.0.3. I checked all the situations, which Soundcheck has been tested. I did not notice any plops when power on/off RPI using both S/PDIF (with receivers listed in my previous post) and analog outputs from PCM5102 board. My conclusion is that there are a variety of software cores for RPI and there may be problems with some of them. According to my friend who is more familiar with the software for RPI all cores should work if one write the needed code.
Problems that I noticed - during playing, if you read some information - the sound stops and the indicator for CPU load is on the maximum. Approximately maximum CPU load is reached during 96kHz playing, at higher sample rates the sound stops (obviously, CPU performance influence), this is of course in this compilation of the kernel.
In near future I will try to test other kernels.
Of course if you change the type of capacitor you will change the type of sound signature. You can experiment
, the used components are not bad at all, for the filter are used these components: Farnell numbers 9752897, 9752900, 1215927, 1215936. I can not escape from the datasheet
But approximation of the filter is synthesized by me.No problem.
This could help me.
@Soundcheck could you please test the RPI and the Cubietruck with the Teac on 192kHz?
PS: Could you please share, what Teac you are using?
Regards,
Joro
Attachments
Yep. I'll do the 192khz tests tomorrow.
I got my issues solved on my CubieTruck board.
For two days I was fiddling around with a broken ArchLinux (nand) image.
Today I installed Lubuntu server on the Cubietruck and everything is working fine.
Sorry for the confusion.
I'll sent you the lsusb -vv printout of my Teac UD 501 per mail.
Cheers
I got my issues solved on my CubieTruck board.
For two days I was fiddling around with a broken ArchLinux (nand) image.
Today I installed Lubuntu server on the Cubietruck and everything is working fine.
Sorry for the confusion.
I'll sent you the lsusb -vv printout of my Teac UD 501 per mail.
Cheers
I've found you've already replied to this question before. Thanks again!
I'll use the battery while I'm putting up the shunts.
Hi.
Some feedback.
We did some serious testing this week. Read "huge" as in "Audiophile" terms.
As transport we used my shiny brand new battery driven CubieTuck + tailormade OS + Tuning + Squeezelite (A setup that's finally replacing my good old SqueezeBox Touch)
Basically the entire chain had been isolated. (We also used a wireless network bridge)
Findings:
The JoroIF interface needs very clean and separated power supplies. The slightest changes can make a huge difference. I was surprised of how much impact the quality of the XMOS supply had.
We've been testing several 5V supplies.
The interface needs a physically well done USB connection. Slightest changes (cable/ground etc.) can make a huge difference.
The input stage incl. XMOS still has a huge impact on SQ even with the reclocker in place. We've been testing several USB cables.
The interface needs a very well done highly tweaked transport. Slightest changes (SW and HW) will make a huge difference. I was really wondering, if the reclocker does its job at all if I run the SPDIF-only base board??.
I just disabled some of my tweaks to see what happens.
Bottom line. If you manage to get all that, plus a top level SPDIF connection/cable, under control. The interface can outperform an Audiophilleo interface.
We've compared it against it.
Then. What makes an interface a real quality interface?? If you ask me, above parameters shouldn't have such an obvious impact.
Basically with this interface you'll never know where you're at. Your tweaking might never end. And that'll cost you time and extra money, without knowing where you're heading.
However. I'm not sure if other interfaces such as the WaveIO do any better. I do think Joro has some homework to do, if he intends to make his product better then today -- better then average.
Advise: Make sure that you'll never have two SPDIF transformers on the SPDIF link! This can happen. You might never experience, what I'm talking about.
The positive side: Our final setup -- using a well pampered JoroIF -- brought us on a level of the Audiophilleo interface. That's not too bad.
Cheers
Some feedback.
We did some serious testing this week. Read "huge" as in "Audiophile" terms.
As transport we used my shiny brand new battery driven CubieTuck + tailormade OS + Tuning + Squeezelite (A setup that's finally replacing my good old SqueezeBox Touch)
Basically the entire chain had been isolated. (We also used a wireless network bridge)
Findings:
The JoroIF interface needs very clean and separated power supplies. The slightest changes can make a huge difference. I was surprised of how much impact the quality of the XMOS supply had.
We've been testing several 5V supplies.
The interface needs a physically well done USB connection. Slightest changes (cable/ground etc.) can make a huge difference.
The input stage incl. XMOS still has a huge impact on SQ even with the reclocker in place. We've been testing several USB cables.
The interface needs a very well done highly tweaked transport. Slightest changes (SW and HW) will make a huge difference. I was really wondering, if the reclocker does its job at all if I run the SPDIF-only base board??.
I just disabled some of my tweaks to see what happens.
Bottom line. If you manage to get all that, plus a top level SPDIF connection/cable, under control. The interface can outperform an Audiophilleo interface.
We've compared it against it.
Then. What makes an interface a real quality interface?? If you ask me, above parameters shouldn't have such an obvious impact.
Basically with this interface you'll never know where you're at. Your tweaking might never end. And that'll cost you time and extra money, without knowing where you're heading.
However. I'm not sure if other interfaces such as the WaveIO do any better. I do think Joro has some homework to do, if he intends to make his product better then today -- better then average.
Advise: Make sure that you'll never have two SPDIF transformers on the SPDIF link! This can happen. You might never experience, what I'm talking about.
The positive side: Our final setup -- using a well pampered JoroIF -- brought us on a level of the Audiophilleo interface. That's not too bad.
Cheers
Last edited:
Sorry soundcheck - not sure I agree with your conclusion. Seems that if a board/component scales well with improved quality of power/cabling, etc. that would indicate the quality of it's design and components used is high.
Also, if you would - clarify how you consider it's average, and yet with good supporting systems (power, input, cabling) it performs better than an Audiophilleo. I owned an Audiophilleo - with and without the battery supply. It sounded very good.
Also, if you would - clarify how you consider it's average, and yet with good supporting systems (power, input, cabling) it performs better than an Audiophilleo. I owned an Audiophilleo - with and without the battery supply. It sounded very good.
Last edited:
Joro's intention with all the efforts he puts into the project by isolating and reclocking, using asynchronous USB with one of the best interface chips, asf clearly outlines his target.
If slightest variations of a digital data stream or the physical conditions (EMI/RFI/jitter/noise) on the input section still show up at the output, my guess would be that he missed his own target.
It would just show the inefficiency of his isolating and reclocking measures. At least to a certain extent.
In my opinion he also has to make sure to achieve very stabil conditions, by properly cleaning up (buffering and filtering) the incoming PS voltages/currents. He even allows
USB power for the input section. Obviously he is convinced that his efforts on the
isolated side are more then sufficient to cope with the surrounding conditions.
I'm just saying there's space for improvement.
In a perfect world, me as a user, would like to end up with the same consistently high soundquality, doesn't matter what USB capable transport we're talking about.
But again. It's not just him or his product. The majority fails on this target. That's what I call average.
Cheers
If slightest variations of a digital data stream or the physical conditions (EMI/RFI/jitter/noise) on the input section still show up at the output, my guess would be that he missed his own target.
It would just show the inefficiency of his isolating and reclocking measures. At least to a certain extent.
In my opinion he also has to make sure to achieve very stabil conditions, by properly cleaning up (buffering and filtering) the incoming PS voltages/currents. He even allows
USB power for the input section. Obviously he is convinced that his efforts on the
isolated side are more then sufficient to cope with the surrounding conditions.
I'm just saying there's space for improvement.
In a perfect world, me as a user, would like to end up with the same consistently high soundquality, doesn't matter what USB capable transport we're talking about.
But again. It's not just him or his product. The majority fails on this target. That's what I call average.
Cheers
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.