Computer Audio Asylum

Music servers and other computer based digital audio technologies.

Return to Computer Audio Asylum


Message Sort: Post Order or Asylum Reverse Threaded

Tony's Player

192.19.218.100

Posted on July 13, 2012 at 00:15:47
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
Below Tony was talking about an interesting concept in a player, I would like to explore this a little bit.

Basic concept: simple device that uses ethernet or some other remote mechanism to fill large amount of memory with data, remote interface gets disconnected and anything having to do with it gets physically powered down, simple system takes data from memory and clocks it into some form of DAC with as simple a path as possible using ultra low jitter clocks and ultra low noise power delivery. If possible the player would not have any form of DSP or digital filtering at all, this would be performed by the computer before sending the data to the player. Of course that means the amount of data can be very large. But memory is cheap and and ethernets are fast.

If I understand correctly the reason for doing this is to completely remove the computer from having anything to do with real time affects on sound quality.

I agree, I think this would be the best candidate I have heard of for doing this.

One interesting aspect of this post was that Tony proposed using DSD, while this can mean a very simple DAC part, I am surprised that Tony brought this up given some of his previous posts expressing some rather negative thoughts on DSD. Tony, have your thoughts on DSD changed? I personally am not a big fan of DSD, but I have never played with the 128 version so maybe that makes a big difference.

On detailed impelementation, I have actually already designed about 80% of this for another project. I am working on a high end squeezebox design with an FPGA, large memory, ethernet "chip" that talks to the FPGA, ultra low jitter clocks and a PCM1704 based DAC circuit (I REALLY like 1704s). The ethernet part is the same XMOS chip used for UAC2 implementations, but XMOS also has a nice network stack for it. I have most of this already done. Digital filters would be implemented in the FPGA.

Tony's concept could use most of this as is, I would have to add relays to the power for the XMOS chip and a relay on the cable connection. I would have to increase the memory significantly, but that is not too hard, DDR memory chips are designed to be used in large arrays. I already have the DDR interface in the FPGA so this is mainly a board layout challenge. I already have the digital side and DAC side completely isolated from each other with the low jitter clocks on the DAC side feeding the digital side to clock out the data. It will be two boards with LVDS interface between them with a each board in it's own shielded section of the box. Of course each secction gets it's own separate power supply. (actually 5 separate power supplies)

The concept of having the computer perform the reconstruction filter and sending the resulting data to the memory is an interesting one. I did some experimentation on that last night. I already have a DAC that has an FPGA driving the 1704 (with reclocking via the local clock of course) in which I can implement my own digital filter or send the data through direct. I tried applying a software filter on the file and sending it to the DAC at 192, this worked very well, vastly better sounding than hardware filters such as the DF1704. I was not able to tell for sure if the software filter sounded better than the filter in the FPGA, but I know for sure they were different filters, I was just trying a couple upsampling routines in some wave editors I had. So the concept sounds viable.

Of course the user interface on this box is going to be very primitive. I'm thinking of a play, pause, restart and connect buttons. You use the computer to choose a playlist, do any filtering etc, then download it into memory, then the box disconnects from the network and runs stand alone playing the playlist. You can start and stop but that is about it. If you want to change the playlist you have to do that on the computer, reconnect the box to the network and download the data. With a giga-bit ethernet connection the download won't take TOO long, but you do have to live with it.

Anybody interested in actually doing this? I don't have the cash to actually build this right now, but I can do all the design and prototype building if I can get some others to invest in it.

I'll let someone else figure out how the computer software side of this is going to work. Whether it's a new program or a plugin to something else we can discuss.

Any thoughts?

John S.

 

Hide full thread outline!
    ...
Are you suggesting a product that would be brought to market or just something for the hobbyist?, posted on July 13, 2012 at 07:28:56
bwb
.



As a commercial product you might contact Rob at Pure Music. Of course I have no idea what he might be interested in doing but he certainly has the expertise in programming to do the computer side of it. He also sells a line of phono preamps so has expertise in hardware too.


.

 

RE: Tony's Player, posted on July 13, 2012 at 08:10:40
Tony Lauck
Audiophile

Posts: 13629
Location: Vermont
Joined: November 12, 2007
Comments re DSD

My reservations with DSD concerned the noise floor, specifically the rising high frequency noise and the general level of noise. Even more important than the general level of noise is the effect of noise modulation. With multi-bit signalling dithering can be performed to remove noise modulation. (Rectangular dither corrects the mean, triangular dither corrects the next higher moment. Or subtractive dither might be used to eliminate all possible signal related modulation.) With one bit signalling dither can not eliminate noise modulation, as the total energy in the signal is constant and louder than the music. Rather, all that can be done is to filter out as much of the noise as possible.

Obviously, if the noise is 190 dB down and modulates with the music plus or minus 6 dB the modulation will be irrelevant. But the problem is that the noise is not down that much. Indeed, the noise in the "audio band" below 20 KHz is not much better than -120 dB (as claimed by Sony and Philips). If you look at sample sigma delta modulators, you will see that these produce peak signals that are not even 16 bit accurate. I did this by running one of these and just measured a DC signal, one can clearly see how the noise level (peak or RMS) vary with the DC input, looking only at the output after filtering with a 64K sinc filter with 22.05 kHz transition. So I still don't care for DS modulators. However, when run at 5.6 MHz all of these effects are substantially reduced.

More important, I have run listening tests with my Mytek Stereo192-DSD DAC and compared upsampling in the computer with sending straight PCM to the DAC (which uses the SABRE chip). The sound, in increasing order of quality is as follows

1. 44/16 file, sent at 44/16 to DAC
2. 44/16 file, converted to 176/24 and sent to DAC
3. 44/16 file, converted to DSD128 and sent to DAC.

Or with high res,
1. 192/24 file, sent at 192/24 to DAC
2. 192/24 file, converted to DSD128 and sent to DAC.

These are not claimed to be scientific tests as I have not done level matching other than manual volume control adjustments which come in 1 dB steps. The gain through the DAC in DSD mode is not the same as with PCM, as it depends on the level of modulation in the SDM. I use HQPlayer to do all the sample rate conversions as well as the sigma delta modulation.

It is also possible to upsample DSD64 files to DSD128 before sending it to the DAC, but I didn't find any obvious benefit from doing so. I may do this later, should the software get the capability to do room convolution at DSD64 rate, which would add low order information that might benefit from the higher speed.


Comments re Memory player and Shift Register DAC

The main reason for suggesting a 1 bit DAC was actually with a shift register implementation, not a memory player. The hope was to build a 1 bit DAC that provided complete isolation through a well engineered shift register, operating as a single clock domain. There would be no LSI chips, just MSI or discretes. The interface would consist of three pairs, a clock pair going from the DAC to the transport, and a left and right pair sending one bit pulse streams. The interconnect cable would be required to have a specific length, and the timing arranged at the transport to ensure that the phase of the clock signal at the DAC matched the data stream. As a result, the entire DAC would consist of a single clock domain. Not many flip flops or gates are required in this design, so the designer would have no excuse if the resulting device didn't isolate from the input and/or didn't produce good sound. Note, in this design every single transistor in every single gate and every single wire, etc. must be modeled as analog components. Getting the shift register to attenuate all legal variations on the input stream (within the receiver's eye pattern spec) to where they are at least 160 dB below peak output in the output will be a bit of a challenge. One does not want any extra components to make this more difficult than possible. Presumably a simple computer interface could be built to interface the three twisted pairs.

IMO if this can be done it would be a much more practical device than the memory player we've been discussing, because of latency and other user interface issues. It will be a much harder sell to skeptical audiophiles than the memory player, of course. I would actually want to have both of these around, since the memory player will make it easy to test how well the player and amplifiers are affected by running but disconnected computer systems and this may be a good tool for testing power supply isolation, cable isolation, etc. It might be a good idea to put the memory player function in a separate box at the end of the twisted pair to allow both methods of operation.



Tony Lauck

"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar

 

PS Audio ?, posted on July 13, 2012 at 08:53:08
AbeCollins
Audiophile

Posts: 46294
Location: USA
Joined: June 22, 2001
Contributor
  Since:
February 2, 2002
Doesn't PS Audio have a similar device? A couple years ago I saw a demo where they used their transport to 'load' their DAC, then disconnected the transport. The DAC continued to play music from RAM. I believe they also have a way to do this over Ethernet but I have not looked into the details.


 

RE: Tony's Player, posted on July 13, 2012 at 10:36:13
audioengr
Manufacturer

Posts: 6017
Location: Oregon
Joined: April 12, 2001
If the data is packetized already when using ethernet and buffered by definition, what is the advantage of disconnecting from the Ethernet? Is is galvanic isolation?

Seems like isolation is all that needs to be added, not the disconnection and further buffering. Disconnection creates problems for playback features, such as skip forwards and backwards.

Steve N.

 

RE: Tony's Player, posted on July 13, 2012 at 13:42:54
Tony Lauck
Audiophile

Posts: 13629
Location: Vermont
Joined: November 12, 2007

I agree with you. But isolation isn't so easy to achieve and even if it is, it may be a hard sell to convince audiophiles that the isolation is real. Disconnecting, powering down and moving the suspect equipment out of the room should satisfy all but the most extreme audiophiles.

One can add additional features such as start/stop/pause/skip forward/skip back, but pretty soon things get complicated and one ends up with some kind of computer to support this interface, and this computer will need to be isolated from the sensitive analog equipment, ... This would be a serious violation of KISS. (Look closely at the image, it shows where this ends up.)


Tony Lauck

"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar

 

RE: Tony's Player, posted on July 13, 2012 at 15:37:22
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
Hi Steve,
if I may paraphrase the discussion:

people are going crazy tweaking real time aspects of computers (OS's, player software, amount of memory, processor type, IRQ priorities etc etc etc. Every form of connection to the computer has had people say that changes to these things done on the computer affect the sound.

This is an attempt to "head it off at the pass" by not having ANY form of connection to the computer at run time. This has been tried with various forms of "memory players" but all of these still have some form of computer controlling things in the player.

This concept is trying to get the absolute minimum amount of stuff running at play time, hopefully producing the absolute minimum amount of cantamination from electrical noise in the box. That is the concept.

One possible implementation is as I stated, an FPGA with very minimal circuitry, just enough to talk to some memory chips at slow speed and send the data to reclocking flops and then to the DAC chip(s). All the circutry necessary to fill the memory and communicate with the outside world is powered down and disconnected at play time.

Yep there are some limitations with UI with this scheme. You can put the data in simple packets so you can add things like a track identifier in the data stream. When the data is being loaded the FPGA can store the track trac klocations thus the player can implement skip forward and back within the loaded data, stop and start playing etc.

BUT I have become very enamored of having a now playing screen, but that would take WAY more processing in the player, not good. You also can't send track status out over the network if the network is shutdown. How about IR? Put an IR transmitter on the front which just gets fired up when tracks change which sends out a few bits that specify the track number. The receiver for this can send this over the network or whatever to the computer which knows what "track 3" is. It can display the real information in many different ways without needing the player to do anything.

One interesting aspect of this was the concept of applying the reconstruction filter with software on computer so no DSP stuff is required in the player. But of course this means more data coming out of the memory. It will be interesting to see whether the amount of noise generated by the extra memory access is worse than running a reconstruction filter in the FPGA.

I think this is an interesting project and not all that difficult to design and build.

If this is successful then we can forget about what cable carries the digital data to the player, is it a Belkin or an SR? Whether the computer has 4GB or 8GB of memory, exactly what processes are running on the computer and focus on things like the curve of the reconstruction filter, lower noise power supplies in the player etc.

John S.

 

one possible implementation, posted on July 13, 2012 at 17:24:53
bwb
.



I think a simple optical transceiver between computer and DAC might work. When the DAC buffer is empty or you hit the reset button the DAC wakes up the transceiver on it's end and notifies the computer it is ready for a refill. The computer sends the song files to the DAC and when it is done the DAC shuts off the transceiver until the buffer is empty or you hit the reset button.

Your now playing feature could be on the computer, whatever it sent to the DAC could be displayed on the computer.

I agree you give up bells and whistles like fast forward, rewind, etc. It is a minimalist player like putting on a record and playing it until you decide to get up and walk across the room and stop it. The DAC is in complete control and only gets data via an optical line when it wants it.

.

 

RE: Tony's Player, posted on July 13, 2012 at 18:37:48
RioTubes
Audiophile

Posts: 1039
Location: So Cal
Joined: February 3, 2005
99% of the posts on this forum are about...

PC --- USB or SPDIF connection --- DAC

so I hope the design goals of this post get some traction. Not exactly building upon your specific design in your post, but rather generalizing ...I think John Brown has approached a similar objective from a different angle with his SD card player here:

http://www.ecdesigns.nl/info-sd-player

The memory capacity on these SD cards will just continue to grow. The processing power required is a fraction of the Touch's processor which itself, is a fraction of what occurs inside the average PC...not to mention the ability to escape the vagaries of the avg PC environment built to accomodate multiple tasks, apps etc.

I still use your SB approach that sends the master clock back to SB2 via i2s and resynchs it just prior to the dac chip. My experience is that this has been hard to beat sonically ;)

I had a NAD C390DD (full digital amp) in the house for a month and one of the source options was simply a usb connection via external 2.5" hard drive. No PC connection. That was also a liberating experience.

 

RE: Tony's Player, posted on July 14, 2012 at 02:52:38
soundchekk
Audiophile

Posts: 2426
Joined: July 11, 2007
John.

I'd approach the thing differently.

What we need is a DAC with the best possible signal recovery/restauration on it's input. It should be an external standalone device.

The Transport side should become kind of irrelevant. It shouldn't matter If I use my PC,SBT,iPad,Android as long as the signal is bit perfect.
Working on the transport side is much too complex.

What IMO matters is a device which can talk to all those commonly used devices and comes up with the same SQ from all of them.


When is comes to usability ( two button control !?!?!): I've been presenting my stuff feeding an Anagram DAC on a DIY-fair. We compared it to ec-designs SD-player.
The majority in the room (all audiophile nuts - including me) prefered
the iPeng control of the simplistic SD player control. The differences in SQ were subtle. The differences in operating the devices were unacceptable to all of them.

I think spending more work on SB kind of projects is waste of time.

Buy a Rasberry PI at 35$ that runs squeezeplayer at up to 192khz and hook up a USB DAC to it.


BTW:

Have you checked out "IANcanada"'s reclocker project @ DIY-audio- digital section?? Perhaps a nice building block to make a better DAC.




Good luck.


-----------------------------------------------------------------

blog latest >> The Audio Streaming Series - tuning kit pCP

 

Rasberry PI at 35$ , posted on July 14, 2012 at 03:33:31
fmak
Audiophile

Posts: 13158
Location: Kent
Joined: June 1, 2002
It is not possible to get one and the current web price is over Ģ50!. Buy from the distributors and they have a waiting list.

If you want to box it and get good power supplies, pay another Ģ20-30!

 

RE: Rasberry PI at 35$ , posted on July 14, 2012 at 04:07:51
soundchekk
Audiophile

Posts: 2426
Joined: July 11, 2007

Yep. I know. They do prepare currently for mass production.

You don't need a box. You can easily put it in your DAC box. It's credit card format.

There's another quite new very interesting 4-core, 1,4GHz, 1GB RAM device at 129$.

Hardkernel Odroid-X. The Samsung SIII is based on the same stuff. Ubuntu 12.0.4 runs on it. And you can use it even for DSP work and/or video.
You can also plan for RAM playback.

Cheers

-----------------------------------------------------------------

blog latest >> The Audio Streaming Series - tuning kit pCP

 

RE: Tony's Player, posted on July 14, 2012 at 05:26:55
>>>>>Buy a Rasberry PI at 35$ that runs squeezeplayer at up to 192khz and hook up a USB DAC to it.

How about just hard-wiring the PI directly to a DIY digital amp like those you posted about/are using.

Have everything in one case which is internally shielded between critical components. Have totally separate PS for the PI and amp. Use a r-core feeding a good linear "Dexa" type regulator for the PI.


 

I'd Like to see this Topic Continue to the Point of a Parts List, posted on July 14, 2012 at 05:33:25
Grand perfection may not be realistic or practical but building a better mouse-trap is possible.

There are plenty of quality low'ish cost parts available.


 

Disconnecting remote interface, posted on July 14, 2012 at 07:13:24
>>>>Basic concept: simple device that uses ethernet or some other remote mechanism to fill large amount of memory with data, remote interface gets disconnected and anything having to do with it gets physically powered down...

Could this be accomplished by having a script that turns off the ethernet on the board after data is loaded or upon hitting play, then turns the ethernet back on when the data is finished playing?

 

RE: Disconnecting remote interface, posted on July 14, 2012 at 08:13:48
SBGK
Audiophile

Posts: 444
Joined: March 22, 2012
>>>>Basic concept: simple device that uses ethernet or some other remote mechanism to fill large amount of memory with data, remote interface gets disconnected and anything having to do with it gets physically powered down...

I can do this with the Logitech Touch, the buffers are large enough to store several minutes of 16/44.1, doesn't seem to make a difference to the sound when the laptop is disconnected from the ethernet while the music is playing, so think the concept may be based on a faulty assumption.
http://mqnplayer.blogspot.co.uk/

 

Recurses! Foiled Again!!! (nt), posted on July 14, 2012 at 08:16:32
Skip Pack
Audiophile

Posts: 144
Location: Hollister, CA
Joined: November 20, 2005

 

RE: Disconnecting remote interface, posted on July 14, 2012 at 08:37:45
Mercman
Audiophile

Posts: 6581
Location: So. CA
Joined: October 20, 2002
I also found no difference disconnecting my Thunderbolt drive after loading the file into memory.

 

perhaps my memory is faulty but, posted on July 14, 2012 at 09:10:06
bwb
.

I thought you reported a while back that your system sounded better with the thunderbolt drive?

.

 

RE: perhaps my memory is faulty but, posted on July 14, 2012 at 09:19:08
Mercman
Audiophile

Posts: 6581
Location: So. CA
Joined: October 20, 2002
My entire experiment is suspect. Tony wanted me to load a file into memory and disconnect the drive. I really don't know what I proved if anything.

And yes, for normal use ( the way I like to play music), the Thunderbolt drive does sound the best on my rig.

 

RE: perhaps my memory is faulty but, posted on July 14, 2012 at 09:23:57
You mean sounds best as compared to another type of drive...subjective impressions are valid.

So it appears that the T'Bolt sounds just as good as having no drive.

I don't think you proved anything either, just an exercise in futility.


 

Question about DSP and Filtering, posted on July 14, 2012 at 09:42:38
>>>>If possible the player would not have any form of DSP or digital filtering at all, this would be performed by the computer before sending the data to the player.

If I get a recording like a RBCD or even a Hi-Rez recording can it be improved by DSP or filtering?

Altering data has its own problems in terms of the quality of the DSP algorithms and filtering used. Is there a perfect algorithm or filter that can actually make an imperfect recording more perfect? Or do they just tailor the sound to suit someone's taste or maybe create a synergy that addresses the shortcomings of down stream components?


.

 

RE: Disconnecting remote interface, posted on July 14, 2012 at 15:04:01
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
The difference here is that all the circuitry that has to do with talking to the ethernet gets completely powered down, when you disconnect the cable from the Touch the circuitry that talks to that cable is still powered up, clocks are still going through it, circuitry and code is still continuously looking at that cable to check for it getting reconnected etc. With this approach all that stuff gets completely powered off. It's as if it was not soldered onto the board and the network code doesn't exist in the processor.

The disconnecting the cable is just "icing on the cake" to make absolutely sure that nothing on the computer can get to the player through that route.

John S.

 

Oh Well this thread is dead before it even started....Half baked Ideas go nowhere..nt, posted on July 15, 2012 at 15:44:13
.

 

RE: Disconnecting remote interface, posted on July 15, 2012 at 16:15:06
AbeCollins
Audiophile

Posts: 46294
Location: USA
Joined: June 22, 2001
Contributor
  Since:
February 2, 2002

As a start, if you're on a linux or unix based platform, you can enable or disable Ethernet ports with:

ifconfig eth0 up
ifconfig eth0 down

ifup eth0
ifdown eth0

I used 'eth0' as the example interface in this case.

/etc/init.d/network start
/etc/init.d/network stop

and various other options depending on your flavor of unix / linux

 

RE: Disconnecting remote interface, posted on July 15, 2012 at 16:32:42
Yes I know.

I don't see why the need to get up and physically disconnect a Ethernet when you can just write a script to turn it off when a song starts and turn it back on when it finishes.

Otherwise by the time you listen to a few CD's worth of material you are going to be pretty tired.

At any rate, this thread is dead. All the big ideas were nothing more than a flash in the pan. Nothing actually seen until fruition.

 

RE: Tony's Player, posted on July 15, 2012 at 16:55:44
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
Hi Klaus,
of course a perfect DAC completely immune to any influences from the outside world would be the way to go, but the problem is that nobody knows how to make it. Right now we are in a situation where all the known influences have been dealt with (at least by a few people) and we still have problems. So now it's a job of hypothesizing a possible vector, devising experiments to test it, come up with ways to alleviate it, and see what happens. So far the definitive vector and solution has not been found. It could take a long time to come up with a good solution.

So until that search is fruitful there are other options such as this that are possibilities. It's obviously not a perfect solution but it is something that is possible to build today.

It doesn't have to be as bleak as you mention. You can still use fancy gui based systems with iPad remotes and all that for selecting music to play, and via an optical connection as I proposed for seeing what is playing. The only major difference is you give up immediate response. After you have selected what you want to play it take 40 seconds or so to download the samples to the box before it starts playing. As far as remote control of the playing itself is concerned, I'm sure we can come up with some way to get an optical connection to the box for controlling the basic transport functions. (start, stop, skip back, skip forward, go to beginning) All these can be done instantly as they work within already downloaded samples. It should be possible to write a plugin for LMS that could use the squeeze system to run this.

John S.

 

RE: Disconnecting remote interface, posted on July 15, 2012 at 19:04:32
AbeCollins
Audiophile

Posts: 46294
Location: USA
Joined: June 22, 2001
Contributor
  Since:
February 2, 2002
"Otherwise by the time you listen to a few CD's worth of material you are going to be pretty tired."

Just imagine how I feel after a few LP's, twice as tired because each one needs to be flipped. ;-)


 

John, I think it's called an iPod :), posted on July 16, 2012 at 07:09:00
Gordon Rankin
Manufacturer

Posts: 2928
Joined: June 9, 2000
John,

Only kidding, but it would be easier and less work just to put a damn dac on an iPad than it would be to develop an entire product.

If you wanted DSD and PCM then XMOS would be the best bet. You may want to use the dual core to do this with one core used for USB the other for memory. Or use something silly like SPI memory which would take up less space and then you could probably do the whole thing with a single core.

It would be tons easier to do this USB than Ethernet as the XMOS does require 2 cores for Ethernet audio.

Since there is already an SPI port for booting the XMOS you could easily use that port for memory storage as well.

Micron has some 128M SPI ram parts, create a select line for a bunch and be done with it. They are only SOIC-16 so they are pretty small. Maybe like 32 of them with a plug in board for 32 more.

I could have this done this afternoon anyone interested :)))

--- But really if you optically isolate the computer from the dac section and have significant and intelligent buffering then it really would not be required for all this.

I think even having the XMOS on the same plane as the DAC chip is a bad thing. Heck it has a ton of PLL's to reclock the part and all the IO so this is not the cleanest part on the block. But which one would be... well none of them.

Really to do this with the XMOS you would be best to have a dual power supply and run the XMOS off one then optically isolate to the digital audio section powered by a separate transformer.

You maybe could pull this off easier with an FPGA and a bunch of memory. You could put a SD card interface on the unit. Plug in the card, the FPGA would transfer the SD info to RAM then set a LED to green and start playing.

Oh great now I got more stuff in my head!

Thanks
Gordon
J. Gordon Rankin

 

John, I think it's called PlayGo, posted on July 16, 2012 at 12:55:01
Roseval
Audiophile

Posts: 1846
Joined: March 31, 2008
Having DLNA might solve a lot of interface problems:
The Well Tempered Computer

 

RE: John, I think it's called an iPod :), posted on July 16, 2012 at 14:54:19
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
Hi Gordon,
yes the idea was that the connection to the outside world (XMOS or whatever) would be completely powered down during play so there is no way it can affect the SQ. That way you don't actally need separate power supplies or planes, just a relay to disconnect the power to the outside world connection. Those PLLs and IOs can't cause any plane noise if they have no power!

SPI RAM is an interesting thought, it would be great for the playback part, but we need to fill it up fast when downloading the playlist. DDR is overkill, but cheap!

I'm trying to avoid the SD card storage part, with an ethernet (or USB) connection the users can still use the fancy remote GUIs they have become used to, there is just the latency issue to deal with.

John S.

 

RE: John, I think it's called an iPod :), posted on July 17, 2012 at 09:47:13
Gordon Rankin
Manufacturer

Posts: 2928
Joined: June 9, 2000
John,

But what are remotes good for if that part of the interface is powered down?

Really SD is kind of a nice idea, just throw it in there. Then put it in the server and you can copy it all to ram and go.

Thanks
Gordon
J. Gordon Rankin

 

The Gods are talking, posted on July 19, 2012 at 04:00:49
jrling
Audiophile

Posts: 82
Location: London
Joined: September 16, 2011
I count myself fortunate as an Inmate, to be able to read the Gods in this game ( JS & GR) debating Tony's excellent visions of the future with productive ideas moving us forward in the quest for ultimate SQ.

I fully support the concepts behind 'Tony's Player'.

Jonathan

 

RE: The Gods are talking, posted on July 19, 2012 at 04:33:38
SBGK
Audiophile

Posts: 444
Joined: March 22, 2012
Comparing this to an otherwordly discussion is apt.

I have tried to test if there is any effect by disconnecting the cable and switching off my laptop after the music is loaded and I can't hear any difference.

I do hear difference when changing settings on my laptop and/or Logitech Touch as do others.

So, until someone can say they hear a difference, this discussion is like the debate about the number of angels on the head of a pin.
http://mqnplayer.blogspot.co.uk/

 

you just proved that the discussion is valid, posted on July 19, 2012 at 06:51:45
bwb
.

The situation you describe is a bit different because this is about computer to DAC and you are talking about computer to music server.

However, if you hear changes when changing Touch settings you are changing computer settings since the Touch contains a dedicated computer. Eliminating those changes is exactly the thing being discussed here.

The discussion is about changing from a system where you stream data from the computer to the DAC while playing to system where you load the entire song file and then play it.


If you

1. change settings on your laptop
2. load the data on your Touch
3. then disconnect the laptop and hear a difference

Then the data to the Touch has obviously changed

The same thing would happen in the system being discussed here.

The discussion isn't about whether or not changing the data changes the sound, it is about whether or not feeding the data in real time and having the computer constantly interact with the DAC changes the sound.

.

.

 

RE: Disconnecting remote interface, posted on July 20, 2012 at 14:44:46
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
I think you are focusing on just one part of the whole concept, you mention that disconnecting the cable doesn't make a difference, but changing thread priorities does make a big difference, but that is what this concept is all about. You don't have to change OS parameters because there is NO OS. You don't have to tweak thread priorities because there are no threads. You don't have to kill programs because there are no programs. When this thing is running there is NO PROCESSOR running at all!! The only thing going on is an FPGA using a couple hundred transistors implementing a very simple interface to memory chips getting the data from those chips and sending it to the DAC chips. Thats IT. ABout as simple as it is possible to get.

By doing it this way it can cut out everything else, disconnect from the outside world so there is no possibility of anything out side interfering with this.

This is MANY orders of magnitude less stuff happening than what is going on in the Touch. If decreasing what is happening in the Touch by 5% makes a significant difference, think about what would happen if you can decrease it by 500,000%, this is what I am talking about.

John S.

 

RE: Question about DSP and Filtering, posted on July 20, 2012 at 15:54:49
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
I have been thinking hard about how to reply to this, it's a complex subject.

I think I'm going to go with the abreviated version and try and keep it short. That means there is going to be a lot left out unfortunately, but hopefully it will cast some light on how I'm thinking about this.

It all goes back to a bunch of experiments I did many years ago with regards to digital filters in DAC chips and NOS DACs etc. I won't bore you with the details, but the conclusion was that done right NOS significantly improves the sound IN SOME WAYS, and makes it worse in others. The sound is richer, more alive, conveys more of the emotional impact from the performers, BUT it sounds "dirty" around the edges, particularly in the high frequencies. Some people think it's a good compromise, others do not. The dirtiness is obviously the results of the high frequency aliasing caused by the unfiltered output. But why does getting rid of aliasing get rid of the "richness, emotional impact etc"?

After a lot of experimentation I came to the conclusion it was the digital filters themselves. Every single one of the hardware filters I looked at in DAC chips (and external ones as well, such as the DF1704) were compromised in some way. My supposition is that in order to cut costs in the chips the designers cut corners in the implemention. They are required to meet certain numbers in the spec sheet, and they can't do it properly and still stay on budget, so they cheat and play tricks in order to get good numbers.

In this forum there have been a lot of statements along the lines of "Shannon says that the filter will accurately reproduce the original waveform", but many are saying it doesn't sound that way, and others keep on saying the theorum is correct, I think this is reason for the dichotomy, the actual hardware implementations in most cases are NOT properly implementing the filter.

I have tested this hypothesis in two ways: creating my own digital filter in an FPGA and using software to do the filtering on the file. In both cases I have used two different DACs that I have built myself. One uses 1704 DAC chips (which do not have a filter) and the other uses a 1794 which does have a digital filter, but it can be turned off. Both use very low jitter local clocks, very low noise power supplies etc. For the 1704 I can feed the data directly (NOS), from a FPGA digital filter, or through a DF1704. For the 1794 DAC I can use either its internal filter, or bypass the internal filter and send direct, or use the FPGA filter.

The results of all this was that with both DACs using either the internal filter or the DF1704 produced very clean sound but it was lacking richness, aliveness etc. Stright NOS in both cases gave the richness, aliveness, but dirty sound. Using either the FPGA filter or filtering in software gave the best of both worlds, it still had the richness and aliveness, but was clean. This sound difference is NOT subtle it is almost starteling. Everyone who has heard this invariabley says something along the lines of "now THIS is what it is supposed to sound like".

I tried several programs to do the filtering in software, and they all did similar things. I wan't using any special audiophile programs, just the normal resampling algorithms in programs such as SOX etc. Yes you can hear slight differences between them, but they all sounded way better than straight NOS or filtering in the DAC chip.

Now all that was the explanation for my comments about filtering and Tony's player. To get the best sound I don't want to use filtering in the DAC chip, that leaves implementing my own filter in an FPGA or resampling in software external to the player. Doing it in the FPGA takes a lot of hardware resources and fast clocks which flies in the face of the concept "absolutely as little going on as possible", so the best bet would be resampling in software and sending the higher sample rate files to the player. The higher sample rate files take more memory accesses, it will be interesting to see if that is any better than the extra stuff going on in the FPGA for a hardware filter. My guess is that the esternal software filtering will sound slightly better.

Whew, that was long winded, but that was about as concise as I could get and still cover the material.

John S.

 

RE: Question about DSP and Filtering, posted on July 20, 2012 at 19:20:24
RioTubes
Audiophile

Posts: 1039
Location: So Cal
Joined: February 3, 2005
John, I hope you are able to pursue the approach outlined in your thread. Where in the playback chain (pc --> dac) does the sox resampling take place?
Can the average user experience this now?

 

RE: Question about DSP and Filtering, posted on July 20, 2012 at 19:52:44
Bibo01
Audiophile

Posts: 648
Joined: December 18, 2008
Software players like XXHighEnd and HQPlayer have filters for very high res upsampling and are geared for exactly your requirements. So much so that XXHighEnd has an optimized 8 x PCM1704U-K based NOS DAC with no digital/analog filters to go with it.

 

RE: Question about DSP and Filtering, posted on July 21, 2012 at 01:04:56
Ebit
Audiophile

Posts: 47
Location: Down Under
Joined: October 26, 2008
John
XXHE software can upsample 16X - feeding 705.6 or 768 kHz to Peter's Phasure NOS1 DAC which does the digital to analogue converstion without filtering or any further over/up/down sampling.
Frank

 

DRAM or SRAM?, posted on July 21, 2012 at 07:39:54
Tony Lauck
Audiophile

Posts: 13629
Location: Vermont
Joined: November 12, 2007
If using DRAM memory, there is going to have to be a memory controller or equivalent to refresh the RAM. Isn't this periodic activity going to have an effect on critical circuitry such as the DAC clock? Do you think SRAM would be better?

(The goal is to produce good sound, not just to make the sound one gets independent of the computer, which can be accomplished at little hassle if one doesn't care at all about sound quality.)


Tony Lauck

"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar

 

Theory vs. Practice, posted on July 21, 2012 at 08:19:04
Tony Lauck
Audiophile

Posts: 13629
Location: Vermont
Joined: November 12, 2007
"In this forum there have been a lot of statements along the lines of "Shannon says that the filter will accurately reproduce the original waveform", but many are saying it doesn't sound that way, and others keep on saying the theorum is correct, I think this is reason for the dichotomy, the actual hardware implementations in most cases are NOT properly implementing the filter."

Shannon's theorem is just theory, i.e. it works "perfectly" in a perfect world. In an imperfect world, it works imperfectly. The basic assumption used in the theory is that the input signal to be reconstructed is band limited and contains nothing at or above FS/2. Not only is this assumption inapplicable for all audio files, it is impossible, and that for two separate reasons:

(1) Except for the all zero signal there can be no finite bandwidth signal of finite duration. This rules out all finite duration musical files. (Ironically, in his classic paper, Shannon made a mistake, presumably a typo in his Theorem 1, when he failed to rule out energy at the Nyquist frequency.)

(2) The theorem is based on real numbers. Computers are finite state machines and can not do accurate processing on real numbers.

This means that the result of filtering will not be the original signal, but merely some kind of approximation to it. We are left hoping that the approximation sounds the same, but this outcome can not be guaranteed by relying on theory.


Tony Lauck

"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar

 

HQPlayer, posted on July 21, 2012 at 08:26:37
Tony Lauck
Audiophile

Posts: 13629
Location: Vermont
Joined: November 12, 2007
HQPlayer sounds very good upsampling PCM to DSD128 playing through my Mytek Stereo192-DSD DAC.


Tony Lauck

"Diversity is the law of nature; no two entities in this universe are uniform." - P.R. Sarkar

 

RE: DRAM or SRAM?, posted on July 22, 2012 at 16:18:49
John Swenson
Audiophile

Posts: 2422
Location: No. California
Joined: October 13, 2002
Yes it has to be DRAM in order to get enough bytes to hold your 4 GB of music. If you access the DRAM correctly the read accesses will be sufficient for refresh, so there should be no need for separate refresh cycles.

My first thought was to use SODIMMs, BUT they are designed to use 64 bit busses all the time, that's a lot of data changing at once and takes a LOT of pins on the FPGA. I think it will be better to go with raw DRAM chips and go with 8 bits at a time, that way fewer wires switch at once, you have to do more memory access cycles, but there is a lot less going on for each one so the "memory access energy" gets spread out, less "bursty". The interface to a single DRAM chip is actually quite simple, very easy to implement in an FPGA.

John S.

 

Interesting - how about MEASUREMENTS?, posted on July 22, 2012 at 17:30:02
Archimago
Audiophile

Posts: 821
Joined: January 18, 2002
Fascinating idea John and I hope someone offers to help with the building of such a device... Would make a great "Extreme Ultimate Music Transport / DAC" article!

However, the operation of such a device as you've alluded to will be very "user-unfriendly" in terms of convenience. For that price, just how much audible difference do you hope this device will deliver compared to an excellent DAC like say a Weiss?

Although I don't think I could ever live with the inconvenience of a "primitive" interface, objectively, what do you think such a device will accomplish? How much jitter reduction do you expect and how would you measure this? Do you think the extreme isolation will lower the noise floor audibly? Will the frequency response change whatsoever; any more "flat" compared to a good orthodox DAC design?

I think it would be awesome to have such a device built and experience the state-of-the-art sound; but I think it'd be just as interesting academically to get some measurements out of the beast and see the results of some blind testing to see if anyone notices :-)

-------
Archimago's Musings: A 'more objective' audiophile blog.

 

Is this dead?, posted on September 2, 2012 at 13:01:38
GStew
Audiophile

Posts: 633
Location: NE Mississippi
Joined: September 21, 2001
Looks like interest in this thread has died down.

Personally, I am very interested the proposed player and hope it will see the light of day. As someone who has personally heard the benefit of minimizing a memory-type player's activity both physically & in the software realm, I love this direction.

Any plan to actually develop this further? Have you further narrowed down the design & configuration? Are you planning any sort of "subscription" participation similar to a DIYAudio Group Buy?

This inquiring mind wants to know!

TIA!

Greg Stewart

Everything matters!

 

Nyquist Shannon, posted on September 2, 2012 at 22:36:52
play-mate
Audiophile

Posts: 948
Joined: November 21, 2008
Hi Tony,

Yeah, that theorem sucks; at least when it comes to redbook format.
I donīt think people realize how bad CD quality actually is in re-constucting the original analog waveform.


At about 10kHz itīs about this precise :

The only viable way out, is to upsample the stuff with a sinc-filter like the "Secret Rabbit Code" in cPlay does.
In cPlay itīs infinite function is actually "overcome" by an "overlapp-add" function in the L2 Cache....

kind regards
Hysolid // Mytek Brooklyn // Spectron Musician III // Analysis Audio Omega

 

RE: Is this dead?, posted on September 27, 2012 at 12:08:43
jrling
Audiophile

Posts: 82
Location: London
Joined: September 16, 2011
Greg - you said everything I agree with.

Tony/John - has there been any progress on thinking or construction? It would be great to have an update

Many thanks

Jonathan

 

Don't Hold Your Breath...., posted on September 27, 2012 at 14:03:41
The DIY spirit is not alive here.

Plenty of talk and expert opinion though.

 

Tony's Player - Any Progress?, posted on November 23, 2012 at 10:59:56
jrling
Audiophile

Posts: 82
Location: London
Joined: September 16, 2011
This is an interesting and innovative project. It would be great if it could be brought to fruition.

Anything anyone here can do to help it along?

Thanks

Jonathan

 

Page processed in 0.053 seconds.