XMOS DSD 384 kHz / 32bit USB

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Look at the photograph with the little uf.l connector board stacked on the Joro I2StoPCM board : exactly what I need if JLSounds don't want to increase the quality of the output layout with GSGSGSG grounding arrengement : NOS 384 AD1865 with built in LDR : it don't resolve the unique output gnd pin of the board but help to provide bigger length with coax uf.l wires....

Anybody knows where this little board can be sourced ? A diyer work ?

That was a part from Ian's fifo group buy. it was suppose to be use for the BIII, but i did not go with BIII as you can see... i went for the AD1865 running 384khz :)

It fits perfectly on Joro's board. Actually u.fl provide a better GSGSGSG grounding arrangement... all the U.fl wires are grounded from source to destination and u.fl is preferred than cable with GSGSGSG...

i am still waiting for Ian to start his GB again which he indicate he would... i am buying more of this little pcb plus i2S board and universal clock adapter for future use(8xAD1865 or PCM1704)... guess just to be patient and wait for it...
 
ahaha.... I try exactly the same as you with two dac projects : two ad1862 and one TDA-1541 (the kit is not working with the TDA).

I need uf.l for the tda board.... why fight agin jitter if we have multiple (which is bad) boards before the dac chips with bad matching impedance or unique return path trace for 3 or 4 I2S wires ! At least with this cute board + the Joro's : the problem is not completly solved but the unique gnd pin is very near to the gnd pins of the uf.l connectors... I assume it is better than nothing but notice I can't know without serious measurement : I believe the experienced fellows about the best layout technic and Ian one is SOTA. Joro's board seems very good : I had just asked them if what I believe to be a problem (this GSSSS instead a sota GSGSGSGS) could be solved in a next batch... (as I don't believe multiple boards could be better without good interconnects).
I could be in to buy at the same price this board without the two FOX crystals to swap them by NDK crystals myself (sourcable at DIYhink).

Note it's just theory from myself, maybe it's good enough like that... but when we speak about I2S connection and when people say 10 cm is max with perfect impedance and close return signals path with coax and the layouts in the same spirits between the chips on the pcbs: I doubt about this GSSS output !

Even without uf.l connectors for the output, a simple vias arrengement with GSGSGSG could help to use coax wires soldered between the two pcbs... All those pcbs are a big weak "link" in our diys DACs....

You know the joke about Ian waiting list ? People who wait also for the Iphone 6 makes a nervous breakdown just with the Ian waiting list...:D ... (just a joke, we know it's DIY... Joro, Ian, we support you both... but do you know the price of a good psychiater and medics :joker:?
 
Last edited:
Hi,

...Sincs i am using I2S only, what are the otions disabling SpDif on your board?
...

You can disable S/PDIF, you have to cut the trace marked with red “X” and connect shown points, please see the attached pic. You have to know that the additional firmwares for DACs, which are configured with pin3, won’t be working, because this channel is used for Data R.

The intervention is before the galvanic isolation, i.e. there is no S/PDIF signal at/around the oscillators and reclock.

Regards,
Joro
 

Attachments

  • SPDIF_mod.jpg
    SPDIF_mod.jpg
    164.4 KB · Views: 767
Joro_s.

Gotta question.

I'll get following output of alsamixer on my Linux with your DAC:

Code:
cat /var/lib/alsa/asound.state 
state.X20 {
	control.1 {
		iface PCM
		name 'Playback Channel Map'
		value.0 3
		value.1 4
		comment {
			access read
			type INTEGER
			count 2
			range '0 - 36'
		}
	}
	control.2 {
		iface MIXER
		name 'XMOS Clock Selector Playback Switch'
		value.0 false
		value.1 false
		comment {
			access 'read write'
			type BOOLEAN
			count 2
		}
	}
	control.3 {
		iface MIXER
		name 'XMOS Clock Selector Playback Switch'
		index 1
		value false
		comment {
			access 'read write'
			type BOOLEAN
			count 1
		}
	}
	control.4 {
		iface MIXER
		name 'XMOS Clock Selector Playback Volume'
		value.0 127
		value.1 127
		comment {
			access 'read write'
			type INTEGER
			count 2
			range '0 - 127'
			dbmin -12700
			dbmax 0
			dbvalue.0 0
			dbvalue.1 0
		}
	}
	control.5 {
		iface MIXER
		name 'XMOS Clock Selector Playback Volume'
		index 1
		value 127
		comment {
			access 'read write'
			type INTEGER
			count 1
			range '0 - 127'
			dbmin -12700
			dbmax 0
			dbvalue.0 0
		}
	}
}


Somehow there is a weired assignment of controls "clock select" and
onboard "playback volume" control.

Can you make any sense out of that?

THX
 
Hi,

With your S/PDIF-'fix' i hear a small improvement, like the music sounds more free than before.
Thank you for your feedback. There is no problem the S/PDIF to be turned off by software.

This is my by implementation of this excellent device. All the following instructions are displayed on the JLsounds website. Sounds great! Thanks Lyuben.

I'm glad that my son helped you. Your implementation looks very well :)

Somehow there is a weired assignment of controls "clock select" and
onboard "playback volume" control.

Can you make any sense out of that?
For a pity I’m not a Linux user. As far I understand you are wondering if this is an issue.

Regarding the volume control – the volume control is turned off from the software of the XMOS processor. This kind of volume control is made by every PC player. I personally am not a supporter of that kind volume control, it effectively reduces the using of MSB in the DAC, that’s why I stopped the volume control. I haven’t removed it from the descriptors, because some different OS may have some issues.

Regarding the clock selector – in this there is nothing to worry about. If it was – there would be delaying or hurrying of the music, due to wrong chosen clock.

Regards,
Joro
 
Have you tried native DSD/DoP/ playback with Raspberry Pi..

no Raspberry here, only ARM boards (wandboard quad, BBB, cubie truck).
mpd, alsa, DOP, usb to i2s, dac (joro's akm board, bufallo III, low cost es9018k2m dac, the last 2 in async mode).

for example playing on dsd on BBB takes aprox 5% of cpu vs playing 192 KHz hires file takes 10%, so if you can play 192 files on raspberry you can play dsd as well.
 
I try Raspberry Pi with Volumio..
I can not play any cue files, ape files, DSD iso files..

you cannot play dsd iso files with mpd. you need to split them.
never had problems with proper formated cue files, or ape files, but it depends how mpd is configured.

is not about joro's board, neither raspberry's. try to find help on volumio thread for cue files and ape files. but my advice is to consolidate your music library (transform all of them to flac or dsf files, add the proper tags with picard) and everything will be fine.
 
you cannot play dsd iso files with mpd. you need to split them.
never had problems with proper formated cue files, or ape files, but it depends how mpd is configured.

is not about joro's board, neither raspberry's. try to find help on volumio thread for cue files and ape files. but my advice is to consolidate your music library (transform all of them to flac or dsf files, add the proper tags with picard) and everything will be fine.

It's all a dilettante and amateur..
Do not even cross my mind to be bothered with it..
I'm back on Win7 and foobar, it is space technology compared to Linux MPD nonsense..
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.