Ahhhhh...magnifico...

[Bromf]

Just sublime...... AK you're the best !  latest Snakeoil is  magic....  I don't know how you do it but every release sounds better and better....!  and has more features...
I am on dishes duty....;-).... with Snakeoil playing Ancient FM (yes, it is a thing) and the Shahinians are cranked up...... oh Heaven ! (except the dishes thing...lol...)

[agent_kith]

Just sublime...... AK you're the best !  latest Snakeoil is  magic....  I don't know how you do it but every release sounds better and better....!  and has more features...
I am on dishes duty....;-).... with Snakeoil playing Ancient FM (yes, it is a thing) and the Shahinians are cranked up...... oh Heaven ! (except the dishes thing...lol...)

Thanks Bromf. I would like to think because it's due to my knowledge in computer technology and music. But honestly, so far along this journey it does seems like pure dumb luck.

Recently when I plugged my old DAC (TDA1541 chip with a valve output stage fed I2S from a Digital Interface) back into the system, the emotional connection is gone. That is because the later Snakeoil releases (Golden Ears and Blind Testing) are optimised for my current setup while the older 0.1.x is optimised for my old DAC. It's interesting how the OS can be tweaked in such a manner.

This shows how important it is to find that tweak that will really make your own system sing. A big part of this tweak is kernel rolling (not just version changes, but also turning features on/off). This 'big idea' can be simplified into these two slogans:

1. Music, your way.
   
2. Designed by us, defined by you.
   

Hopefully I can set up a system to make it even easier for everybody.

For this to really work, we need to find a group of people who are really good audiophiles. Not the kind of arm chair experts that's a dime a dozen on the Internet, I'm looking for the real deal.

As an audiophile, I only know timbre, micro details, imaging and sound localisation. Snakeoil Golden Ears and before are all designed with those 4 attributes in mind.

Then a friend dropped in and tells me my system's  "sound is too slow". He then went on to describe what he meant, and showed it to me his idea of how music is supposed to be. With that in mind I started experimenting on what needs to be done to get that 'speed'... And found it via CPUset. Finding that speed without compromising the other aspects. At the end of the day, it's really more luck than skill.

A lot of luck to discover the tweak, and a little bit of skill to notice the change.

If you compared Golden Ears vs Blind Testing. The key difference is that speed, the music just feels less lethargic in Blind Testing when compared to Golden Ears.

[JD1]

+1 on the improvement. Many thanks to Agent Kith. 

I'm keen to be involved with kernel rolling.

I've played with CPUset and would really like it if this feature was advanced to allow us to individually assign a CPU to each process. Someone on this forum showed an example interface but I just can't find that post anymore. 

AK; did you hear the CPUset effect with LMS/SL? and do you only have 2 CPUs?

[agent_kith]

+1 on the improvement. Many thanks to Agent Kith. 

It's my pleasure. Don't expect an improvement every release though.. At the end of the day, none of this really makes any sense and it's all done by trial and error.. Errors are bound to happen.

 

I'm keen to be involved with kernel rolling.

Still an idea at the moment, waiting on spinning up a new server to do this (for security reasons). The idea (pipe dream) is:

1. User goes to a Snakeoil website
   
2. User gets presented a web page
   
3. User gets a choice of kernels to choose from, and a list of options (e.g. he may want to enable CPUFreq, a network card, or a particular USB or audio card)
   
4. User submits his request -> Server will do it's thing -> server sent an email to the user when the kernel is ready,
   
5. User download the kernel, applies the kernel (I'm thinking of automating this straight into the Snakeoil WebApp), and reboot
   
6. Viola, kernel rolling is done.
   

This is the server method. But it cost money. The alternative is to do all this inside the Snakeoil OS itself. But it gets harder to share their builds (they can block this if they want)..

Doing this via a public server means any kernels built can be shared by others - and nobody gets to keep their secret receipes for themselves.

 

I've played with CPUset and would really like it if this feature was advanced to allow us to individually assign a CPU to each process. Someone on this forum showed an example interface but I just can't find that post anymore. 

Future releases will improve on that I think. It just gets complicated real quickly hence the reason for keeping it simple for now. Until then, SSH into the system directly, create more CPU sets and further isolate the processes.

AK; did you hear the CPUset effect with LMS/SL? and do you only have 2 CPUs?

The only effect I have is the speed (and improved 'blackness', for a lack of better term).. And yes, this is with LMS/SL... What other effects did you hear?

And yes to only 2 CPU cores... It's an old Jetway after all.

[JD1]

AK; did you hear the CPUset effect with LMS/SL? and do you only have 2 CPUs?

The only effect I have is the speed (and improved 'blackness', for a lack of better term).. And yes, this is with LMS/SL... What other effects did you hear?

And yes to only 2 CPU cores... It's an old Jetway after all. 

I have 4 CPU cores. I didn't hear a big difference but found that I preferred just 1 core for user. 3 cores for user was next best and 2 cores for user was the worst.

Just made me speculate that there is benefit to having all user processes on a common core but that there might be further benefit in also keeping certain system processes on a common core; i.e. separate to the user core but never switching cores.

This was using LMS/SL.

[agent_kith]

I have 4 CPU cores. I didn't hear a big difference but found that I preferred just 1 core for user. 3 cores for user was next best and 2 cores for user was the worst.

Just made me speculate that there is benefit to having all user processes on a common core but that there might be further benefit in also keeping certain system processes on a common core; i.e. separate to the user core but never switching cores.

This was using LMS/SL. 

With only two cores, my experiments are pretty limited. Tried:

1. Squeezelite only
   
2. Squeezelite + LMS
   

With 2 being better than 1. Other things to try is to move the network process over to the same set. Which leads me to think if it's possible to use the link local (127.0.0.1) for Squeezelite instead (not entirely sure if this is possible)...

These features will all be added in due time I guess..