Thanks and Sorry to hear of your tweeters destructing
Elk said Please trim quotes to only that which is necessary to place your comment in context.LOL Elk I have to smile ... way back I made a similar suggestion, but perhaps not as elegantly worded as yours (English not being my 1st language) - so I was perhaps a little long winded in my post. As I recalled somebody then "got right back at me" by fully quoting me and adding only one or two words. 'Twas funny
But yes: I definitely agree. The flow of a conversation is often interrupted by uneccesarlily long quotes and subquotes.
In fact: Often, I think, the quote can be left out entirely instead of being trimmed.
plcomp saidElk said Please trim quotes to only that which is necessary to place your comment in context.LOL Elk I have to smile … way back I made a similar suggestion, but perhaps not as elegantly worded as yours (English not being my 1st language) - so I was perhaps a little long winded in my post. As I recalled somebody then “got right back at me” by fully quoting me and adding only one or two words. 'Twas funny
But yes: I definitely agree. The flow of a conversation is often interrupted by uneccesarlily long quotes and subquotes.
In fact: Often, I think, the quote can be left out entirely instead of being trimmed.
Cool!
Ted Smith saidThanks.The exercise last weekend was Aristotelian debugging, not Empirical debugging - i.e. I stared at the wall rather than doing gobs of measurements.I realized that I might have miss simulated the main upsampling filter and that I could probably both raise it's cutoff and make it smoother. Just to verify that I didn't make a mistake I was checking that there wasn't any aliasing and one explicit experiment I did was to play a 88kHz tone and check for a 200Hz tone - at the time I thought I should listen instead of just using a scope just because in general I trust my ears more than measurements, but that was a baaaaad choice this time: I blew my tweeters :)I can only judge jitter with my ears and without tweeters that’s a bit of a problem. Still I’ve learned things to do in the FPGA that lower jitter and apparently they worked again after I changed the filter.
The fixes I did were obvious (in hindsight) and I only needed to verify that I didn’t screw anything up when doing them. Too bad I screwed up the testing for no screw-ups.
So: no graphs…
Sorry to hear about your tweeters.
Have you found a way to implement a strategic approach in order to minimize the impacts caused by the Xilinx compiler Simulated Annealing phenomenon? I would assume that one remedy would involve a uniform and predictable path throughout the process (however the ‘SA principle’ and ‘predicted’ I guess deviate in nature…).
If it can be assured that only modified code may result in enhanced SQ and not re-compilations ‘by chance’ I guess we have come a long way. If the beta team vote for one specific build, I would always ask myself ‘what could be further gained (almost for free) or loosed throughout a new compiling process?’
The SAA may benefit most computer tasks, but could it be minimized for audio code without drawbacks?
Could something be gained by studying the FPGA compiler manner of operation in greater detail (not that I claim that this is the case here)?
What do other companies do (e.g. Playback Designs). I would guess they are experiencing the same issue?
Frode saidHave you found a way to implement a strategic approach in order to minimize the impacts caused by the Xilinx compiler Simulated Annealing phenomenon? I would assume that one remedy would involve a uniform and predictable path throughout the process (however the ‘SA principle’ and ‘predicted’ I guess deviate in nature…).
Could something be gained by studying the FPGA compiler manner of operation in greater detail (not that I claim that this is the case here)?
What do other companies do (e.g. Playback Designs). I would guess they are experiencing the same issue?
I used to work at Cadnetix (an EE CAD/CAM) company and spent some time in the router group (and in fact with some of the engineers who are now at Xilinx) so I have a pretty good idea what’s going on in their code.
As I mentioned elsewhere I’ve locked down the most critical resources to somewhat constrain the squirrelyness of some of the routing, there are plenty of controls for this sort of thing in the Xilinx tools but it’s always a balance between time used in the tools and time using our ears.
We work around the remaining issues by listening to 20 or so compiles for each release candidate. The variance in the SQ between them has been decreasing on average with each release as I empirically learn more about this whole mess.
I haven’t asked Andreas what he does, but in general it depends on what the various companies are using the FPGA for. If you use it in your clock path you’ll have a lot of problems, if you only use it for math and then use a separate DAC downstream you won’t have nearly as many problems… Online some swear they’ll never use an FPGA again because they are impossible to control and others that they are no big deal if you know what you are doing. Who knows how much of those claims are posturing. For a higher hardware cost I could make the DS less sensitive, but a little pain on each release costs a lot less overall than beating it to death with hardware.
I should receive my DS this week and now there may be a firmware update. How will I be able to get the improved firmware?
ozzymilton said I should receive my DS this week and now there may be a firmware update. How will I be able to get the improved firmware?Ozzy, the way this normally* works is:
-
There is a small test team (call it the Alpha team) that checks it out. Gordon is on this team.
-
If good it goes to the Beta team. There are a few more people on the Beta team.
-
The Beta team tests it. This allows for a check across a larger set of systems. If all goes well then it gets released for public consumption.
*(sometimes when it hits the Beta team it’s also been made available to the world with a “use at your own risk” flag.)
So,when the firmware is available, do I obtain it by downloading the update from PS website to a SD card and then load that into the Direct Stream?
Basically yes.
Simple and complete instructions will accompany the update file, as well as an explanation of why the update is being offered.
From my lips to God
’s ears.
ozzymilton said So,when the firmware is available, do I obtain it by downloading the update from PS website to a SD card and then load that into the Direct Stream?Yes.
adriaan said @gordon: when do think think the new firmware will be posted on the PS Audio Downloads and will the new firmware be shipped with the upgrade kits?Woah Nelly.
I am not saying that there is any new firmware YET. What we already have is pretty hard to beat.
There is stuff in “alpha” testing at the moment that shows promise but if still quite far from real-time status.
The next release will probably be for some user tweaks like the channel level control and higher rate DSD.
I am a long way from Colorado and Paul just feeds me little morsels to torture me but, if all goes as planned , then perhaps an SQ tweak [if that is even possible] will be included.
Enjoy what you have and maybe the tooth fairy will surprise you one morning.
Any DS owner will just download and install any updates by simply loading the unzipped contents to an sd card, inserting it upside down[contacts facing up] and rebooting the DS by the switch on the back. AMP[s] turned OFF please while doing this.
OHM
...Paul just feeds me little morsels to torture me but, if all goes as planned , then perhaps an SQ tweak [if that is even possible] will be included.For as good as things are now, G, I think you know my feelings about this.