Let me know when you are there...additionally to having those options enabled in the Kernel, you need to have it in the command line of the KErnel when booting...so somthing like "nohz=on isolcpus=nohz,domain,1-3 nohz_full=1-3 rcu_nocbs=1-3 no_balance_cores=1-3"
Hi there.
@Blitz - Welcome to the club.
Since around 2008 I am trying to tell people (over here and elsewhere) what impact PC noise resp. data jitter has on audio performance.
I was pushing rt-kernels for that purpose already than. I've been trying to avoid all kind of load on a PC. Using different CPU affinities and
IRQ and task priorities. Optimizing apps. Asf. Asf. And I shared the stuff - most of it.
I've been facing headwinds about the subject out here and elsewhere since I started with it. (I consider myself one of the very early generation talking about the subject.)
Over the years it turned out that standard measurements won't cover the full audible experience. AudioPrecision even explained in public (Youtube) that their
measurements ( $28k equipment) are limited. That didn't stop those ignorant folks around here and elsewhere asking for measurements.
The founder on that well-regarded platform AudioScienceReview, even was present on that very same AudioPrecision presentation and runs all his measurements
with that gear. And he still pushes the underlying message - "what can't be measured, can't be audible". His intentions are more than obvious of course.
Since there are (almost) no measurements known to nail that situation, the whole subject remains a heated topic.
In the early days we've done some research using a basic tool called audio-diffmaker over at slimdevices forums.
A tool that compares the actual recorded waveforms of "real music". Obviously much more objective than "ears".
It was done analog-out to analog-in on a USB DAC. People (and the testers as well) over there were surprised to learn about
a clear difference, when testing my toolbox against the default setup of the SB Touch.
I've been providing a thing I called squeezebox-touch toolbox to prove my (the) point during those days. The Touch was a very well done Linux based realtime
kernel streamer. One of the first of its kind. And it was tweakable - the OS.
Later on I provided Moode Audio with a realtime kernel and some optimizations. Just to prove the point. The overall logic has always been the same.
"The stream needs a highway, a fast lane. What it usually finds is a bumpy off-road track."
Later on I posted a lot of the findings on my blog.
My latest public contributions was sKit. A toolbox for piCorePlayer.
IMO RPi based streamers are the perfect candidates to be used for the purpose.
To wrap it up.
Your findings in the plots, do not surprise me.
There's a recipe I usually follow:
* realtime kernels are a nice add-on. These are very sensitive though. It requires quite some tuning to get them properly going.
On the RPi the rt-kernel causes a huge load ( in my case ~4%) on USB related stuff. Yep. There are downsides.
* and there's more, though above bullets I'd consider the big points
And finally. Nothing beats a rock solid hardware. The better and more stable the computer hardware the less impact will have
the OS based tweaks. The nice thing about SBCs, such as RPI. These are easily tweakable. Just e.g. add 6*330uF Oscon to
the power rail and take a measurement, you'll see what I mean.
However. For USB DACs I still use external power and filters (iFi). Even my rather modern Gustard DAC made clear, he's
appreciating the whole bunch of tweaks. That got me back to my RPi HAT DAC - a well powered Allo Katana. Despite its
great sound and fair price, it doesn't require all the USB gadgets.
And yes. The better the DAC the more you can question if all the tweaking hassle is worth the effort. I've a couple of audiophile
friends who think it is.
Anyhow. Great to see. That people keep looking into the subject from a different angle. Thx for referring to the kernel tool and sharing
the plots.
Enjoy.
@Blitz - Welcome to the club.
Since around 2008 I am trying to tell people (over here and elsewhere) what impact PC noise resp. data jitter has on audio performance.
I was pushing rt-kernels for that purpose already than. I've been trying to avoid all kind of load on a PC. Using different CPU affinities and
IRQ and task priorities. Optimizing apps. Asf. Asf. And I shared the stuff - most of it.
I've been facing headwinds about the subject out here and elsewhere since I started with it. (I consider myself one of the very early generation talking about the subject.)
Over the years it turned out that standard measurements won't cover the full audible experience. AudioPrecision even explained in public (Youtube) that their
measurements ( $28k equipment) are limited. That didn't stop those ignorant folks around here and elsewhere asking for measurements.
The founder on that well-regarded platform AudioScienceReview, even was present on that very same AudioPrecision presentation and runs all his measurements
with that gear. And he still pushes the underlying message - "what can't be measured, can't be audible". His intentions are more than obvious of course.
Since there are (almost) no measurements known to nail that situation, the whole subject remains a heated topic.
In the early days we've done some research using a basic tool called audio-diffmaker over at slimdevices forums.
A tool that compares the actual recorded waveforms of "real music". Obviously much more objective than "ears".
It was done analog-out to analog-in on a USB DAC. People (and the testers as well) over there were surprised to learn about
a clear difference, when testing my toolbox against the default setup of the SB Touch.
I've been providing a thing I called squeezebox-touch toolbox to prove my (the) point during those days. The Touch was a very well done Linux based realtime
kernel streamer. One of the first of its kind. And it was tweakable - the OS.
Later on I provided Moode Audio with a realtime kernel and some optimizations. Just to prove the point. The overall logic has always been the same.
"The stream needs a highway, a fast lane. What it usually finds is a bumpy off-road track."
Later on I posted a lot of the findings on my blog.
My latest public contributions was sKit. A toolbox for piCorePlayer.
IMO RPi based streamers are the perfect candidates to be used for the purpose.
To wrap it up.
Your findings in the plots, do not surprise me.
There's a recipe I usually follow:
- slim down your OS - just run the apps that are required for streaming. Best: headless operation, no web server, asf asf.
- isolate your audio task. I have just the squeezelite output thread running on a single CPU exclusive
- use full-track RAM playback. Basically you want to be finished with all streaming and DSP before the data hits the DAC.
- make sure your buffers are properly configured. Different DACs and audio interfaces require slightly different settings.
* realtime kernels are a nice add-on. These are very sensitive though. It requires quite some tuning to get them properly going.
On the RPi the rt-kernel causes a huge load ( in my case ~4%) on USB related stuff. Yep. There are downsides.
* and there's more, though above bullets I'd consider the big points
And finally. Nothing beats a rock solid hardware. The better and more stable the computer hardware the less impact will have
the OS based tweaks. The nice thing about SBCs, such as RPI. These are easily tweakable. Just e.g. add 6*330uF Oscon to
the power rail and take a measurement, you'll see what I mean.
However. For USB DACs I still use external power and filters (iFi). Even my rather modern Gustard DAC made clear, he's
appreciating the whole bunch of tweaks. That got me back to my RPi HAT DAC - a well powered Allo Katana. Despite its
great sound and fair price, it doesn't require all the USB gadgets.
And yes. The better the DAC the more you can question if all the tweaking hassle is worth the effort. I've a couple of audiophile
friends who think it is.
Anyhow. Great to see. That people keep looking into the subject from a different angle. Thx for referring to the kernel tool and sharing
the plots.
Enjoy.
I have been studying your homepage and your contributions for many years and enjoyed them very much. A pleasure to have you on board.
I agree with you 110%.
I am in the process of givig different hardware platforms now similar software platforms and see what happens...
And I agree...the better your chain, the more audible the source becomes...even when you have a state of the art FiFo/clock in front of your DAC (and I have Ian's Fifo in nearly any version here as well, got the Pulsar clocks, the Andrea Mori Clocks etcetc, got the Gustard G20, which is a nice DAC, but no comparison to Soekris or Andrea Moris R2R...with DHT-Outstage like the big Lampizator DACs for xx.xxx $)
I agree with you 110%.
I am in the process of givig different hardware platforms now similar software platforms and see what happens...
- many Socs waiting to be compared
- I am rebuilding a bit the Pink Faun 2.16 (xx.xxx$ unit)just to compare it with SoC and see what this will do...
- Up-boards will be ordered as well as they got the latest Elkhard-SoC but with Linux-enabled I2S out directly from the SOC-chips and if Real-Time-OS is our cup of tea: There is the Up 6000 with Atom RE 6425 which brings https://www.intel.com/content/www/u...ime-coordinated-computing-tools/overview.html
And I agree...the better your chain, the more audible the source becomes...even when you have a state of the art FiFo/clock in front of your DAC (and I have Ian's Fifo in nearly any version here as well, got the Pulsar clocks, the Andrea Mori Clocks etcetc, got the Gustard G20, which is a nice DAC, but no comparison to Soekris or Andrea Moris R2R...with DHT-Outstage like the big Lampizator DACs for xx.xxx $)
@soundcheck suuuuuuper interesting points. i will check in detail those suggestions scattered around several posts and your site. thank you
Until someone provides some solid proof any of this is actually audible its all just ******* into the wind.
I've used a good half dozen mac music players, all of them sounded exactly the same itunes, music, audivarnia, bit perfect, songbird, vox, Amarra.
Does anyone actually have any measurements showing potential audibility?
I've used a good half dozen mac music players, all of them sounded exactly the same itunes, music, audivarnia, bit perfect, songbird, vox, Amarra.
Does anyone actually have any measurements showing potential audibility?
Hi Soundcheck,thanks for your intervention,
I use Picoreplayer with your Skit Toolbox since 2 months,great not forward, thanks you,
You no longer use the network But an SSD via USB to store your musical library,What did it bring you?
For I2S user It may be beneficial to deactivate USB on Raspi 4,Do you know The Uhubctl tool,It gives control over USB concentrators.
I use Picoreplayer with your Skit Toolbox since 2 months,great not forward, thanks you,
You no longer use the network But an SSD via USB to store your musical library,What did it bring you?
For I2S user It may be beneficial to deactivate USB on Raspi 4,Do you know The Uhubctl tool,It gives control over USB concentrators.
Let me point out... yes, Linux is a special case. It has always been since the 90s when we started to use it.
Now, for the OP, the jitter in the OS is going to be pretty much for real unless:
(1) You use a real time OS: ie: vxWorks, ThreadX, Integrity, etc...
(1a) In a multi core environment you also need to look at SMP and AMP. Often times, using one core as AMP for IO will remove a lot of the jitter from the other cores that now can run in SMP.
(1b) You can then run a simple loop in one of the SMP cores that polls shared, uncached DDR. If you want, you can always use ONE interrupt to clock the loop.
(1c) In SoCs, the application cores are always so isolated from the peripherals.
(1d) If you are running ARM, make sure to use an R or M core to handle the IO.
(2) Move the AD/DA processing off the core(s) and out to the peripheral device with a time isolated interface and separate clock. Currently I use
2a) Xonar U7 USB, windows 7
2b) M-Audio Firewire, windows XP
2c) RME ADI Pro FS USB, windows 10
3) Nuforce HDP-4 (USB), android
4) Nuforce UDAC2 and UDAC3 (USB), android
5) Burson Play, (USB), android
In the past, whenever I ran plug in boards, I ran Windows NT or XP trimmed down with no other applications running in the machine except for the network interface/stack, Foobar and the necessary device drivers. No Windows maintenance crap... nothing. I tried Ubuntu and CentOS and they were fun, but a PITA to configure. I have also played with the Raspberry 3 and 4 but have moved all processing out the USB bus.
I think the issue with PCI cards in general is that the bus introduces jitter. It's an electronic reality and in order to prevent this, you have to burst the data over the bus. Meaning that the card will use it own clocks to process the audio data. Hence, no matter how non deterministic the cores may be, so long as you can feed the data to the DAC card in time AND so long as the DAC is designed properly the "jitter" from the cores does not affect the reclocking of the AD.
I have spent many years with my nose to PCI bus analyzers and IO boards, programming device drivers, to see this.
Nonetheless, your quest is interesting.
My goal is to get my Raspberries to replace my Androids and Windoze media machines.
Last edited:
An old joke:
If airlines were like Windows, the planes would be beautiful, take off on time and then blow up in mid air for no reason.
If airlines were like Mac, the planes would be beautiful, fly beautifully but if you asked how they worked they wouldn't tell you.
If airlines were like Unix, the crew and passengers would congregate at the gate, bring the parts and build their own damn airplane.
I like building my own airplane. ;-)
I wish I understood what you are doing but iI will try.
It is sadly amusing that there are so many so quick to bring up how nothing matters but numbers and graphs. There is a pandemic here of those, whom I assume, think it is their duty to protect the folks they assume to not share their enlightenment might be "misled" by someone saying something that is not part of the accepted wisdom, the audio science settled by consensus, of people who all think the same and put their critical thinking away decades ago.
I find the numbers and the graphs to be useful but far from definitive. In fact the measurement schemes are as much a crapshoot as anything else in audio. Who knows what they mean if there is no correlation to what it sounds like?
Of course, they will bring up, and I do not believe the story, how Peter Walker never listened to his original electrostatic speaker - just measurements. I guess anything is possible but I would think the best results are brought about when the measurements and listening inform each other. And if it sounds mediocre it is mediocre.
It is sadly amusing that there are so many so quick to bring up how nothing matters but numbers and graphs. There is a pandemic here of those, whom I assume, think it is their duty to protect the folks they assume to not share their enlightenment might be "misled" by someone saying something that is not part of the accepted wisdom, the audio science settled by consensus, of people who all think the same and put their critical thinking away decades ago.
I find the numbers and the graphs to be useful but far from definitive. In fact the measurement schemes are as much a crapshoot as anything else in audio. Who knows what they mean if there is no correlation to what it sounds like?
Of course, they will bring up, and I do not believe the story, how Peter Walker never listened to his original electrostatic speaker - just measurements. I guess anything is possible but I would think the best results are brought about when the measurements and listening inform each other. And if it sounds mediocre it is mediocre.
Well, let me see if I got you right...if we use USB out than we should avoid any USB outou where we go over an PCI bus, right ?
I assume that a USB which is directly coming from a SoC or those USB which come directly from the CPU like with some Ryzen CPUs would avoid this problem ?
That has been at least a bit my impression...purely subjective...those USB outs coming from a controller fed by PCIe sounded always a bit less direct, less clean/clear.
I checked ethernet sources vs. ssd local...different in OSnoise is quiet significant, ethernet is noisy. even when I pit it on its own core, my impression is as well that local storage sounds a bit sharper in focus.
The USB path is "usually" different from the PCI path. PCI is a very noisy environment, indeed it is a very cheap design where the echo'd signal pulses mix with a transmitted pulse to clock the pulse at a given slot in the bus... hence using less power but using a delay mechanism ( for different slot ) that is mostly statistical.
Now then, both PCI and USB controllers are hooked up to the core(s) via an address/data bus. So, given a choice for an external device you'd be better off selecting the one with the least jitter and greatest opportunity for isolation.
When using a PCI bus in a PC, it's very hard to truly isolate the sound card from the power supply noise and phase shifts in the bus, but using a USB device that derives its own clocks and provides its own power supply isolates it very well from the cores and all the noise.
So running a one to one USB connection that is connected internally to the core(s) and does not get routed over a PCI bus, the better off you are.
HOWEVER, all that said, it is possible to implement a PCI card that is very good, but it gets expensive quickly!
Did you play with the buffer size in your network connection?
Ethernet and IP connections are bursty by design.
Noise wise, those are reliable connections so data corruption is addressed and prevented.
No, the ethernet buffer and otimization topic is still on my list...read some articles where people gave tx a different isolated core and rx another isolated core...lots of cores...
I run first of all RTLA and watch osnoise...and that shows ethernet not as bad as USB, but quiet a lot coming from the IRQs...so lots of IRQs=lots of interrupts which may be a source of jitter.
On the USB side, I see two points for improvement:
Nevertheless, I am surprised how well the USB ports in those little SoCs and as well in the big PC sound (Asus Crosshair VII and 8 core Ryzen 5700x in energy saving mode set in the bios, using a Corsair standard PSU at the moment). The Asus Crosshair is what they use in teühe Pink faun xxxxx $ machine...At the moment it play softer with very nice mids (some would say very musical) compared to my Intel N5100 240$ Mini-PC. but lots to learn about this new toy still...
But before investing imto expensive USB-card to solve the issues of pci...I will compare direct I2S out with an Upboard 6000....which brings the I2S controller of the CPU/SoC directly to a GPIO i hope (need to look into the schematic)...(as i saw as well I2S implementations using additional chips which I dont want).
I run first of all RTLA and watch osnoise...and that shows ethernet not as bad as USB, but quiet a lot coming from the IRQs...so lots of IRQs=lots of interrupts which may be a source of jitter.
On the USB side, I see two points for improvement:
- The xmos chip oftently (i2soverusb or Soekris) gets default wise powered by the USB port...so, not using that voltage source.
- Even if you decide to use one of these xxxx$ UsB card with their own OXCO etc...the USB signal gets reclocked by the receiver card before it enters the fifo/dac...so optimizing the receiver card would be equally important I guess...
Nevertheless, I am surprised how well the USB ports in those little SoCs and as well in the big PC sound (Asus Crosshair VII and 8 core Ryzen 5700x in energy saving mode set in the bios, using a Corsair standard PSU at the moment). The Asus Crosshair is what they use in teühe Pink faun xxxxx $ machine...At the moment it play softer with very nice mids (some would say very musical) compared to my Intel N5100 240$ Mini-PC. but lots to learn about this new toy still...
But before investing imto expensive USB-card to solve the issues of pci...I will compare direct I2S out with an Upboard 6000....which brings the I2S controller of the CPU/SoC directly to a GPIO i hope (need to look into the schematic)...(as i saw as well I2S implementations using additional chips which I dont want).
Today I finally got around to taking out the Burson Swing... using it strictly as a DAC. Plugged it into my Samsung Note 8 via USB OTG. It sounds really good. But, since I don't have the fancy driver in my phone, it only does 48Khz. Next I will try a Dell laptop and see how that goes. As it is, it sounds very good... Really good. And it also gives me the option of two different filters... so I'll get to play with them. I don't expect it to sound nowhere as good as the RME ADI Pro RS (an AD/DAC) but then it didn't cost so much... got it on their sale a couple of years ago.
I2S is a complication. I'm not quite sure of its future... with USB-C and its very high speeds. well... it reminds me of how GigE killed off ATM (Asynchronous Transfer Mode) except perhaps for backbone links.
SoCs are incredible nowadays... specially the ones in the smart phones. I've been working with SoCs now for seven years and they keep astounding me. Particularly as they tend to be ARM based and the limitations of the PC and Windoze don't apply. For one thing, being Unix based, they don't need special drivers. Except that Android still has that issue with 24/96 (Note to self... did they finally fix it? I haven't paid attention for the last two years on that issue).
As far as running things in SMB (core affinity) I wouldn't worry so much. Unless you have access to the internal workings of the firm/software there's not much and from a PC point of view, I figure that the DAC sits out there by itself, if you have USB2+ running asynchronously and the DAC has its own power supply. At that point, who cares?
Ethernet and 802.11xx... you are worrying too much. Again, once you move your DAC to an outboard USB set up, you won't care. Interrupts? Don't worry, so long as you are not running a very old machine with lots of graphics and other processing. For the last 20 years, the peripherals have gotten very smart and they will do DMA by themselves, transferring data from peripheral to peripheral without the cores ever getting involved.
Interrupts... well, if you have large buffers in your networking set up, you won't see lots of them. Even so, properly done, the core won't see the interrupts. I think you're worrying too much ( Comment: I've paid the mortgage for many years writing device drivers and ISRs).
Speaking of 801.11xx... I hear no different between running my Android with Tidal from locally stored files in the SD card or streaming them over the 801.11ag I got in the house (TCP at work too). The main tricks here are to ensure that the ISP WAN connection is good and you don't use the phone/tablet for anything else! Even with two people in the house watching Netflix and having the Rokus recording online streams, I have not had an issue yet with network capacity. Remember that audio is very low work....
....You might want to get something like a Dell MFF with an i5 or i7 and use them solely for audio. That works for me quite well. Those run wired gigE. IN fact, my 801.11ag access points are wired into the home's gigE LAN so I have lots of capacity left over within the home LAN.
Oh, friends don't let friends use the onboard audio... whether it be a PC, a smart phone, a Mac... even with my cell phones and tablets I use a portable USB DAC. One of them has its own battery power even!
Last edited:
@Blitz
Thanks for tackling this project. I understand about 1/2 of what you're talking about, but I do believe there to be something there. One of the first things I'd like to try is to find an SOC that will allow me to separate the power from the mainboard and some kind of USB add on card. Meaning the hat or card or whatever can be powered separately from the rest of the device which seems simple enough, but I haven't been able to find such a thing. It seems like it would be easy to achieve in a PC environment where a modular power supply would create the ability to power each peripheral separately if one chose to. If it exists, could you point me in the right direction? Either way, I'm subscribed to this thread now and look forward to following your progress.
I
Thanks for tackling this project. I understand about 1/2 of what you're talking about, but I do believe there to be something there. One of the first things I'd like to try is to find an SOC that will allow me to separate the power from the mainboard and some kind of USB add on card. Meaning the hat or card or whatever can be powered separately from the rest of the device which seems simple enough, but I haven't been able to find such a thing. It seems like it would be easy to achieve in a PC environment where a modular power supply would create the ability to power each peripheral separately if one chose to. If it exists, could you point me in the right direction? Either way, I'm subscribed to this thread now and look forward to following your progress.
I