Thanks so much Blitz.
I run everything exclusively on lifepo4.
280A for amps. A123 for clocks dito for analog side of Dacs inkl Maxwell caps. Would a cpu of the mentioned motherboard also run on 3.2 to 3.3 volts from the 280a battery directly? The board should run at least 20 hours without dropping more than 0.1 Volt. If that will not work I got a few double LT3045 regs that could be stabilized by the mentioned super caps.
I run everything exclusively on lifepo4.
280A for amps. A123 for clocks dito for analog side of Dacs inkl Maxwell caps. Would a cpu of the mentioned motherboard also run on 3.2 to 3.3 volts from the 280a battery directly? The board should run at least 20 hours without dropping more than 0.1 Volt. If that will not work I got a few double LT3045 regs that could be stabilized by the mentioned super caps.
Hi, I read the document, I'm using a RPI4 now with Ian Canada Transport PiDigi & PurePI Life4PO batteries running latest Dietpi.
I see you set up MPD as music server/player/local library. What controller interface do you use to play music?
As for MPD core affinities, I see you restrict MPD to 4-8 cores. For a RPi4 that has 4 cores, which affinity do you recommend? I've thought of isolating core #4 to MPD exclusively by removing #4 core affinity from the rest of the RPI services.
I'm using Upmpdcli as a Upnp renderer and an Android phone as a Upnp controller from a Upnp Music Server by sharing a USB Upnp media drive on my network router.
I've also isolated core #3 for Upmpdcli renderer service exclusively. Is it a good practice to isolate one core for Upnp renderer and MPD each? Or is it better to use all cores and just realtime priority for both services?
I'm using power save governor with 300 MHz minimum frequency for the moment. I'm planning to build RPI present kernel to enable tickless kernel.
If I were to use a local library for MPD, which controller/player app do you recommend?
I see you set up MPD as music server/player/local library. What controller interface do you use to play music?
As for MPD core affinities, I see you restrict MPD to 4-8 cores. For a RPi4 that has 4 cores, which affinity do you recommend? I've thought of isolating core #4 to MPD exclusively by removing #4 core affinity from the rest of the RPI services.
I'm using Upmpdcli as a Upnp renderer and an Android phone as a Upnp controller from a Upnp Music Server by sharing a USB Upnp media drive on my network router.
I've also isolated core #3 for Upmpdcli renderer service exclusively. Is it a good practice to isolate one core for Upnp renderer and MPD each? Or is it better to use all cores and just realtime priority for both services?
I'm using power save governor with 300 MHz minimum frequency for the moment. I'm planning to build RPI present kernel to enable tickless kernel.
If I were to use a local library for MPD, which controller/player app do you recommend?
I personally use an ipad and soundirok, but i play pcm files from a NAS.
If you use HTOP and customize core view into it, you can see what is going on on your cores. You will see that MPD is not just MPD. It is MPD plus 3-4 sub programmes which MPD calls as parent app.
I am not using Upmpdcli, so not sure how it works with MPD and is should have its own core and who feeds whom with data and kf this stream is buffered by MPD in ram or not...i guess it is not for locally stored files ?
For Rpi 4, i recommend core 0 for Linux and all other non audio apps, core 1 for usb output and core 2-3 for your audio apps, maybe even grouped like this and let Linux decide how to use core 2-3 within the audio apps called.
If you use HTOP and customize core view into it, you can see what is going on on your cores. You will see that MPD is not just MPD. It is MPD plus 3-4 sub programmes which MPD calls as parent app.
I am not using Upmpdcli, so not sure how it works with MPD and is should have its own core and who feeds whom with data and kf this stream is buffered by MPD in ram or not...i guess it is not for locally stored files ?
For Rpi 4, i recommend core 0 for Linux and all other non audio apps, core 1 for usb output and core 2-3 for your audio apps, maybe even grouped like this and let Linux decide how to use core 2-3 within the audio apps called.
The I2Soverusb has isolated barrier only with USB side, BUT micro-controller after isolation has high "issues" same sort as You describe in the topic. Please take a look at the data-sheet.
And it is not the USB galvanic isolation - it is after USB isolation - followed by noisy micro-controller (with all mini internal modules like buffes, memories etc...)
.
The true USB isolation will be.
0. made proper USB protection at the slave chain (look at the wurth)
1. redrive the USB line from any source at the computer USB terminal. To drive cable...(with TI redriver devices, see the measurements...)
2. optionally re-clock the USB line. (need a good oscillator and hub IC, take a look at the silanna papers)
3. Make galvanic isolation from all previous supplys and OS noise leftovers... With new series og proper speed, non-programmable devices.
-------
USB is isolated, re-driven and optionally re-clocked...
Then go to any USB-I2S device
4. isolate after I2S forming the bus, again that is cannot be done without use of some programmable device microcontroller etc etc...
.
For instance, Thunderbolt has already optical isolation baries in every cable connector and very good drivers.
But it is a mystery why it is reserved for "pro" segment of audio industry almost exclusively?
Firewire is much better also...
.
USB is simplex type of data transmutation via diferentioal pair of wires, so every time the information need to be recever from the downstream device the main stream has to be interrupted.... Like one railway with 2 opposite lines of trains...
for I2SoverUSB the path is: again please take a look at the datashhet and PCB photo
1. no usb isolation xmos accepting the USB
2. Isolation after XMOS
3. CPLD or microcontroller after isolation
4. Digital bus output.
...
So there is no isolation after high speed, noisy, micro-controllers.
.
From DAC in reverse: before DAC - direct microcontroller I2S or other format bus. Not isolated from MC...
CPLD is not a microcontroller so it is less noisy. And I did not say there is an isolator after that. But CPLD does the reclocking and isolator after that would make the reclocking pointless. So either leave the reclocking out or accept possible noise from CPLD.
This is a "half" reclocking - just one Flip flop per line. Potential cause of metastabile state and lines are delayed 1/2 of master clock F.
Better recklock is to put 2 x serial FF for each line. And use separate usualy double FF package IC. In that case delay will be 1 cycle of master clock for all, no metastabile state, and no "mixing" of the different frequencies inside the IC...
.
And off-course re-clock should be a part of input circuit of the DAC (with attenuated output lines to DAC according to the LO/HI values specification.
.
About CPLDs / Micro controllers
THey are high speed, high density programmbile devices. Inside these ICs happening exactly the same nature processes that explained in the software side in this topic. They are more than sufficiently capable for task they are doing managing the usb audio... Some software running the devices too...
So I think that on the hardware side should follow the improvements in the software area to get even better results?
About USB galvanic isolation I tried Silanna IC, my design and Silanna demonstration board too with DC-DC converter. (mac platform)
And i was very satisfied with the result. The sound was clearly more "analog", better voices, less harsh, less "preasure" in beguining of HF region. etc. etc. And few other people spot the same.
In These days Silanna was only manufacturer of non-programmble stand alone IC for audio usb speed isolation.
But they stopped to produce these iso ICs
Fortunatley - recently there are some known brands offering their solutinos in the same field. LT and AD I think?
I am sure that the results will be the same.
And i was very satisfied with the result. The sound was clearly more "analog", better voices, less harsh, less "preasure" in beguining of HF region. etc. etc. And few other people spot the same.
In These days Silanna was only manufacturer of non-programmble stand alone IC for audio usb speed isolation.
But they stopped to produce these iso ICs
Fortunatley - recently there are some known brands offering their solutinos in the same field. LT and AD I think?
I am sure that the results will be the same.
I agree that reclocking (if even needed) should take place at dac board instead of USB-I2S board. Which is why on my USB-I2S board I have omitted reclocking and use a high speed isolator after MCU for all output&input signals.
CPLDs and MCUs are different beasts. Noise of CPLD is not much different from discrete logic ICs.
If you think noise from CPLD in I2SoverUSB is audible then you should prove it with measurements. Unfortunately this thread seems to be all about beliefs and subjective opinions rather than measurements.
You insist on this but nobody said that they are the "same"?
Point is that they have one common thing - program controlled, high speed, ultrahigh density and so.
Much of the issues this topic covered in computer system.
.
Unfortunately, every usb-to-digital stream audio has these devices, software controlled on the plates.
.
The very good thing about the I2Soverusb is doubled F of oscillators comparing to other devices same function.
That is good for max reclocking limit to 1/2 of MCK that clocks the lines. 45.1584/49.1520MHz oscillators are used
and limit for reclocking is 352.8kHz 384kHz
(with "standard" MCK oscillators of 22.5792/24.5760MHz we can recklock only up to 176.4kHz / 192kHz
Because BCK is equal to the master clock F (22.5792/24.5760MHz) and cant be reclocked with the same F clock. Should be at least 2n (n=1,2...) higher
.
This is the very good interface, many features etc.
But somehow I not prefer XMOS digital audio usb
For me it is more harsh and edgy, with more "digital" sound.
But maybe I am wrong...
The temperature of CPLD/micro-controllers have significant impact on sound. Even if they are just warm if you put the IC heatsink, larger one on the top, sound will be better. (bare in mind other close complonents - use standard dimmensions and thermal tape glue). It is not hard or expensive to investigate - You will be surprised.
Expecially on the XMOS ICs, (Savitech too) they consume a lot of [mA], And they can heat up significantly, in the closed chases is always more...
The temperature should be low as possible. The ICs offcourse, without heatsink, can stand these temperatures - BUT sound will be better.
Expecially on the XMOS ICs, (Savitech too) they consume a lot of [mA], And they can heat up significantly, in the closed chases is always more...
The temperature should be low as possible. The ICs offcourse, without heatsink, can stand these temperatures - BUT sound will be better.
More of an aside than an addition to the thread - I added roonbridge to BLITZKLANG and now I am listening to QOBUZ through my control machine using roon.
roon makes it easy along with converting the flac files to wav before sending then along. I agree that is a rather expensive way to to that but it seemed to be the easiest and least impacting way to do it. Of course, that should be read as the easiest way I am aware of doing it. Very pleasantly surprised by what I am hearing. Now I will never be able to decide what to listen to.
roon makes it easy along with converting the flac files to wav before sending then along. I agree that is a rather expensive way to to that but it seemed to be the easiest and least impacting way to do it. Of course, that should be read as the easiest way I am aware of doing it. Very pleasantly surprised by what I am hearing. Now I will never be able to decide what to listen to.