 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
68.179.148.150
In Reply to: RE: the computer: parallel vs series posted by Joe Murphy Jr on February 12, 2012 at 08:52:20
.
I don't think a CD player has ever been built that didn't have a microprocessor of some sort in it. It may be dedicated to a single task like controlling the playback of a CD but if you have a machine that takes digital data and somehow manipulates it then you have a computer.
What you describe is a computer controlling another computer (what you described as an "on-board controller."
.
Follow Ups:
Series vs Parallel
Maybe a football reference might help. There are players and there are coaches. Players are series: coaches are parallel. Coaches can design plays and tell players what to do, but they aren't "in the game". Only the players are "in the game". Today, computers, which should be coaches/parallel, are players/series.
I don't want Windows, OSX or Linux touching the actual audio. I do not want software touching the audio when it's sent to a DAC (ie, no influence on sound quality which is not what we have today in computer audio).
Here's a simple analogy. I get up and put a CD in the transport. I sit down and press PLAY on the remote. The transport feeds the signal to a DAC. In other words, I do not have any influence on the music whatsoever.
I want the computer to replace what I have to do and have that same "no influence whatsoever" characteristic.
.If you want to get data from wherever it resides (physical disc or hard drive or memory or?) to the DAC then a computer has to handle the data. It might be a simple microprocessor in the transport with some simple dedicated code to handle the task or it could be a personal computer, but there is a computer doing the work.
"The transport feeds the signal to a DAC. "Not really, a computer controls the reading of the data and the computer then feeds the data to the DAC. I understand your desire to be blind to this process, to assume that whoever designed the hardware and wrote the software did it optimally and therefore lead you to be believe it is as good as it can possibly be, but that is a huge assumption. Why do you feel having some influence is a bad thing? I see it as a plus.
BTW your use of series/parallel is rather unconventional :> )
.
Edits: 02/14/12
Conventional, while usually an assurance of stability, is much like even keel sailing and is a bit like being in a rut. It's the same ol' same ol'. Unconventional, while not always successful, eventually leads to progress. Sometimes it's only baby steps. Sometimes it's ground breaking.
What's in a CD player or transport, when compared to a conventional computer, is application specific. A conventional computer, while containing some application specific circuitry, is very much not.
There are pros and cons to both approaches. You believe your approach, the conventional computer, is the better approach. I'm fine with that, but for you and others -- not for me. I believe there is a better, less intrusive way, to utilize the computer. Someone just needs to act on that unconventional idea.
.That is not progress, it is simply using 2 computers to do the job of one. Your "on board controller" is merely a computer dedicated to a single task being controlled by an external PC. It will also have to dedicate some of it's resources to interacting with the PC which might affect it's operation.
It's not really unconventional. Being application specific is nothing new. That's the way it was always done before CD transports started being replaced by PCs. Now you want to regress back to that.
Besides, it is already being done with asynchronous DACs. They pull the data from the PC and store it in a buffer until they need it. How does your idea differ?
Instead of pulling data from a PC it could pull data from a hard drive that is being controlled by the on board controller (i.e. dedicated computer) inside the drive? Then we can debate which external drives sound the best.
Where is your on board controller going to get it's data so it doesn't have to interface with an external device that can influence it?
..
Edits: 02/14/12
CD/DVD transport
substitute a "massive" storage medium for the spinning disc
connect to a DAC via a single cable (multi-line internally)
clock is sent from the DAC to the transport
It's just an idea. No Windows. No OSX. No Linux. No conventional computer. If I knew the answer to your obvious "How..." question, then we wouldn't be having this conversation. Gotta start somewhere. Seems to me an idea is a better place than "You can't...".
A few thoughts on this. Is the storage medium in the same box as the DAC? If its in a different box how does the data get between the boxes? There are computer peripheral interfaces such as USB or firewire, or network protocols such as ethernet, but those are fairly complex protocols and usually require a computer of some sort. They don't HAVE to use a computer, its possible to configure an FPGA to implement these protocols, but its still a lot going on to deal with the protocol. Of course a new protocol could be developed thats much simpler that could easily be implemented in a small FPGA.
Then there is the issue of how do you get the data off the disk. The general purpose file systems used on disks today are fairly complex, there is a lot going on in there, which usually means a computer to read and write the data to the disk. Again it's theoretically possible to do this with an FPGA, but it would be be a very complex task.
Now of course a disk doesn't HAVE to use a complex file system, at the low level its just a bunch of sectors. We could develop our own "music filesystem" which is extremely simple which could be easily read by an FPGA, but then how do you get the data on the disk? And how does the "control app" know what is on there? You would have to have your music files, kept in normal file types on normal file systems in normal computers, which would read the tags and catalog the music, and then somehow write just the sample data onto our disk that gets plugged into the "player". Since the "control program" does the writing to the disk it can tell the player to read sector 12345 to 23456 and it knows that is the song you want to play.
Since no computer on the planet will know how to write data to our "barebones" filesystem, we will need to write a driver for it, the easiest way to make this work would be a simple linux driver, so in order to write the drive we would need a linux box with say an eSATA port and ethernet. This linux box does the writing to the music disk under control from the "control program" on whatever system it runs on. You then unplug the drive and plug it into the player (or remote storage box if you don't want the disk next to the "stereo")
Then there is how the remote controler talks to the player, if you use a general purpose protocol such as ethernet or wifi you are back to needing a computer in the player again. So we are back to writing our own protocol for this interface. It doesn't have to be complex, its just saying "play sector 1234 to 2345" this could esily be implmented on a wire, or IR, radio would get a little more complicated, but the bandwidth is extremely low. We could implement this as a little device that plugs into a USB port and looks like a USB serial port, which has built in drivers on all major OSes.
So there you have it, a system where no computer touches the audio data in the playback chain, there has to SOME circuitry somewhere to get the data off the drive and properly timed and sent to the DAC chips, but it doesn't have to be very complex. All control is handled by a control program on some other computer with a very simple control interface between the control computer and the player.
There are a couple drawbacks to this, number one seems to me to be that there needs to be two copies of the music, one the control program sees for generating it's tag data base and the simplified one in the player. For people that have a static collection this wouldn't be TOO bad, but it would get a little cumbersome for people who get new music frequently.
After going through all this, why is this really necessary, why is there a requirement that there be no computer in the playback path? Take for example a squeezebox receiver, it has a small processor which just knows enough to talk networking and a small FPGA to take the data and feed it to a DAC chip. It has no mainline "OS" just dedicated code written for that box. Yes there is a server involved which DOES run on a regular computer, but it does not send the audio data through the computer OS audio stack in any way, the server uses the OS drivers to read data from the disk, then it encodes that data in a very simple protocol that it sends over the network to the player, which sends it to he DAC chip. All the "control" in this system is handled by external hardware (squeezebox controller, apps on iPhones or android phones, web pages, programs on computers etc) This sounds a lot like what you are describing, how does it not meet your requirements?
John S.
Appreciate the time you took in making this reply. However, it was not my intention to have someone go through so many steps to show that it could be done (the way you descibed it or using another approach). I know it is possible. Perhaps I should have stated that I wasn't looking for a possible "How to..." reply. My apologies.
.
Me too, one last try. What you are describing below is a music server that is missing the brains it needs to operate. A DAC can't read data from a storage medium, you have to put a computer between the two so they can talk.
"substitute a "massive" storage medium for the spinning disc
connect to a DAC via a single cable (multi-line internally)"
Q.. How does the data get from storage medium to DAC?
A.. A computer has to read the data from the massive storage medium and transfer it to the DAC.
The computer can be dedicated to the task and contained in the same box but that is just what any other music server being built today does. It has to run some version of software even if you program in machine language. I don't see why you think getting away from the well known ones would be better.
It isn't a matter of starting somewhere, music servers abound.
Good luck with it.
.
.
"Q..How does the data get from storage medium to DAC?"
Answer: How does the data get from a CD to an external DAC?
Remember, this is an idea. I have only put forth the idea in the most simple terms. Plenty of info was not given in order to keep this uncomplicated. You have needlessly added quite a bit of naysaying and irrelevant info to this concept based on far too little detail.
The "critical part" missing is the someone who will build it. And I guess overcharge for it. Thanks for the well wishes, but I will not be that person.
I only know where to start.
.
"You have needlessly added quite a bit of naysaying and irrelevant info to this concept based on far too little detail. "
That is funny....
You push out a half baked "concept based on far too little detail" and then get defensive and scold me for shooting holes in it.
What was the purpose of your post?
If you didn't want to discuss it why did you bring it up?
.
Discussion of the concept doesn't necessarily mean discussion of the minute details. If I had wanted to know "if" or "how" this could be done, there would have been a question mark in my original post.
Have a good day.
.
I didn't understand the rules of the forum.
Next time I'll keep an eye for that question mark.
Thanks for straightening me out. I'll try not to let it happen again.
.
Post a Followup:
| FAQ |
Post a Message! |
Forgot Password? |
|
||||||||||||||
|
||||||||||||||
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2025, Audio Asylum, all rights reserved ]
