Snakeoil Forums

Well I posted that error message here in the wrong thread and also confused things with the native DSD option...D'Oh.

MPD: Native DSD did not work for me on 1.0.9 or the alpha FW with any version of MPD and for options I typed one of the following:
dsd_native_type "0"
dsd_native_type "2"
dsd_native_type "3"

I then gave up on that and tried to return to LMS/SL; using the alpha FW. I was really commenting on the bigger problem that SL will not start with the alpha FW. In fact, 100% failure over the last 20 attempts. The error message is always the same (as I posted on correct forum), except for one time when I got the error message above.

That was for SL and not MPD. As you noticed, I was still messing with native DSD settings at the time and was trying to put one of those options into SL when that long error message appeared.

I'll move back to the alpha thread now...sorry about that.

(03-Mar-2018, 02:40 PM)JD1 Wrote: [ -> ]Well I posted that error message here in the wrong thread and also confused things with the native DSD option...D'Oh.

MPD: Native DSD did not work for me on 1.0.9 or the alpha FW with any version of MPD and for options I typed one of the following:
dsd_native_type "0"
dsd_native_type "2"
dsd_native_type "3"

Now I know why you had so much difficulty getting it to work, and I had none back in the day. Because I'm using the iFi .

Right now only these DACs will support native DSD in Snakeoil.

1. iFi Audio micro/nano iDSD
   
2. Matrix Audio X-Sabre
   
3. Matrix Audio Mini-i Pro
   
4. OPPO HA-1
   
5. Gustard DAC-X20U
   
6. DIYINHK DSD DXD 384kHz USB to I2S/DSD
   
7. JLsounds I2SoverUSB
   
8. Aune X1S 32BIT/384 DSD DAC
   
9. PS Audio NuWave DAC
   

If you have one of the DACs above, plug it in and try native DSD again. It should work with mpd-dsd-rt if you force it. MPD 19 and 20 should auto detect, but I didn't test this back in the day as the feature wasn't released.

The only upside I can think of is you can play higher rates DSD . What other benefits do you reckon native dsd will bring?

In theory should be able to get Snakeoil to support more DAC devices. The only thing I need to do really is put the kernel source code somewhere in the open so as not violate GPL (because I am modifying the code). Hopefully will have something at the end of the month .

Yay, we are on the same page now. Need to enable for each DAC type but I was never gonna work out how that is done. Glad you are on the case  :thumbs:

There are still some people claiming native DSD sounds better and I'm not interested in the reasons why that is impossible; just a listening test of my own will do me. The clicks/pops of DSD might get worse or might get better; we'll see.

Yes, higher rate DSD is the main thing. Blue Coast are releasing more and more music at 4xDSD. Some of it I have owned for nearly a year and never been able to play. This is made more frustrating by the "fact" that even offline, it is impossible to convert those 4xDSD albums to a lower rate DSD, without converting to PCM and then back to DSD.

People who like to upsample to 4xDSD will be able to do so more easily. Apart from the DAC sample rate limitation, I'm not even sure if any existing Linux system can do 4xDoP.

Native DSD might also help when you want music playing simultaneously  in 2 rooms via different DACs. I use Snakeoil server-USB-Makua in front room and same snakeoil server to sMS-200 in back room via network. Haven't thought it through but having native DSD (and higher sample rate) enabled for all devices might make this easier with more of my DSD library.

I look forward to trying it out  :) .

(11-Mar-2018, 09:47 AM)JD1 Wrote: [ -> ]Yay, we are on the same page now. Need to enable for each DAC type but I was never gonna work out how that is done. Glad you are on the case 

It looks simple enough, but whether it'd work or not, you'd probably have to tell me when I have the test kernels ready for you later.
 

(11-Mar-2018, 09:47 AM)JD1 Wrote: [ -> ]There are still some people claiming native DSD sounds better and I'm not interested in the reasons why that is impossible; just a listening test of my own will do me. The clicks/pops of DSD might get worse or might get better; we'll see.

Native DSD is better technically I guess because it does not have the extra over head of the PCM. And that in bold. Don't think native DSD will have that problem any more.

 

(11-Mar-2018, 09:47 AM)JD1 Wrote: [ -> ]Yes, higher rate DSD is the main thing. Blue Coast are releasing more and more music at 4xDSD. Some of it I have owned for nearly a year and never been able to play. This is made more frustrating by the "fact" that even offline, it is impossible to convert those 4xDSD albums to a lower rate DSD, without converting to PCM and then back to DSD.

People who like to upsample to 4xDSD will be able to do so more easily. Apart from the DAC sample rate limitation, I'm not even sure if any existing Linux system can do 4xDoP.

Native DSD might also help when you want music playing simultaneously  in 2 rooms via different DACs. I use Snakeoil server-USB-Makua in front room and same snakeoil server to sMS-200 in back room via network. Haven't thought it through but having native DSD (and higher sample rate) enabled for all devices might make this easier with more of my DSD library.

I look forward to trying it out  .

Shouldn't be a problem at all. Just define two different outputs. It is the output that determines DSD support, not Snakeoil.

(11-Mar-2018, 08:55 AM)agent_kith Wrote: [ -> ]In theory should be able to get Snakeoil to support more DAC devices. The only thing I need to do really is put the kernel source code somewhere in the open so as not violate GPL (because I am modifying the code). Hopefully will have something at the end of the month . 

I'm guessing that that the code mods for enabling native DSD might already be available in the public domain (and available to you) ...for DACs that have already been enabled by others.

*Please assume disclaimer that "I don't have a clue about software" to all my posts. 

(11-Mar-2018, 03:09 PM)JD1 Wrote: [ -> ]I'm guessing that that the code mods for enabling native DSD might already be available in the public domain (and available to you) ...for DACs that have already been enabled by others.

*Please assume disclaimer that "I don't have a clue about software" to all my posts.   

They have to, else they are violating the GPL. e.g. the earlier link I gave is one example of the source code, there could be others, but I don't have the full list. Google can probably find them. For now I'd just try it on your DAC and see how it goes. Will think more about this if it actually works .

Happy easter everybody. It's been a tough year 2018 in more ways than one. The pace of development for BlindTesting is not going as fast as I would like :bored:.

Having said that, development is continuing, and despite the snail's pace, it's one step closer to a beta release.

Here's a preview of what's to come: assigning processes to CPUs.

Now there are several ways to do this, for Snakeoil OS - cpuset is probably the best method because the OS is designed as a dedicated music playback machine after all.

And here's the GUI on how to set this up. Here's an example of a correct setting (OK), and an incorrect version (Error).
 

First up Snakeoil will find out the number of virtual CPU (vCPU) your computer has (in the example, there are 2 vCPUs). If your computer only has a single core, this feature will be disabled.

The list of vCPUs is shown. Check the item to dedicate it for yourself (user), unchecked will be used by the OS. On first setup half the CPUs will be dedicated for system, while the other half for everything else. Things will be a lot more useful when you have more than 2 cores. For example if you have 4 vCPUs, 2 for system, and 2 cores for music playback (or 1 for system, 3 for music).

There are also the standard basic error checkings. e.g. you cannot assign all cores to user, or all cores to system (see Error). Obviously you cannot continue when there is an error. And you can enable/disable this any time.

What's the point of this you may ask? Well, the idea is to make sure the music code don't 'jump' across different CPUs. The reason is complicated to explain, suffice to say this has a good chance of either reducing latency, or increasing it. :huh:

The only way to find out - is to test it out. The theory is, this setting may well improve some motherboards. To the extent that, perhaps someday I may finally replace my NF9C with something else ;).

So been trying this combo the past 2 days:
 

I'm using LMS + Squeezelite v1.6.4. With music stored on a NAS. And I have partitioned my cores into two - CPU#0 runs Linux and everything, CPU#1 runs LMS and squeezelite. Also turned off the unused USB port. Kind of weird, but there is a slight difference .

With CPUSet subjectively:

1. Less warmth. The tube warmth that I'm used to disappeared. Sounds more like MPD, but not overly so
   
2. Instructions like cymbals and flute seems to be a lot more pronounced, and seems to extend just a bit longer
   
3. Not too sure about timbre, could be better, could be worse, could be no difference. Can't really tell .
   
4. Perhaps a slight improvement in clarity
   

With USB port #2 on vs off:

1. Don't think there is a difference. But then just because I couldn't hear anything different doesn't mean it doesn't work. For all I know I may well lack the skills to identify 'em. This is with my PaulPang card, perhaps SoTM or others will notice a difference.
   

The difference is slight. But at least there is one, whether it's better or worse is really up to you and your setup. The key thing is, you don't have to learn complicated linux commands to do this now - click a few things here and there, and away you go. It's that easy .

Still need to clean up a few stuffs before I release the next alpha. Unfortunately I'm delayed yet again. Reason below..

There is one thing that makes a bigger difference compared to the above two. And that's isolation. Past few weeks I suddenly noticed the microdetails in my system has disappeared. Unfortunately I had made a lot of changes past few weeks while working on Blind Testing and native DSD (Can't get native DSD to work with the DC-37 unfortunately). With so many changes I can't remember what has changed.

After a lot of fumbling around, finally manged to get my microdetails back! Turns out it's the isolation feet I am using . Honestly no idea why isolation would make a difference for a computer. But it seems to be so for me. Pretty sure I made the same mistake before.

In the meantime, if anybody of you have this and not using 'em, please send me a PM. I need another 12 pieces of this. They are cheap so don't think you guys will mind donating them to the Snakeoil project .
 

Now that I have got the microdetails back, can concentrate more on Snakeoil development. Hopefully will have a new alpha release soon. Then will write a tweak about isolation for your computer.

Updated the panel and hope that it'd be a lot more intuitive. So basically any CPU assigned to (User) will be dedicated for music software, leaving the other CPUs for everything else. Subjectively this does make a difference. So to whoever suggested the addition of process partitioning, thanks
 

There are other tweaks with cpuset (e.g. with memory), but if my memory serves the RAM blocks are locked and cannot be swapped out when the processes are running in RealTime. Because of this, the whole thing actually becomes pretty convenient.

Just a few more tickets to finish before the final alpha 3.. After which - it'd be beta and finally the official release.

This feature took longer than expected to fix, Snakeoil OS now remember options based on the player selected. i.e. you can set options for mpd-v20, an option for squeezelite-1.8, etc. Now you can swap between players without losing any previous player configurations.
 

Blind Testing is currently almost feature complete. Hopefully I'd be able to release a new alpha tomorrow, while I work on the last bits.