On transports

[Thad E Ginathom]

On a GHz machine, I expected this to be very accurate, but to my astonishment, I got the following:

0.019496
0.019506
0.019516
0.019525
0.019535

Not at all sure what this is supposed to prove, but looks like things have got about a thousand times better!

$  gcc -o tick tick.c
 $  ./tick
0.000081
0.000067
0.000068
0.000068
0.000068
0.000068
0.000068
0.000068
0.000068
0.000068

Maybe because I changed the program name

To be honest, I often find my system sounds better after a reboot, or with a different version of the OS. Real or imaginary? Ultimately, I just don't know!

 

[ranjeetrain]

Its not that simple!! An OS runs on H/W clock ticks (typically 100 times a second) to schedule processes into memory and there is never any guarantee that an existing process ( for example a kernel data copy module) will execute in cpu at a precise time.

This is where we need to set the context correctly.

You are talking about a general purpose (all-purpose/generic) computer, isn't it? Yes, I agree with what you said, BUT, that is valid only in case of a generic computer.

My point was -- built keeping audio duty in mind. A computer built for audio duty will not have a complex kernel. It will not need to do time sharing with multiple users. It will not be running 4 threads for checking email, 4 threads for the document you are drafting, 4 threads of notifying you about your contacts coming online and going offline. It will not have 10 threads constantly validating the data you are writing to the media to be malware free, and will not have a browser session running 20 threads and 100s of background processes.

Here comes the difference between a generic computer and a computer optimized for audio duty. A computer optimized for audio duty should:

1. Have a bare bones kernel
2. No security needed
3. Just ability to mount/unmount block devices
4. A file system module, to allow reading/writing of data
5. No background processes

So, if you see, whereas a generic computers has 50-100 processes and hundreds of threads, an audio only computer will (should) have 2-3 processes and 5-8 threads. Besides, "the OS" should prioritize the thread writing the data to the output stream, to have highest priority.

It is highly unlikely that a computer built to perform audio duty, will not be able to perform several writes a second. And as soon as you think of asynchronous writes, that requirement of "precise time" ceases to exist.

So, you have two choices.

1. Have an ultra precise computer which outputs data at the clock rate as asked by the DAC. This ultra precise computer is your stock Transports available on the shelf.
2. Have a less than ideal computer supply that data in a slightly less precise manner on an asynchronous bus, and let your DAC (outside the computer) handle the rest.

 

[ranjeetrain]

seem you have been reading posts in other forums but memory buffer is one hilarious addon you have suggested(heard from somone)?
bro, system ram itself can be reserved for buffering,most OS provides this feature.No one has to manufacture a buffer.
come on lack of knowledge has plagued some people with vague ideas, and they are spreading in all over the net

Everyone else understood my point, you didn't.

Apparently you can't read. I can't help you if you don't know how to read. May be you should go back to school and ask your teachers to help you?

 

[jls001]

So what exactly are you disputing?

--G

No dispute. If one is to believe the Terra Firma concept, the culprit in digital circuitries is the jitter in the clocks.

 

[jls001]

Everyone else understood my point, you didn't.

Apparently you can't read. I can't help you if you don't know how to read. May be you should go back to school and ask your teachers to help you?

Let's keep this civil.

 

[ranjeetrain]

Let's keep this civil.

I am trying. He is jumping into a lot of places to muddy the water. I am keeping away from his posts but he keeps meddling it.

 

[Thad E Ginathom]

Yes... let's knock the stuffing out the ideas, not each other.

My point was -- built keeping audio duty in mind. A computer built for audio duty will not have a complex kernel. It will not need to do time sharing with multiple users. It will not be running 4 threads for checking email, 4 threads for the document you are drafting, 4 threads of notifying you about your contacts coming online and going offline. It will not have 10 threads constantly validating the data you are writing to the media to be malware free, and will not have a browser session running 20 threads and 100s of background processes.

In an ideal world, yes. Mind you, most people here would share my experience that the computer does not audibly stop playing sound to do something else. Usually. I built this computer because the last one actually did!

 $  ps -ef | wc -l
184

... Actually, I thought there would be a lot more! Most of those processes will be consuming no resources for most of the time.

Whether Linux is better than Windows at multitasking is a moot point, and one that we might moot some time. It is true that it is built on a model that was a multi-tasking, multi-user system long before Windows was born, and even longer before it would, even with more than Window open, actual let us do more than one thing at a time.

Thus, I'd suggest that Linux is the better system, but someone would immediately remind me that it is running on the same hardware-interupt-based physical architecture, and then go on to remind me that Linux audio people, whilst not, perhaps, going to the same levels of process elimination as one might with WinXP, do have complex tweaks to balance interrupts, and do go to the trouble of using "real-time" kernels. Things seem to have easier recently. It's not that long since I wrote a whole thread about my struggles to make my particular system work.

 

[jls001]

For those who want to start off into PC music, some tips:

1) cabinet: get a nice one, preferably something that can be mounted into the audio rack.
2) get a good sound card, the best that your budget allows
3) buy hard disk as per need. You can add later
4) SMPS and CPU fans: get the most silent one
5) Software applications not needed for music play out not to be installed. This includes AV.
6) bypass the OS's audio mixer. Use something like WASAPI or at least ASIO (or their equivalents in other OSs.
7) get more memory
8) rip your CDs using a good ripping software. Win Media Player is avoidable. Don't believe folks who tell you bits are bits. Some are more equal than others. Crap in, crap out applies strictly.
9) ripped files can be stored as uncompressed files or as flacs.
10) avoid lossy compressed file formats. No, this point is not open to debates. I have heard both sides of the argument. Stick to the real thing, not the facsimile.
11) get a good digital interconnect. Well shielded one. The laws of electromagnetic interference don't stop working just because the signal is digital.
12) give it the best outboard DAC you can buy.
13) unless your DAC is a current model that can do asynchronous USB as well as it does SPDIF or AES-EBU, stick to the latter two. Remember that these two are audio specific interfaces, while USB is not and lab coats are twisting themselves into knots to make it work for audio. It is at best a work in progress. Unless you can afford a dCS or some OEM who has licensed their USB technology.
YMMV, of course.

 

[gobble]

Not at all sure what this is supposed to prove, but looks like things have got about a thousand times better!

$  gcc -o tick tick.c
 $  ./tick
0.000081
0.000067
0.000068
0.000068
0.000068
0.000068
0.000068
0.000068
0.000068
0.000068

Maybe because I changed the program name

To be honest, I often find my system sounds better after a reboot, or with a different version of the OS. Real or imaginary? Ultimately, I just don't know!

Great stuff Thad! A practical experiment. Will try that on my PC tonite.

This is where we need to set the context correctly.

You are talking about a general purpose (all-purpose/generic) computer, isn't it? Yes, I agree with what you said, BUT, that is valid only in case of a generic computer.

My point was -- built keeping audio duty in mind. A computer built for audio duty will not have a complex kernel. It will not need to do time sharing with multiple users. It will not be running 4 threads for checking email, 4 threads for the document you are drafting, 4 threads of notifying you about your contacts coming online and going offline. It will not have 10 threads constantly validating the data you are writing to the media to be malware free, and will not have a browser session running 20 threads and 100s of background processes.

Here comes the difference between a generic computer and a computer optimized for audio duty. A computer optimized for audio duty should:

1. Have a bare bones kernel
2. No security needed
3. Just ability to mount/unmount block devices
4. A file system module, to allow reading/writing of data
5. No background processes

So, if you see, whereas a generic computers has 50-100 processes and hundreds of threads, an audio only computer will (should) have 2-3 processes and 5-8 threads. Besides, "the OS" should prioritize the thread writing the data to the output stream, to have highest priority.

It is highly unlikely that a computer built to perform audio duty, will not be able to perform several writes a second. And as soon as you think of asynchronous writes, that requirement of "precise time" ceases to exist.

So, you have two choices.

1. Have an ultra precise computer which outputs data at the clock rate as asked by the DAC. This ultra precise computer is your stock Transports available on the shelf.
2. Have a less than ideal computer supply that data in a slightly less precise manner on an asynchronous bus, and let your DAC (outside the computer) handle the rest.

Yeah agreed, I plan to build a custom linux machine that does nothing but run a player and read the filesystem. In fact I got the amd fusion mobo just last week.

But I dont expect it to perform as well as an ASIC based circuit with high quality clock like might exist with a CDP. Except that a CDP mechanicals will add to the jitter, I would expect if you plonked in an SSD into CDP instead of a CD tray(in which case it would no longer be a CDP) it would perform better than a desktop PC.That was the point of my post.

--G0bble

 

[ranjeetrain]

Yes... ............did!

... Actually, ................. time.

Whether .............. time.

Thus, ................work.

We are going too much into the PC/Software/OS direction. Windows vs Linux will be another intriguing debate.

Let's just say that - a computer, not running multiple applications, not running unnecessary background processes, will be able to go a very good job of being a Tranport (if not more).

And those who want just the perfect OS for their audiophile computer, please join my project I started it when I had some free time, but busy again. Or should I say, unable to spend quality time writing a custom shell all by myself

 

[gobble]

Yes... let's knock the stuffing out the ideas, not each other.
In an ideal world, yes. Mind you, most people here would share my experience that the computer does not audibly stop playing sound to do something else. Usually. I built this computer because the last one actually did!

 $  ps -ef | wc -l
184

... Actually, I thought there would be a lot more! Most of those processes will be consuming no resources for most of the time.

Whether Linux is better than Windows at multitasking is a moot point, and one that we might moot some time. It is true that it is built on a model that was a multi-tasking, multi-user system long before Windows was born, and even longer before it would, even with more than Window open, actual let us do more than one thing at a time.

Thus, I'd suggest that Linux is the better system, but someone would immediately remind me that it is running on the same hardware-interupt-based physical architecture, and then go on to remind me that Linux audio people, whilst not, perhaps, going to the same levels of process elimination as one might with WinXP, do have complex tweaks to balance interrupts, and do go to the trouble of using "real-time" kernels. Things seem to have easier recently. It's not that long since I wrote a whole thread about my struggles to make my particular system work.

I wanted to post about the number of processes you would still find in a barebones minimalistic OS, but skipped it - thanks for that reminder.

And yes I do plan on a realtime Linux kernel for my audio PC.

--G0bble

 

[gobble]

And those who want just the perfect OS for their audiophile computer, please join my project I started it when I had some free time, but busy again. Or should I say, unable to spend quality time writing a custom shell all by myself

Whats in it?

--g0bble

 

[Staxxx]

For those who want to start off into PC music, some tips:

1) cabinet: get a nice one, preferably something that can be mounted into the audio rack.
2) get a good sound card, the best that your budget allows
3) buy hard disk as per need. You can add later
4) SMPS and CPU fans: get the most silent one
5) Software applications not needed for music play out not to be installed. This includes AV.
6) bypass the OS's audio mixer. Use something like WASAPI or at least ASIO (or their equivalents in other OSs.
7) get more memory
8) rip your CDs using a good ripping software. Win Media Player is avoidable. Don't believe folks who tell you bits are bits. Some are more equal than others. Crap in, crap out applies strictly.
9) ripped files can be stored as uncompressed files or as flacs.
10) avoid lossy compressed file formats. No, this point is not open to debates. I have heard both sides of the argument. Stick to the real thing, not the facsimile.
11) get a good digital interconnect. Well shielded one. The laws of electromagnetic interference don't stop working just because the signal is digital.
12) give it the best outboard DAC you can buy.
13) unless your DAC is a current model that can do asynchronous USB as well as it does SPDIF or AES-EBU, stick to the latter two. Remember that these two are audio specific interfaces, while USB is not and lab coats are twisting themselves into knots to make it work for audio. It is at best a work in progress. Unless you can afford a dCS or some OEM who has licensed their USB technology.
YMMV, of course.

This is a really interesting thread and I am intrigued by the various views expounded. I use a fairly high end CD player (Esoteric K-03) but still feel my digital system is slightly more to my taste in it's presentation, perhaps as I have spent longer time with the sound of the external DAC.
I just wanted to mention, one thing that surprised me was the signature of various digital cables - point 11 here. In a revealing system, I was surprised at the impact of the digital cable. I currently use two Jorma digital cables (SP/DIF) and tried a few others (three or four brands, including Stealth etc.). Each very clearly made an audible difference. This is from personal experience and I am sure there are many who will be skeptical of this.

 

[ranjeetrain]

Yeah agreed, I plan to build a custom linux machine that does nothing but run a player and read the filesystem. In fact I got the amd fusion mobo just last week.

I have saved many of my "vintage" PC components safe with me. One of them is a 12 years old Intel mobo, running on the then state-of-the-art RDRAMs (history now). Compared to current generation mobos that pack everything on one board including Wifi (scary thought when we are talking about signal purity), they were truly modular. You add the component for the functionality you want.

I "hope" my prehistoric age mobo p) they will have much lesser noise compared to current generation ones. I do hope to build, someday, an totally PC-based transport, which will rival the very best in consumer transports.

But I dont expect it to perform as well as an ASIC based circuit with high quality clock like might exist with a CDP. Except that a CDP mechanicals will add to the jitter, I would expect if you plonked in an SSD into CDP instead of a CD tray(in which case it would no longer be a CDP) it would perform better than a desktop PC.That was the point of my post.

I hear you. Those devices are specialized. I still believe you would find the computer transport + high end DAC to be much more rewarding.

 

[jai1611]

This is where we need to set the context correctly.

You are talking about a general purpose (all-purpose/generic) computer, isn't it? Yes, I agree with what you said, BUT, that is valid only in case of a generic computer.

My point was -- built keeping audio duty in mind. A computer built for audio duty will not have a complex kernel. It will not need to do time sharing with multiple users. It will not be running 4 threads for checking email, 4 threads for the document you are drafting, 4 threads of notifying you about your contacts coming online and going offline. It will not have 10 threads constantly validating the data you are writing to the media to be malware free, and will not have a browser session running 20 threads and 100s of background processes.

Here comes the difference between a generic computer and a computer optimized for audio duty. A computer optimized for audio duty should:

1. Have a bare bones kernel
2. No security needed
3. Just ability to mount/unmount block devices
4. A file system module, to allow reading/writing of data
5. No background processes

So, if you see, whereas a generic computers has 50-100 processes and hundreds of threads, an audio only computer will (should) have 2-3 processes and 5-8 threads. Besides, "the OS" should prioritize the thread writing the data to the output stream, to have highest priority.

It is highly unlikely that a computer built to perform audio duty, will not be able to perform several writes a second. And as soon as you think of asynchronous writes, that requirement of "precise time" ceases to exist.

So, you have two choices.

1. Have an ultra precise computer which outputs data at the clock rate as asked by the DAC. This ultra precise computer is your stock Transports available on the shelf.
2. Have a less than ideal computer supply that data in a slightly less precise manner on an asynchronous bus, and let your DAC (outside the computer) handle the rest.

I think JPlay tries to fix the windows is along the lines you describe.

On my pc, it makes an audible difference despite the fact that I can't run it in full hibernate mode

 

[ranjeetrain]

Whats in it?

--g0bble

As of now, nothing much really

But I know in exact details what I want to do. It's very much like what you described you want to do.

• I will pick a Linux kernel.
• Strip it down to bare essentials.
• Compile it.
• Write a custom shell, extremely lightweight, as this is the part that will take tons of CPU cycles.
• Load it onto my prehistoric age mobo

 

[ranjeetrain]

I think JPlay tries to fix the windows is along the lines you describe.

On my pc, it makes an audible difference despite the fact that I can't run it in full hibernate mode

Interesting! Something I would look into if I got an opportunity. However, I am skeptic due to Microsoft's design philosophy. Windows really isn't a great candidate for such an endeavor. Linux offers compelling reasons for such things. But lets not go into Windows vs Linux thing here.

 

[kaushik]

ranjeet,
it is real bad to act like head of the advisory committee..we are all learners.
i know your post was a reflection of some assumptions so I pointed, what is that mud you are talking?

Apparently you can't read. I can't help you if you don't know how to read. May be you should go back to school and ask your teachers to help you?

(It is just me who ignored your comments ,read forum rules:

"
Any member who is intentionally unpleasant or disruptive may be banned without warning.
"
same lines you put on other people ,they will raise request to ban you for sure..)

however ,i am in for the OS tweaks and admire your effort

 

[gobble]

I just wanted to mention, one thing that surprised me was the signature of various digital cables - point 11 here. In a revealing system, I was surprised at the impact of the digital cable. I currently use two Jorma digital cables (SP/DIF) and tried a few others (three or four brands, including Stealth etc.). Each very clearly made an audible difference. This is from personal experience and I am sure there are many who will be skeptical of this.

Now your endorsement is really tempting me to invest $$$ in a digital cable. There was discussion around this on the forum ages back but I postponed big spend and purchased a BJ Coaxial instead.

Since you are in Bengaluru, perhaps you won't mind dropping by with your cable for an audition so we can do an A/B?

The carrot for you is that you get to listen to a 47 labs Shigaraki

As of now, nothing much really

But I know in exact details what I want to do. It's very much like what you described you want to do.

• I will pick a Linux kernel.
• Strip it down to bare essentials.
• Compile it.
• Write a custom shell, extremely lightweight, as this is the part that will take tons of CPU cycles.
• Load it onto my prehistoric age mobo

Do you know what kind of expertise it takes to write a custom shell?

there are already minimalistic options: BusyBox

--G0bble

 

[Staxxx]

Sure Gobble, I will PM you.