So you have found that configuring an application changes the sound.
Which is better?
Did you try a different DAC? What kind of a DAC were you using? What is the configuration? What are the applications driving the DAC?
I mean, it's not unexpected, actually expected, that you would hear a difference. When I use to run PCI DACs I found out soon enough that Cubase and FooBar where by far the best sounding. I had a dedicated machines to do this, btw, typically running at less than 50% CPU capacity. However, once I moved to a Firewire PCI card with a Firewire connection, the differences disappeared.
I think it’s all in good fun. I think most of the folks involved in this conversation have multiple Dacs. I think a lot of us are heavily invested in time and or money in this hobby and are at a point where 2% gains here and 2% gains there mean something. This topic didn’t interest me until I tried vitOS and realized it sound different than ropieeee. That made me ask the question that if these two OS’s can sound different, likely based on system settings, what else can? I’m likely not making another speaker, dac, or amp change in the near future so this is a fun way of staying active in the diy hobby.
As for the hats are noisy comment, most of them are connecting to i2s and powered from an external supply. I don’t have an i2s dac so I can’t really play that game.
That said, your background might make you the right person to ask this question. How much goes into the host boards for the compute modules? Would that be an easy enough thing to outsource design of and get printed in small batches? I love the idea of a board with superior components and implementation. Is this as plug and play as it seems or are we talking deep waters?
No, everything is the same expept the hardware. MPD, OS everything the same.
I have 10 different dacs. But i dont care. Andrea Moris Fifo Dac is my preference by far (thewellaudio.com). So, i dont go back to less capable equipment. Would not make any sense. The whole point is to give this unit a source which is as capable.
It's a very expensive "hobby" to build your own boards nowadays. It always has been. Most of the stuff is surface mount, I think all since the late 80s. There really are no "superior" components for such things, mostly it's consumer, industrial, aerospace or mil-spec. (*)
Your best option is to buy a reasonable board, like the Pi and then build your own RTOS, or just go bare metal, with no OS.
You could always look for an industrial SBC (single board computer) and build your own kernel for it. Than just install (write) your own BSP (board support package) that includes only the device drivers you need, no more, no fancy graphics, etc...
You really are much better off, writing your own streaming application for a Raspberry Pi board, assuming you insist on working at that level. It will give you the most bang for your software. That's exactly what the Pi was designed for. It's a very fun product.
(*) As an aside, in the projects I've participated where we ended up building our controller SBCs, we ended up spending fully 1/4 of the budget in the power supply. But pretty much, people just buy their SBCs, there is little to be gained by building your own. You gotta look at 10K per board, so that's why the Raspberries are such a breath of fresh air.
So, you are keeping the DACS the same, keeping the same application, but changing the single board computer, is that right?
hmm maybe, but if it makes a difference with a 500-1000€ dac, it will also make a difference with higher priced ones and its one of the few things that can actually tweak the sound for free...
i mean... i use a device to aditionally completely galvanic isolate the dac completely from the raspberry pi and it still makes a difference
i cant pinpoint on stuff that is actually the culprit, the best thing i can tell that i "guess" its osnoise, jitter and stuff since there is notably difference in sound if we change settings that tackle these two things
for me the biggest eye opener was testing windows vs linux alone (even with windows + asio/wasapi) it just doesnt sound the same, pulseaudio also sounds considerably worse than a alsa only setup on linux
why so many say moode/picoreplayer sounds better than volumio if it all doesnt makes a difference...
its hard to argue with objectivists and better not done at all, either you heared it or you didnt
I've got a pretty nice power supply that cost significantly more than any of the SBC's cost. I disagree about the components thing, but I also wasn't clear. What I meant was that a board could be designed without switching components, possibly a better performing USB bus. I don't know if the clock is on the module or the host board, but perhaps that could be upgraded as well. Let's stop hijacking @Blitz thread though as I feel we're veering off topic. I did actually create a post about this a few days ago if it's something you're interested in discussing further.
https://www.diyaudio.com/community/...uter-manufactuer-ranking.392827/#post-7189657
(1) The better DACs have better isolation from the source. Not necessarily the most expensive. Look at RME, they are semi-pro, so the have the volume to keep their per unit non recurrent costs lows.
(2) Forget Windows, forget Apple... try running Android or Raspbian in kernel mode only. Get rid of those applications, write your own.
(3) I believe in the sound of music, Ruskie tubes, Class A 2nd order harmonic distortion, LPs... so call me a realist. Science is never settled, it's just a model, it's not complete. Only non scientists, and parlatans, think otherwise.
The OS is different, the BSPs are different, the device drivers are different, the application software is different, the grounds are different.
What is the connection between the DAC and the motherboard?
The USB clock is provided by the motherboard because you have to be able to communicate between the cores/DMA and the registers in the USB peripheral.
BUT, the streamer is running in the cores, using either DMA or memcpy() to move the audio data to the USB. It NEVER sees the actual clock between the USB devices, indeed, it never sees the USB at all.
I just think this thread has the wrong title then.
I think its a mixture of a lot of stuff...as usual...but its a solid starting point to agree...no matter how good your fifo or dac is...the source infront of it MAKES a difference.
After that you can start to try to structure the root cause...same software, different hardware or vice versa...but that is the fun part and sharing your findings...its a party.
The Os is the same.the application the same. You are just throwing nebular bombs...sure the device drivers are different as hardware is different...not getting your point...as it is pointless.
Anyway. I am not imterested in debates from which I cant learn anything to improve SQ.
No. As we dont discuss USB here as the inly topic. It can happen that I2S is the winner...the q7 is burning in...
Wait. no, the OS is not the same, the applications are NOT the same, the Board Support Package is different, and THAT is the crux of the matter!
You are hearing differences in the up front part of the audio stream because the SYSTEMS are different.
I am not throwing nebular bombs, I'm asking very SPECIFIC questions because we're dealing with what I've been doing for over 40 years at work. That's why I am curious at what your SYSTEMS look like. I've spent most of my life looking at instruments and writing firmware to know this. Don't dismiss my questions just because you don't understand why I'm asking them, I will be more than happy to explain why I'm asking them to you.
I2S is driven by a peripheral device too. The cores don't execute the transaction, they only command it.
However it's somewhat of an ancient interface by now.
I was in a group where we programmed the I2S interface, amongst many others, in an ARM based SOC. We used it to transfer the audio data rendering from media files to the multimedia core (*). The built in DAC sat in there. Data went via DMA on an AXI bus. Our media decoders had quite a bit of DDR caching.
(*) Not to be confused with the application core.
Well, i think we agree on the fact that dofferent hardware has different layouts has different devivüce drivers as it has different components etc. Your definition of OS seems to vary, why so ever. Yes, the menu config of kernel.org (same version) has depending on the hardware here and there some other small difference, but 95% is the same. Be it timer subsystem, timer frequency, thread handling, even tracers etc.
Anyway, i could equally come up with war stories from my times of as application developer...but that would not be relevant...if it doe not translate into something which is relevant to a new setting which is audible for the topic we discuss here. So, what are settings you believe could make a change we should try from your experience is the question ?
Long general statements about windmills or your war stories froma very specific example of the past of a very specific SoC which we even maybe not discuss here yet as application is different dacs are etc...well...not helpful.
Anyway, i could equally come up with war stories from my times of as application developer...but that would not be relevant...if it doe not translate into something which is relevant to a new setting which is audible for the topic we discuss here. So, what are settings you believe could make a change we should try from your experience is the question ?
Long general statements about windmills or your war stories froma very specific example of the past of a very specific SoC which we even maybe not discuss here yet as application is different dacs are etc...well...not helpful.
My definition of an OS is very constant. It is an application. I know what an OS is since I have written stuff like task switching, task schedulers, IPC mechanisms, etc.. at the OS level. I can port an OS on different platforms using adaptation layers, for example. You don't need an OS to do things, you can always go "bare metal" which is the fastest, most deterministic way of doing it.
Now, think of the BSP, the board support package, as the firmware that allows the OS to run. When you change parts of the hardware, the BSP changes. If you go bare metal, your BSP becomes monolithic.
Sure, you will keep the bootstrap separate.
I also talk about doing whatever you're doing within an OS in the kernel, not in a process. That's the least latency, ie: "jitter".
Once again, what are you trying to achieve? Best sound? Sure you can achieve changes by modifying the application software but that's ignoring the 600 lb gorilla in the room.
You are trying to make a DAC run over an I2S bus using the power and clocks of your SBC ( or motherboard for your Windows set up). OK, but there are better busses to do this to begin with because they isolate the DAC from the motherboard electrically (noise, clocks) and temporarily (your caching). That's why I pointed out that for the best sound and least interference from the hardware and software the way to go about this is to use an outboard USB2/3 DAC. Best if it has its own power supply.
Note: actually, you could try an optical interface too.
Why don't you keep the software constant and modify the DACs over different interfaces? I got a NuForce HDP4 that has several inputs: analog, DAC and optical. Try to get something like that, see which sounds better. I found the USB to sound best.
My advice is to try changing the hardware first. Only then try to compare different players.
Oh, I wasn't one SoC.... we were developing six SoCs from three families every year.... and then I've programmed ARM in COTS SBCs for eons as well. I've been doing this for quite a long time. My first home brewed media machines were built in the early 90s with Windows 3.2WG. So I can say I've been doing something like what you're trying to do, except that I look at it from the driver point of view, not the application, for quite a long time.
I like Don Quijote. Giddyup Rocinante!
im not sure if usb is the best interface for this, i use a galvanic isolator (topping hs01) and things like usb cables/usb hubs, even a ifi isilencer after the isolator still makes a difference (and as far as i remember also kernel/os changes STILL make a difference) but im definitly with you on trying out different interfaces, for example spdif instead, maybe the galvanic isolation from optical is actually a good compromise to having theoretically more jitter if we use a good reclocker, ian canada also offers a galvanic isolation board for i2s, many people (subjectivits) seem to report that i2s/spdif is superior to usb
but also most spdif board have galvanic isolation over coax spdif without the jitter disadvantage over optical
you definitly have a point there but this doesnt exclude the sbc/computer from having still a effect on SQ, even if it seems unlogicial (i know it objectivly doesnt make sense but...)