I too have never had an issue with pops on the DMP. I don’t listen to DSD too often through the Bridge, but I have heard an occasional low level pop. I think the point is the pops are through USB and the Bridge only and it is related to how those transmission methods work with the DS/DS Jr. Not so much a fault of the DS/DS Jr, rather coping with the quirks of how data is transmitted.
I also hear clicking during loud transients in me all PSA system with my DS DAC set to 100 on the high attauator setting. Ted mentioned it’s a known bug. He had suggested setting the attauator to somewhere between 85 and 100 if you use a preamp in order to minimize.
When I tap the filter button on the DSC remote, the volume goes way down, even then if I turn volume up to 106. It’s still too quite. I am confused??
No, you are not confused.
The attenuator drops the output by 20dB. This is equivalent to reducing the volume by 40. Even at a volume setting of 106 the volume is still down by 34.
The attenuator is to be use when you would other wise need to turn the volume down to 60 and below. Invoking the attenuator improves the S/N in these circumstances.
I’m going to get in trouble on this one…
There’s a very specific problem in the released Redcloud code (only on the DS Sr.): if the absolute level of the signal (after the volume control) rises fast enough and stays high enough (within about 6dB of the maximum possible value) just the right amount of time an accumulator will overflow in the FPGA and who knows how bad that will sound. As soon as the level goes lower for a fraction of a ms things will be fine again. The problem doesn’t even happen the same (or sometime at all) if you play the same music again.
The reason it isn’t in the Jr was that I found it while listening to the Sr very close to release.
Some history:
Way back when (on the hardware that came before the DS), I’d wrestled with a problem I called the “blurbles” for months and months. Tho I found it in a couple of weeks I couldn’t get the technically correct fix to sound good. So I spent weeks and weeks finding a few kludges and workarounds that hid it (with the then current software.) Then I built the DS…
Over time as the releases got more transparent I (and a few customers) had a nagging feeling that something wasn’t quite right. We’d been living with the kludges for years, but no-one had found a specific and reproducible case that showed something specifically wrong. When Huron came along it highlit the old problem on some lower level signals for a few customers, especially on the Jr (it can’t do one of the above mentioned workarounds.) Then a customer that had heard it contacted PS Audio with a reproducible case that was measurable on the Audio Precision. I happened to be in Boulder a day or two later and they showed it to me. Seeing it on the screen made it immediately clear to me that it was the “blurbles” again. Back in my basement after I could reproduce it with my test equipment I knew that I had to figure out exactly what was wrong with the technical solution that I’d tried long ago. (Unlike a lot of bugs) I knew what went wrong with just a few hours of staring at old code. I’d put the fix (and many other attempts at similar fixes) in the wrong place in the signal flow. With the cleanest previous attempt in the current code (at the right place) the problem was completely gone. The new wasn’t all good - there was still a parameter that needed to be tuned, but I knew that would just take some time. That was right before RMAF. While at RMAF I told people I had a fix and promised a few customers that they’d really like the next release, I even told one fellow that heard something amiss at the show that I’d have a complete fix in a week or two, but that it would be a month or two before PS Audio could test it and go thru the release process. After RMAF at PS Audio we tested my preliminary code with the AP and their test case was completely fixed, in fact things looked better than they’d ever seen.
Since it was a fairly fundamental change I’d be making and also that there was a tunable parameter involved, I contacted a few customers that had, especially on Huron, complained about what I thought was this problem and asked them to be beta testers. Over a couple of iterations we honed in on the correct value for the parameter and eventually all of the beta testers noted that their problem was fixed (tho one did also have another seemingly related problem that PS Audio could (and did) fix in the control processor.) I delivered the code (FPGA 0.131) to PS Audio and waited for other fixes in the bridge and control processor that together would make a new release.
While waiting I (and a few of the beta customers) noticed one little gotcha: on some (fairly rare) recordings there was a small (and a time or two, not so small) problem. I fixed the Sr, ran it by the beta testers and sent a new copy (FPGA 0.133) off to PS Audio.
On the other side of the planet (actually just a thousand or so miles away): Paul had just a few days left to get the release out before he was off to a show (or something.) But somehow they listened to the 0.131 version of the software. I say listened and that sounds simple, but listening to a new version can take days and involves listening to 20 version of it and picking the one that’s the most realistic. Sometimes the differences take a little while to become apparent. (I’m glad someone else does it.)
When Redcloud was released I got a copy and listened - I knew something was wrong - sure enough when I looked at the software released it was FPGA 0.131 not FPGA 0.133 (the Jr was 0.132) I called PS Audio and left a message, I send email, I called again …
The thing is that Paul was very happy with the 0.131 code he’d listened to and the only thing he knew about the problem was that they had never heard it, and that, as far as they knew, it rarely happened and then only on a very few pieces of music. He either could start all over with 0.133 (which he was afraid would sound as good as 0.131) and delay Redcloud for a week or two or he could release what they knew sounded great. On the other hand and in the mean time the beta testers and I found more ways of 131 failing (we’d stopped listening to 0.131 while I was working on 0.132 and 0.133.) but people were loving the released Redcloud (0.131.)
In our own little worlds we had done what we thought was right, but now we’re here:
FPGA 0.133 has been ready for a while, but there are still some other problems in the control processor and the Bridge that haven’t been fixed yet. There’s no sense in spending multiple days listening to 0.133 and doing another release (wouldn’t the press like that) and then when there’s a better Bridge, do yet another release.
The thing is that you can’t listen to the pieces of a release separately so they have to be bundled, and there’s still the elephant in the room: what if none of the 20 compiles of 0.133 sound as good as 0.131… How about if none of 40, or 60…
For right now people just have to live with the (not very good) choice of turning the volume down a little on the DS (and up on their preamps, if they have one) or going back to Huron…
The good news is that in the FPGA the problem is well understood, fixed, tested and ready for listening…
The bad news is that there are a lot of problems unrelated to the FPGA itself that need to happen, many with unknown outcomes.
10 Likes
Got it now. Thanks ELK. I have never heard any of these issues. Any noises I heard in the past were from PC and USB which I left behind over a year ago. Lan Rover and Bridge II took care of that usb issue.
Of course there is another option. Send out fpga 1.33 out as a temporary fix, and let the users decide if they like it or not for the time being. Some people expressed real annoyance about the pops and cracks, and may be they are ok with the code not being tested properly.
Berlin
That’s another option.
Most of the beta testers (all?) reported that 133 fixed the problem and that they are using 131. It’s not a question of testing. 133 has one more flip-flop in the right place and can’t be worse than 131 in any technical way. But we never know about sound quality until we do a lot of listening.
I don’t know if you remember Torreys A, Torreys Final and the others, but multiple combinations of pieces of a release in the field are a nightmare in too many ways to enumerate.
Thank you for the updated Ted! The clicks are audible in my system but infrequent. Your advice on backing down the volume control works perfectly. Prior to that, I was slightly concerned about a connection or component problem. Now if bothersome on a song or a disc, I just turn it down a little and all is well. Funny story, it happened for me with my Norah Jones Come Way With Me SACD on the title track. After hearing Paul’s podcast with Bernie Grundman, it turns out Norah’s vocal highs in that song were at the limit of the master tape. It’s exactly were I hear the clicks. Things have come full circle!
Berlin, I can’t remember, were you a beta tester for this release?
My mother told me not to lie or to break my promises!
I appreciate that, I should have been more explicit: since I’ve laid it bare all beta testers for the Redcloud FPGAs are free to talk about it including the sound quality differences between 131 and 133.
1 Like
Thank you, Ted. This is a fascinating story in many respects. And I always appreciate learning new nomenclature, such as blurble.
As a non-coder it sounds a bit like one necessarily is dancing on the edge of a chaotic system when working with this low a level of programming.
The world is a fascinating place.
1 Like
The SDM is indeed a chaotic system. That’s why the exact levels, timing, etc. of the problem are so fuzzy. I thought I’d calculated the register widths appropriately (in spite of the chaos) but changes in a new test required the extra bit.
1 Like
Ok. 1.33 works excellent for me. Sound quality is superb. I let it run for 200 hours or so, and it let me smile every day. All dsd related problems are gone. I do hear an occasional low level click once in a while, but that can be file or other cause related. It does not bother me, so I do not keep track or check if it can be repeated.
Berlin.
Thanks. I thought there was at least one who liked 0.133 better but I couldn’t remember who. And of course there’s nothing wrong with changing one’s mind especially with a little time under the belt.
Ted, you said the following regarding the DS Senior:
Is the resultant “bad sound” a pop, a blurble, or something else? Since this problem is related to DS Sr only, then is there still another problem (not necessairly in the DS) that needs to be addressed? I was under the impression that there were some issues at the renderer end that were causing some of the pops. As I said above I haven’t experienced any serious problem, though I do get the occasional snap and rarer still, odd sounds which I attribute to the source rather than the DS.
Now that we are free to talk I can say that I had the issues with 131 which were fixed with 133, but I instantly went back to 131 because the fixed 133 especially had so much less defined bass, it was immediately worse, I didn’t even want to listen for other differences.
So don’t worry about trying it out, it’s really worse…just turn the DS output down a bit…I hope the next fixed release will be as good as 131 soundwise and that Redcloud 131 was no singular special stroke of luck 
There are multiple possible pop sources:
The DS Sr volume related problem: sometimes a pop, sometimes a ruffle, even short bursts of hash. Many report that it’s DSD only, but that’s just because DSD can get 4dB louder than PCM. Even tho DSD shouldn’t be louder than PCM for long, it’s long enough to cause this problem on some tracks/discs. To test for this you can turn the volume down a little and the problem should change or go away as the volume is lowered.
The Bridge problem (I don’t know the details, just that it’s been reported here.)
The pops that happen with changes in sample rate, or more likely, between PCM and DSD or between two DSD tracks: all of these depend on the source of the input to the DS, but on average they should be better than Huron.
Bad cables, etc. Especially if you have a DS Jr set to auto input select and have always had a bad cable (perhaps even on a different input), the fixes in Redcloud that try to mute pops will actually make discontinuities from cable problems, etc. worse. You can run a bit perfect test to check this.
Thanks Ted! Seemed there were multiple problems with independent solutions, but I got a little confused along the way! 