The well Source…

[multiblitzParticipant]

…this would be very nice to have…as I clearly can still hear the difference between the Sources with SDtrans384 leading folowed by my old Alix1D with sotm card followed by sotm sms200 streamer…than coming the RP machines much later with Ians mods and battery supply…let alone mini PC or windows sources.

 

So, what make a good source as it seems:

– Slow Components which are just good enough to feed the stream into the fifo…low EMI I guess

– Very good Clocks (sdtrans384) and direct I2S output of highest quality

– Battery supply, no dc to dc switching PSU components

– Open to Standard software still like MPD..or Hqplayer(as NAA)

– Pipe-Principle: The Source in front of the fifo is just receiving and playing a data stream to the fifo. Its a receiver. The main software (even mpd) is running on a separate different machine.

 

The is a longer explanation/ topic of a guy who built this and wrote the software (open source) for such a setting in princiole around the italian Aria g25 Mini Computer. He referred to compiling a special Linux while precisious clocks usage (a special Linux mode you can compile when you do not use a standard distro, but compile it yourself) and he wrote the software for the sender and the receiver units:

http://137.226.152.76/frankl/stereoutils/player.html

This was a hobby project, I will try to rebuild his approach but i am not sure if my Linux knowledge is sufficient and if the Linux version he used is still available or if he is still active as this was a hobbyist approach from a German Hifi forum.

 

But maybe this approach is something for a well source if you ever think to develop one as this is the next big weak piece in the digital audio chain currently. And it plays to your clocks/fifo…and would be completely unique … a different league than any Rp projects.

 

 

[The Well AudioParticipant]

We can plan the digital source development, but it will take very long time.

Now we are working on the Sonic Empire FIFO/DAC (it takes very long time), then ampli and speakers system.
Finally we eill work on the digital source.

We aplogize, but we are hobbiest and not professionals, so our designs usually take long time.

[multiblitzParticipant]

I fully understand and it is a miracle to me how you managed to develop all of this in your spare time…and make it accessible for others sharing your hobby, highly appreciated…

You really want to expand to build amps and speakers…and sell them ? Send them ? Wow. Not even DcS went into this space. Neither Krell and Others…that is a completely different segment…

So I would have thought that a Mini-Source, like a SD-Card-Player, but with Network-Access would play much more in your strength as deep knowledge of the digital and clock domain…so, I am surprised. In the meantime I will start to build this Arias G25 Player and compare…all the best !

[KazumaParticipant]

Oh, this is an bottomless can of worms. Nobody has a clue why this effect exist really. There are many solutions on market now.

Developers of many products spent much effort to perfect those, so

Most smart move would be to just try out several you can land your hands on, to compare what sound they give.

To develop another solution from scratch would be a waste of resources for now, when other projects are more appealing to finish

[multiblitzParticipant]

Well, everybody may have his opinion…but I think Andrea has the right thinking and concept:

 

– Highest quality of clocks (which source has that ?)

– Minimum approach like NOS

– Battery Supply

– Custom Software Development

– PCB-Design which is not for industry but for audio

 

…just initial 5ct…many others either use industry mini computers and standard linux distros like fedora in the sotm…and thos who do their own desigs easily charhe you many thousands $$$…

 

I thonk Andrea gave us with the fifo / DAC alread a huge present…Much above what you can buy commercially, really…

[multiblitz]

multiblitz you have already tried many flavors of, so to speak, digital sources.

And your test reports are always so nice to read.

Many people, including myself are interested in what you will eventually find to be working best.

[KazumaParticipant]

multiblitz, ive read on another forum that you plan to order many different SoCs from Odroid, BEaglebone and others.

There is an important issue you should be wary of.

For example, on yet another forum there is a long thread about BEaglebone.

And people quickly found out that i2s pins get burned very easily.

If you connect SoC i2s pins to a load, when load is ON, and SoC OFF, it fries i2s.

So, general rule is to use any galvanic isolator on pins (but sound gets worse usually), or strictly follow the rule to never power off SoC, while other device its connected to is ON

Just to give you a heads up, so your efforts will not be ruined with something simple as that.

Because you will need a lot of swaps while comparison tests, and better be safe.

[multiblitzParticipant]

Thanks for the hint and the compliments…

 

I am burning lots of sdcard at the moment while the parcels come each day with additional new socs…

 

At the moment I will stick with USB input…but i will certainly try I2S directly at some point as well.

 

..but on this potential I2S burning issue…maybe Andrea can give advise if this risk is given with his fifo as well…there are lots of galvanic isolation chip board oit there i could bring into the game if i have to…but usb/xmos does not sound bad as well already…

[multiblitzParticipant]

Andrea, may I ask you some questions:

– It seems that some people made the experience that a SOCs I2S can be destroyed if the SoC is not powered and its load still is…can you see that risk as well with your Fifo ?

– If yes: When I select the source in your Fifo, i hear relays klicking…does this mean, the I2S source is fully detached ? So if the SoC is not powered anymore but not selected as a source…no issue ?

– Or, do I have to use in any case a galvanic isolationboard when using I2S-Sources (mysdtrans384 sofar had no issues without it btw)

 

And very last question: How do you want the forum be used ? Do you want me to give reports on findings when playing with SoC and Software or shall I use diyaudio or other forums for that ?

[The Well AudioParticipant]

I don’t know much about SOCs I2S, we have not yet designed any source so we have never investigated the possible ways.

Anyway, when the FIFO is on the input is a very high load, several Mohms.

If I have undesrtood your problem, I think you have to power off the FIFO and then the SOCs I2S.

The relays of the FIFO have nothing to do with the inputs, the switch between the two sample rate families (oscillators connected to the FIFO).

You can report your experience here and on diyaudio.com, no problem.

[multiblitzParticipant]

Hi Andrea,

I am working on the subject on multiple fronts: Got a couple of x86 SoC like 8350 and N5100, but as well a dozen different ARM-devices.

Currently I am working on finding the right Linux-Settings which is all about reducing OS-Noise, isolate interrupts and Player-threat, creating my own custom Kernels etc.

One thing which is alread obvious: You can clearly hear the differences between TSC and HPET-clocksource and their respective max-User-frequencies which are customizable in Linux.

 

I found this article on Aliexpress: https://de.aliexpress.com/item/4000382031034.html

I am not interested to buy that as I rely on your clocks obvisouly, but I ask myself: Is this really so easy to bring the whole board to a new level of jitter performance ? JUst excahnge that Crystal like in an old CD-PLayer ?

I thought that this crystal is only used for the RTC clock (battery powered) to keep the time/date when powering off the PC, no ? After boot a PC should enable the crystal within the CPU and than software enabled clock like TSC / HPET take over…but this guy explains a different story…

If it is really that simple…well..than lets try.

[KazumaParticipant]

If you are currently interested in Linux route, please take a look at gentooplayers. com

I was not able to test it fully myself yet, but it looks like most customizable system to date.

Author had already done all the heavy lifting for us. We just need to utilize it correctly.

 

That aliexpress guy explains not a different story, he describes that if you have separate crystals for USB or Lan on your MB, then you can try and swap those (and those mods been done by community for a long time now). Not a RTC clock crystal.

Also, i think HPET timers are deprecated in most modern linux kernels, and the clock sources that are built in CPUs are being used for kernel, yes.

[multiblitzParticipant]

By the way, here my current status on finding a good solution to feed your extraordinary DAC:

https://www.diyaudio.com/community/threads/path-to-noiseless-linux-streamer.391202/

 

 

[multiblitzParticipant]

gentooplayers looks very promising…I need to understand more details on what Kernels with what option they profie in detail as my preference is currently on tickless full, 1000Hz, No preemption etc…but once I found my “preference” in Debian, I will look into the more exotic Kernels out there especially from the Realtime type…and compare Gentoo…It looks like a nice GUI ontop of Linux, so you dont have to learn all the configuration files and syntaxes yourself …which is cool as long as it offers the full set of functionality needed…I will give it a try for sure.

[KazumaParticipant]

I’m not sure about that whole Dante thing. It’s purpose is to stream data to some remote location, often multiple locations.

Like this: convert i2s to custom protocol, send it over lan cord, convert back to i2s at destination.

While we have all our gear in same room.

Seems like a unnecessary link in a chain?

[multiblitzParticipant]

I will have a deeper look into I2S realizations when I cross the bridge, which is not at the moment.

 

I am completely with you: I am VERY suspious about ANY additional chips additionally in the signal path.

 

I learned that the USB 3.0-OUtput which goes directly out of the SoC of the Z8350 sounds SOoooooo much better than the Usb 2.0 OUt where the signal goes through another USB-controller.

 

Equally, on I2S is saw that the NanoPiNeo3 offers as a soundcard “I2S” over Alsa immediately using an included DAC-Chip…which seem to be included in the Rockchip…so as well a solution with the same chip…promising…

[KazumaParticipant]

The only justification that i can think of, is so called ‘last metre’ effect.

When the importance of only last few devices in the chain are playing the role.

Also, regarding Linux.

I remember one thread where a guy reported his experiments that setting ALSA period size and samples per buffer played leading role in quality.

Most pleasant sound was from something like 3 samples, and 2 periods. The lower you can get, the better the sound.

To achieve that, he was using patches for real time kernels, alsa itself, and optimizing the hell outa linux. Because regular installation cannot process those low values just out of the box.

May as well try this also.

 

[multiblitzParticipant]

Well, that sounds like a low-latency guy…

 

I studied computer-science. And i understand roughly what the internals are needed to get to a determined real-time system. But I am not convinced that the overhead, the ultrafast interruption of our pcm data processing is what we want actually.

 

For me the real-time systems bring a certain sound which is very controlled and a cwrtain level of greyness to the music. Tone is suffering, but trebles are super resoluted…But overall, it is more computersound and overall not very natural.

Try it and listen to voices, fines transients of percussions etc…you will see what i mean.

 

Many years ago we played with those Alsa buffers and USB Packs…and it became clear that there are two groups of listenes…the transistor type of guys and the triode lovers type of guys…those who love control and those who prefers a very free, natural representation…

 

I advise to try the exact opposite: Pemption=none. 100Hz timer. As low overhead as possible, as low interrupts as possible. Try it and listen…

[multiblitzParticipant]

plus tickless full, irq and app isolation on cores…so the lowest possible os noise in your device.

[KazumaParticipant]

It was kind of impossible, until rather recently, to configure multi core true isolation setup, because of only 4 core processors available.

I also think thats the proper way to go.

What number of cores do you think a CPU needs to be, to properly immplement such a solution. Would 8 true cores be enough, or need more?

[multiblitzParticipant]

On the I2S implementation, I guess we need a bit of Andrea’s wisdom. The first tough job is to find the right hardware platform. This starts with three criteria to be fulfilled:

– We want a chip which gives I2S in a SoC naturally out in the right I2S mode

– we need a Pin-Out for this particual I2S mode on the board

– we need software support, so that e.g. Debian/ALsa recoginzes this particular combination as a soundcard which we can utilize.

 

Example:

The Rockchip Rk3399 looks like a promising chip. From its datasheet:

“There are three I2S/PCM controllers embedded in the design, I2S0, I2S1 and I2S2.

Different features between I2S/PCM controllers are as follows.

Support eight internal 32 -bit wide and 32 -location deep FIFOs, four for transmitting and four for receiving audio data for I2S0

Support two internal 32 bit wide and 32-location deep FIFOs, one for transmitting and one for receiving audio data for I2S1

Support four internal 32-bit wide and 32-location deep FIFOs, four for transmitting audio data for I2S2

Support 10 channels audio data transmitting and receiving in total in I2S mode for I2S0, 2 channels audio data transmitting and 2 channels audio data receiving for I2S1, 8 channels audio data transmitting for I2S2

Support up to 192kHz sample rate for I2S0 and I2S1, 768kHz sample rate for I2S2”

 

from: https://pdf1.alldatasheet.com/datasheet-pdf/view/1132005/ROCKCHIP/RK3399.html p.701ff

The eight channel 768khz is running at 1.8V…not sure if this what we want ?

 

Now, once Andrea gives us guidance what the right PCM-Controller is we want to use from the Rk3399 (if we want only PCM stereo)…

 

…we have to have a look which board actually will present which I2S signal on their GPIO. I found any combination so far. From No I2S at all to “hidden” in some generic GPIO-Names to I2S0, 1 or 2 so an arbitrary choise which I2S controller of the three goes to GPIO Pins out. If a board maker decides to give us I2S at all in their GPIO, they choose often only one, many times the eight channel 1.8V version…

 

So, which one can Andreas Fifo stand ?

 

ON the suftware side I nee to experiment with I2S. To my surprise the NanopiNeo 3 and its internal DAC/I2S is supported natively by Armbian/Debian/Alsa, I can see the Alsa Soundcard as I2S…need to solder a connector now to Andreas Fifo and see if it works out of the box.

[multiblitzParticipant]

Good question.

Currently my setup is quiet simple:

– one cpu for housekeeping…timers…ticks…apps…IRQs in general

– one cpu for Ethernet IRQs or cifs

– one for USB-Irqs

– One for MPD.

 

Now, with full dynamic tickless on…if MPD is not acive there is NO OS-NOISE at all on that CPU. Which is what we expect. No timer ticks, no Irqs…complete silence.

With MPD on, we have quiet a bit noise. Without FIFO/RT-Prio for MPD this goes up by 30% in OSnoise. With flac instead of Wave this goes up by factor 2-3. With a sample rate conversion this goes up by facor 20-30x !!! Equally 44khz recordings create a lot less OS-noise than 192khz recordings…

This is not what I expected. As a full dynamic tickless mode should see MPD as a thread/ one task and let it run uninterrupted without any OS noise basically. This is by the way the dream of any real-time-fanboy: My app is running uninterrupted on its own core, so nothing reduces latency at all…so in the end both path would come together again.

But this is what happens: MPD creates 4-5 individual threads: MPD, RTIO, flac, etcetc…have a look with HTOP and enable custom names and unhide user threads. So we break the rules of tickless it seems.

I will experiment with an Odorid XU4 with eight cores and see if I give one CPU with four cores to MPD and separate each MPD-thread…what happens than soundwise. ON the other CPU we let Housekeeping and Ethernet and USB run isolated from each other.

Maybe I find as well an app which truely runs with one thread only instead of MPD to get real dynamic tickless support, so we have real uninterrupted PCM-Stream handling…but my suspicion is that a MusikPLayer need to be programmed with full tickless in mind to make that happen and that our level of influence is not enough by isolating userspace-threads alone.

 

Now, seleting the right SoC/CPU is the main topic behind your question I guess…

 

I think we have to weight in other factors there. The quality of OS-clocksources being an important one. x86 has tsc and hpet. arm has something like archtimer I believe…I yet have to compare x86 vs arm with the exact same Kernel and customizations…this is next on my list.

[KazumaParticipant]

Apart from yet unknown reasons (that will be discovered in the future) of why it influences the resulting sound, i think the main culprits are: 1) RF poisoning 2) noise coupling 3) square bus signals ringning.

Those are what we are want to mitigate and clean, basically.

For example, lets see how Berkeley solved those in one of its product:

– (RF poisoning) The “dirty” and ” clean” parts of board are separated by isolated chip. The inscription on the chip has been erased, but I am absolutely sure that it is an AD ADuM chip, isolating the I2S interface channels between the XMOS chip and the SPDIF output.

– (square bus signals ringning) The chip is protected by an unusual ferrite flap. The flap forms a kind of a ring that encloses the chip 360 degrees (above and below the circuit board).

– (RF poisoning) The metal shield further improves the isolation by dividing the internal space into two compartments.

– (noise coupling) One of the coolest design elements of the Alpha USB is the design of the USB input connector. MOST manufacturers make a matching hole in the metal housing and
and put the USB connector in there. But not Berkeley. They made an inch-by-inch slot in the case and inserted the USB connector into a plastic plate to reduce the possible
capacitive coupling between the two elements. Clever move.

Also there is a picture of lossless tech explaining what they have invented as a filter

Attachments:

You must be logged in to view attached files.

[KazumaParticipant]

multiblitz, do you have any contact info that I can use to PM you?

Theres no PM function in this forum format, and on diyadio I think they recently blocked PMs or what, because I can’t create any new messages there.

So I have to ask this somewhere

[Kazuma]

Kazuma Said

I’m not sure about that whole Dante thing. It’s purpose is to stream data to some remote location, often multiple locations.

Like this: convert i2s to custom protocol, send it over lan cord, convert back to i2s at destination.

While we have all our gear in same room.

Seems like a unnecessary link in a chain?

I got a modded Singxer F1 with separate clock supply via LiFePo4 and UlraCaps. The cheap unmodded Dante Monism boards are audibly better.

The interesting thing is that running Windows Server 2016 as RamBoot makes a big difference on the F1, but with the Monism boards the impact is way smaller.

This tells me that a propper reconstuction of the signal is key.

I have yet to feed a dedicated clock to the Dante System, but that’s why I came to this Site.

Greets Klaus

[Author]

Posts