Howdy
Happy New Year all.
Feel free to skip reading this if you get bored.
The short version: let’s brainstorm about possible FPGA related DS improvements and new features.
The (very) long version:
As Dennis mentioned on another thread there’s a new release of the DS firmware coming and tho the exact feature released are always subject to change, the FPGA changes are minimal, tho important to the people they affect:
In the design of the DS I made a decision to keep the clock jitter as low as possible but still deal with inputs with clock rates that were up to 100 parts per million off of nominal. I chose 100ppm because that’s the Redbook spec and I expected that any quality transport/player/audio card would have a clock that’s at least that accurate. Well the Oppo BDP-103, 105 and related universal players have clocks that often start up a little out side that range but after warming up (maybe three or four hours depending on the ambient room temperature) they drift to within 100ppm of nominal. There are also other players out there that seem to use the Oppo transport/support boards so this may well affect some others. The DS’s symptom of the input clock being too far away from the nominal sample rate is a small ffft every minute (or longer.) The ffft is actually a small mute of about 6 ms (FIFO overflow or underflow) and actually some listeners never seem to hear it and others are driven nuts by it.
The next release of software will accept clocks off by at least 10,000 ppm (way wider than the sloppiest clocks) without any ffts. The further away from 100ppm (actually 100ppm up to about 140ppm depending on manufacturing tolerances) the input clock is, the theoretically worse the input jitter rejection but I doubt that people will hear anything since the DS is fairly input jitter insensitive. Users that have clocks that are within 100ppm won’t be affected at all.
The other FPGA change is direct support for 22.05k and 32k sample rates. There are internet radio stations out there that use sample rates slower than 44.1k. Some users are disappointed that they need to set their players/renderers (or whatever) to do sample rate conversation of sample rates below 44.1k. I don’t blame them because some players are fairly non-intuitive to set up to only upsample some sample rates while leaving others alone. 22.05k and 32k aren’t the only rates out there for internet radio stations, but they should cover the vast majority of feeds out there.
Now to the subject of this post:
In a few weeks I’ll start having some time to work on the DirectStream software for a while and wouldn’t mind some input from you all.
Obviously the first thing on my mind is trying to get even better sound quality. 1.2.1 may have set unrealistic expectations for the next SQ increment 
The 1.2.1 difference was mostly due to two things: a tuning parameter whose value was left over from a prototype board and lower jitter in the FPGA. The lower jitter was achieved by freeing resources that were needlessly being used because I was conservative when I set other parameters. Using my new scope allowed me to measure the results of some parameter changes and to pick better trade offs that didn’t result in sound quality compromises. We’ve made enough progress over the last year both in sound quality and critical listening that we can hear changes now that didn’t seem to be there in the past.
I say “tuning parameter”, but a lot of these type of changes are simply choosing how many “extra” bits are used in the math. Tho I aim for at least a 144dB S/N ratio everywhere in the FPGA code, in some places, for example, the noise from too few bits seems to be very non-white and gets magnified down stream. Without the new oscilloscope I at times was quite conservative with my number of extra bits selection. With it I could chop bits back off until things were audible and then add some back. This freed up a lot of “wasted” FPGA resources. This allowed cleaner FPGA layouts and routing which achieved a bigger sound quality improvement than any of us expected.
Anyway there are some other alternative pieces of FPGA code I’ve written over the years. Tho I always listened critically to each algo choice, over time we’ve improved sound quality enough (and our listening experience enough) that we may find some hidden jewels in the heap of rejects.
Still, now would be a good time to entertain ideas for other new features, etc. I don’t know how much time PS Audio will have to work on features that require significant user interface changes, but you never know until you look what’s unexpectedly simple and what’s unexpectedly complicated.
Anyway I invite you all to brainstorm with me on this thread about improvements and/or (small) new features.
I warn you all that I’m usually quite prickly when people suggest things that I missed or prematurely rejected but I’ll try to be on my best behavior. In reality tho I may not appear to be listening, most of the good changes in the DS over the last year are the (sometimes very remotely related) results of being prodded or poked with feature requests that I initially rejected out of hand.
-Ted
Happy new year all.