Snowmass V1sounds better than Snowmass V2

I think there is some confusion here. Snowmass beta is v1. What Paul said was, that the beta version and V2 sound the same. Although many here would disagree.

No confusion here. The beta was released the weekend before V1 to a select few who emailed Paul. The following Monday, PS Audio released V1. The beta Paul emailed and V1 released the following Monday are the same exact files. Paul confirmed this. The beta and V1 are one in the same. Then when V2 was released a few weeks later Paul made the claim V2 sounded the same as V1/Beta.

2 Likes

Had SMv1 for a couple of weeks very very impressed.

Installed SMv2 the day of launch, immediately updated Bridge II and was happy and satisfied. However something in the overall presentation brought me in doubt which led to a reinstall and several reboots of the DS last week (just to be sure).

Reading the experiences in this topic i decided to pull the trigger and flawlessly reversed back straight from SMv2 (3.0.4) to SMv1 (3.0.0).

Unfortunately my Melco is in Londen for repair :disappointed: (probably defect audio grade SSD, luckily under warranty…) Although this is a complicating factor for comparison to me i concur with others who stated their positive experiences with SMv1, and my ‘doubt’ vanished :grinning:.

BTW this doesn’t prove anything, it’s just my experience at this moment to my ears and in my system…

This thread is inspiring me to carefully listen to Snowmass V1 v. V2. I just reloaded V1.

I enjoy that we have a group which really digs into everything.

2 Likes

What was fixed in V2? I run V1 and never had a single issue in 500+ hours of play.

## Fixed Issues

  • Users couldn’t update bridge firmware on 3.0.0
  • Bridge update now displays upgrade percentage until completion
  • The Bridge II would set the volume to 50 on initialization
  • Volume level will restore to 25 on reboot
  • Locked/Unlocked button didn’t hold settings on reboot
  • Locked/Unlock button now controls Attenuator setting from remote IR and setup menu
  • Bridge II Album Artwork reloading on every song.

## Updated Features

  • Added Button on Setup Menu that Toggles Volume controls between “Fixed” and “Variable”
  • When button is set to “Variable” Max Volume is displayed to the Left.
  • The “+” and “-“ buttons will affect the Max Volume of the DSD as it has always done
  • When Button is set to “Fixed” Max Volume is switched to Fixed Volume.
  • This is the ONLY place where users can change the volume (Up or Down) while in “Fixed” mode
  • The DSD will save the volume at the time of toggling the button to “Fixed”
  • If the unit is in Fixed Mode upon power cycling it will rest to the same volume.
  • If the unit is in Variable Mode upon power cycling it will rest to volume level 25

I looked at the download files for beta Snowmass…and compared those to V1 Snowmass…and the files are showing some differences. Don’t know if that makes any difference between the two.

Thank you. I see quite a lot of changes in the way volume is controlled. I still wonder if this is throwing people off or if it is indeed implemented correctly. If Ted says Snowmass FPGA is unchanged then real or inadvertent differences in volume setting might explain audible differences.

Digital Volume control can be a tricky thing - for example dithering is very important to eliminate introduction of quantization noise when bit levels are changed.

I don’t believe in ghosts or gremlins…but I suppose it might be “groupthink” which does happen. The power of suggestion and all that.

Anyway, to my ears and vs my reference DAC the V1 is absolutely outstanding and I see no reason to mess with V2 given the concerns brought up by far more knowledgeable experts than me.

Yes…you don’t want to mess with those pesky gremlins you don’t believe in…it’s true though.Just ask any DMP owner.:stuck_out_tongue_winking_eye:

Time for a poll?

How many prefer v1 but don’t have Bridge II?
How many don’t hear a difference and do have Bridge II?

I don’t have my Bridge II installed and have tried both V1 and V2 and am back to V1 just to test. I am hearing no difference between the V1 and V2.

No difference…Bridge II. I don’t listen like y’all though.

It’s very probably not groupthink. Any audible differences that might exist are small differences (see below) and these have been heard in the past with various releases.

There are no weirdnesses in the volume control in that what you see is what you get. There are certainly changes in the volume setting caused by the bridge/ROON, etc. which the user might not expect. That’s clearly a separate issue.

The FPGA digital volume is simply a multiply with no loss of precision (The volume is a 20 bit number, the PCM is 30 bits wide at that point in the signal flow and the SDM uses all 50 bits of the output of the volume multiply .) Put another way any changes in the input volume level or the input signal cause the expected technically correct changes in the output. There’s no need for dither (or perhaps I should say that the SDM is plenty of dither.) There’s no resolution lost with the digital volume. As you know that’s a separate phenomenon from the potential changes caused by the distance to the analog noise floor.

Any audible difference between Snowmass versions is caused by RFI and/or electrical noise caused by the control/display processor and/or the bridge. That difference may be in the DAC or in the user’s system via, say, the power cords or interconnects, from the user’s system reacting to ultrasonic noise, etc. (Except for the display radiation, the interference is most likely inside the DS.)

When the display is off the actual changes between the versions of Snowmass are small. Any changes in spuria or noise shape above -135dBFS are not visible in a long term FFT.

There are no measurable phase or amplitude changes in the frequency response between the various versions.

Any perceived differences are likely caused by such things as noise masking in the ear.

2 Likes

We have had a number of occasions in the past when a couple of users have heard something untoward which the majority initially missed. I have learned to trust the group ears.

I think the beta was set to force load every time the DSD restarted. V1 removed that. My guess is this is the difference.

Ted,

I recall prior discussions mentioning that repeated compiles of the FGPA code sound different, and there is a winnowing process to zero in on the best one for release.

I have NO background in digital or electrical engineering, but am naively wondering if it is possible that successive loads of the same firmware onto the FGPA in the DSD are subject to similar random processes that might alter the sound - or is the location of the code in the chip architecture pre-determined?

In other words, have you or any of the folks at PSA done successive loads of the same firmware on the same device and verified that repeated loads of the same firmware sound identical?

I have NO intent to drive myself nuts with this experiment, but I am going to re-load 3.0.0 tonight simply out of curiosity. Sorry for potentially creating a new dimension of AOC (Audiophile Obsessive-Compulsive) disorder. :scream::scream:

On a serious note, the DSD with Snowmass has never sounded better - I don’t care which version. Hat’s off to you!

1 Like

Here’s much more information that you probably were asking for :slight_smile:

The FPGA compile process uses an oracle (pseudo random number generator) to help make decisions as it searches for placements and routings that will meet the timing criteria (and other things like placement restrictions, etc.) that I give it. The search space is huge and for many (more complicated) FPGA projects at other companies they need a sea of workstations/servers trying to do various routes for days or weeks just to find one that works.

The FPGA in the DS and the code I write for it are pretty simple in comparison so essentially all of the different routes it tries (no matter which random numbers are used) find a placement/routing that functions correctly. Since I get to specify a random number seed for each routing attempt I give it 1, 2, 3, … 20 as the seeds. Note that with a given seed the compiler will always generate the same placement and routing. Also, just in case it’s not obvious, all 20 of the compiles produce code that when given the same inputs generate the same outputs. They only differ in jitter and power supply noise generated.

The differences in compiles mostly show up as different patterns of current draw on various power pins. The FPGA compiler knows everything about how much jitter there is at any point and time that the FPGA is running and also how much current is being used over time for each “trace”, but the only thing it cares about is getting the correct answer - it doesn’t care what the jitter or current draw is if the answer is correct. If a potential routing has too much jitter, etc., it just ignores it and tries another one…

To a first approximation none of this is relevant to different OS loads of the FPGA. Each load of a given release puts exactly the same bits at the same places: the amount of jitter and power supply noise is the same with one load as another of the same code (given the same FPGA temperature and the same power supply voltage.)

In the past (hopefully in the past) there was a bug that sometimes would let the FPGA sound noticeably worse than normal. A reboot would fix that. I’m pretty sure that it was caused by the display processor getting wedged somehow (an infinite string of interrupts or something) But there’s always the chance that there was a bug in the FPGA where two sections of the FPGA get out of sync with each other and one grabs a value one clock too early or too late from when the other sets it. The code should now be insensitive to clock slippage like that (or self correcting if it does happen), but in the past there were some places where it seemed to me to be to be theoretically possible. I keep my eyes out for such potential problems. However this whole paragraph isn’t really what you were talking about.

7 Likes

My V1 is force load which I requested from PSA CS.

Fascinating stuff, Ted.

I greatly enjoy these explanations/descriptions.

Ted,
Your code is the only thing loaded into the FPGA?
The PIC goes elsewhere?

1 Like