MAC vs PC -> DAC (Digital to Analog Conversion)

The reasons people choose Windows PC over Mac OS X...

• cheep hardware
• easy expansion
• virtually infinite choice of software combinations
• infinitely customisable
• lots of tweaks possible to get best sound

The reasons people choose Mac OS X over Windows PC

• more expensive but average useful life of Apple hardware tends to be longer
• limited expansion, but you know the hardware works
• software you need is available and well written, often supplied
• easy to use as customisation is limited
• good sound without wading through tons of tweaks / experimentation (i.e. what is best sounding ASIO or WASAPI or KS?)

There's lots of other reasons for both ... but these tend to be the most definitive... A lot is down to personal preference.

Eloise

He,

considering your tone, you should go the Apple way.

Anyway, Eloise has forgotten an important one for me :
Windows will switch sample rate automatically when out-of-the-box mac os won't (and you will have to pay (again) for that).

Elp

I actually gave this a lot of thought!

If we are lucky enough, our systems are going to contain products we regard as statement, once in a lifetime purchases - speakers, amp(s) to drive them, cables to connect them etc. We are, however, driving these beloved items with personal computers - which these days are, almost, disposable items!

Now, I'm writing this on my iPad, which cost me £500 and is definitely not disposable - but I do not expect it to last me much more than a couple of years. Computer technology has driven forward at a tremendous pace over the last 30 years and there is always some new technology, some new gadget, to tempt us. That's how the industry survives, by constantly tempting us with the next latest, greatest, thing.

So, if I want to take advantage of 'Quantum LightFire HyperSpeed' wireless sound cards, when they turn up, I need to able to have a system I can bolt one on to. So for me it came down to buying the lifestyle statement computer and maybe having to stand still - technologically speaking - for a while, or go for flexibility, cheapness and less of a financial hit to stay with the game.

It wasn't easy! There's a lot to be said for the simplicity offered by buying an Apple computer. But I could buy two of my current servers for the price of one Mini.

The one thing I never considered at all, of course, is the 'superior sound quality' one gets from an Apple computer. Because that's just rubbish. Old wives tales, Internet gossip, call it what you like but it's still rubbish. Apple computers are not better for audio. There is a case for arguing that they are, by and large, better built than your average PC and are likely to be more reliable in day to day use due largely to the locked down hardware and certified software platform. But there is absolutely nothing inherent to an Apple computer that is magically going to make it sound better!

And it could equally be because Apple computers generally look lovely and PC's generally look like disposable commodity items!

Elp, allow me ...

Windows will switch sample rate automatically

Which is of no use at all, once you want bit perfect output.
If *I* am overlooking something, I'm sure you (anyone) will let me know.

And FWIW, since I have the best playback for realistic sound reproduction (I leave out further superlatives), which operates on Windows only, the answer should be "Windows".
But skip it if you think I can't be trusted. No problem.

Peter

"Anyway, Eloise has forgotten an important one for me :
Windows will switch sample rate automatically when out-of-the-box mac os won't (and you will have to pay (again) for that)."
Well if your hardware, software and drivers will all play game and you get the number of samples in the buffer correct and you don't get clicking noises (all are problems people have reported having - not just made up!). It's hardly "out of the box" IMO.

As I say, swings and roundabouts.

@Peter
Not sure what you mean.
That does not collide with bit-perfectness, right ?
I've tested this ok with the nice feature of the weiss int202.

@Eloise
I wouldn't let others discourage you.
That works out-of-box with Windows7 at home for several digital interfaces and dacs.
Now that you speak about it, I did have difficulties with firewire interruptions at first. But that never led to clicking/buffer/whatever issues. And the computer is really a poor lad (as far as cpu is concerned), so that should really not be an issue on any recent one.

I was even surprised when my netbook stopped (out of fuel) playing music, and music simply restarted (where it stopped) when I plugged it to the wall (fuel plug :D).

Anyway, I'd rather we don't start the Apple/PC war when obviously you don't play much with windows (as far as music serving is concerned) and I don't with mac os.

Elp

Very good points.

one note:
"when out-of-the-box mac os won't"

Mac will also resample AIFF file from a CD to mp4- so do not import into iTunes unless you need this.

>> Windows will switch sample rate automatically
Which is of no use at all, once you want bit perfect output.
If *I* am overlooking something, I'm sure you (anyone) will let me know.
Now I'm confused - surely you want Windows to switch the sample rate it outputs to match the sample rate of the file to keep the file bit-perfect (i.e. not re-sampled).

And FWIW, since I have the best playback for realistic sound reproduction (I leave out further superlatives), which operates on Windows only, the answer should be "Windows".
Ha ha ha!!

Eloise

PS. Anyway, I'd rather we don't start the Apple/PC war when obviously you don't play much with windows (as far as music serving is concerned) and I don't with mac os.
You're right ... well I have been playing with Foobar but need to get it connected to the main system really ... but generally both can give good results but both have limitations.

mediapress... "Mac will also resample AIFF file from a CD to mp4- so do not import into iTunes unless you need this."

iTunes will import a CD in whatever format you tell it to. I guess you mean that default in iTunes is to import as AAC?

Eloise

Hi Elp,

Not sure what you mean.
That does not collide with bit-perfectness, right ?
I've tested this ok with the nice feature of the weiss int202.

This is not a straight "statement" of mine as such, but I think it can be reasoned out that as soon as you leave it to Windows to switch sample rates, you are subject to the Audio Engine in there, and that NEVER is bit perfect ... under no condition.

To clarify better (hopefully), look at it the other way around :

Use WASAPI Exclusive Mode (guaranteed bit perfect), and notice that Windows is doing nothing here. So, sample rates may switch allright, but now it is because *I* (the developer of the playback software) do it. If I do nothing, nothing will happen when the material changes (for sample rate etc.), and you'll have the chipmunks around. Or Elvis for that matter.

But maybe I overlook something ?
Peter

PS: But ... regarding the above, what were the "Weiss conditions" here ?

for some people is familiarization. Though my first personal computer was a Franklin, an Apple clone, I've owned many DOS and Windows PCs continuously from the the very beginning of personal computers.

Despite Macs being easy to use, there have been several times when I have been frustrated by trying to do something on my MacBook Pro that I know very well how to do on any Windows PC.

Perhaps for a computer novice the Mac has the edge. But even for the newbie, you're likely to know many more folks that can help with Windows computers than Macs.

On a practical note, both Windows and Macs are better than Linux, unless you're really a computer expert.

"I note that most people are using a PC for Digital to analog conversion & music playing."

Hi Mediapress - Note that nearly nobody is using a Mac or a PC to do Digital to Analog conversion.

I really do not see that much of a difference either way. I run Mac, because I prefer it as an OS, not just as a music server. The player software seems to be key. Itunes is a decent catalog system, and I am rather enjoying using it with Pure Music. My only real complaint is that I cannot use Peter's XX Highend on my mac. I hope he ports it, but I'll not hold my breath.

He Peter,

Use WASAPI Exclusive Mode (guaranteed bit perfect), and notice that Windows is doing nothing here. So, sample rates may switch allright, but now it is because *I* (the developer of the playback software) do it. If I do nothing, nothing will happen when the material changes (for sample rate etc.), and you'll have the chipmunks around. Or Elvis for that matter.

Ok, I never took a look at those APIs, so I guess you are correct here, being a developer of a playback software :D

How does that work for KS and ASIO ?

I thought at some point Windows would let you bypass its mixer/kernel but still make good use of initialization services, such as sample rate setting (as far as architecture is concerned, this does not have to be in the mixer/kernel).

PS: But ... regarding the above, what were the "Weiss conditions" here ?

JR MC15, Wasapi exclusive, no dsp option at all.
Nothing set in the Int202 drivers (apart from overall latency).
You then just need to play those test files, and look (with angst) at the BT check led. If it swings, then you win ;D
Tried both 24bits and 16bits files with expected results.

JR MC15, Wasapi exclusive, no dsp option at all.

Which is why it works (bit perfectly). So, the OS is not involved here, and my explanation from before applies.

How does that work for KS and ASIO ?

100% the same.

Actually it is easy to see;
Vista/W7 don't allow 88.2 and 176.4 as a choice to resample to. Still you will be able to play that (bit perfectly) through either WASAPI, KS or ASIO.

Besides (a little twist here now) ...
Vista/W7 (W2008) will never switch sample rates as such, because there's always one output sample rate only : the one you denoted (mind you, for Shared Use this time). So, the only thing what happens is that your 16/44.1 file will be converted to your denoted e.g. 24/192, and when a 24/96 comes along, now *that* will be converted to 24/192. So, the output sample rate doesn't switch at all ... the conversion changes though ...

Regards again,
Peter

Right Peter,

ok, this proves that I need to rephrase what I stated above.

Windows will not switch sample rate automatically, but will let the application does it, provided it uses one of the asio/ks/wasapi (exclusive) modes, which are required for bit-perfectness anyway.

Now, all 'serious' audiophile players (from XXHE/MC15 to MM, through Foorbar) will support this, some of those being even free.

Well this might just be the case for mac os applications too, since Amarra is able to do so (but not iTunes, correct me if I'm wrong).

I'll just stand by the price argument then, but that is unfair otherwise asking not to promote the MAC/PC war (I am just human) :)
Then one good argument for a mac book : the touchpad just trounces any (pale) copy from the pc world.

For those wanting XXHE on a mac, I would suggest installing w7 in dual-boot. Looks like a good idea to me.

Elp

I have been playing with both a Asus Ul30A with a 128Gb SSD running J River and a new MBP with a 64Gb SSD running +/- Amarra/Pure Music.
For abit of fun I dl-ed and tried Peter's XX high End again last night after a break for a year or so (Hi Peter!).

Both Win7 and Mac OSX were running in 64x.

I have to say that there really isn't much in it to my ears. The SSD levels the playing field as does copious quantities of Ram.

I use the Asus for work and bought the MBP as a music server and for it's fw capacity.

Funnily enough I liked the stock iTunes in OSX 64 just fine. Amarra was an improvement in some ways. Pure Music in others. Depended on what I was listening to. J River reminded me alot of Amarra. Perhaps not as analogue but close. XX High End is for the devotees's still.

Really OS/hardware comes down to personal preference. I know the Asus is 1/2 the price of a MBP. Mac is shiner and sleeker and better quality.

Ultimately (when Office for Mac 2010 is released) I'll move completely over to Mac. Until then... happy to play with each.

As an ex Linux user I agree life is too short to be a code geek. Although MPD on a low latency 64x kernel is a special animal.

Cheers
A

As Elp says, iTunes does not track the output sample rate to the sample rate of the track being played. This has been stated by Apple as being a feature not a bug (applications shouldn't change the sample rate as it could affect other applications). Right or wrong - well for true Audiophiles using a DAC it's probably wrong, but for the general population it's the right thing to do.

Amarra (and Pure Music) on the other hand do change the sample rate in Audio MIDI as different tracks are played. What they don't do (unlike WASAPI and Kernel Streaming and ASIO in Windows) is bypass any of the OS's audio subsystem (Core Audio in Mac OS X).

Eloise

PS. to Andrew S. - It's going to be Microsoft Office for the Mac 2011.

you are most comfortable with. Both OS do a good job if implemented corectly. Personaly I prefere W7.
The choice should rater bee firewire or USB. Firewire is far superior to USB, but there is DAC's around now that can do as good a job in regards to SQ, asynchronous DAC's like Weiss,Wyred4Sound or even HRT Music Streamer. Seeing that FW is a "dying" protocol for consumer market, I would choose a OS I am comfortable with an playback software acordingly. Then I would invest in a good async. USB DAC.

You wrote:

>Amarra (and Pure Music) on the other hand do change the sample rate
>in Audio MIDI as different tracks are played. What they don't do (unlike
>WASAPI and Kernel Streaming and ASIO in Windows) is bypass any of
>the OS's audio subsystem (Core Audio in Mac OS X).

Hi Eloise,

Actually, Amarra bypasses the majority of Core Audio, relying instead on SSE, a virtual audio engine, what a programmer would call an audio framework. SSE highjacks the audio processing, from disk reads all the way to delivering the audio bit stream to the DAC’s port. SSE is used in all Sonic Studio software, both the entire Amarra family and pro lines.

Peter,

First off you should not be selling your product on this forum. That is not the place.

~~~~~

Out of the box neither Windows Vista/7 or MAX OSX will automatically switch sample rates. Actually they are very much similar in the way the Audio Stack works.

There are free programs on both sides that allow for sample rate change on the fly.

While neither are bit perfect out of the box they both give the capabilities to do so.

~~~~~

Presently in my opinion, Windows is at least a few years behind MAC in audio development. MAC has several things including the move to 64 bit floating point (to allow for 32bit native DACS and ADCS to work bit true) and also Class 2 USB etc... etc...

MAC USB and Firewire base drivers seem to be better than Windows. Therefore the results from testing even with boot camp MACs (i.e. same hardware switching from OSX to say Vista/7) that the empirical data (pun intended) would point towards the MAC.

~~~~~

Otherwise I would agree with Eloise on the differences.

Thanks
Gordon

I don't know the technical details of Amarra and SSE (I assume this is SonicStudio's Sound Engine or something?) ... but it seams to me that it doesn't bypass much of Core Audio - at the end of the day you can mix Amarra's playback with other sounds produced in other applications. Yes Core Audio features playback functionality which is not used, but neither does Foobar or J.River rely on Microsoft supplied playback functionality.

It doesn't (as far as I can tell) "deliver the bit stream to the DAC's port" it delivers it to Core Audio's mixer. Otherwise when playing different sample rates why does it need to adjust the values in Audio MIDI, why can you play (and mix in) other audio - just increase the volume (that Amarra has set to zero) in iTunes if you want an example!

As I say, I'm approaching this from observing the behaviour, not as a coder. But this is what I observe. I can't find a link, but I believe that Jon from SonicStudio actually commented that Amarra doesn't bypass Core Audio - searching with google gives me these quotes though...
Amarra is designed to work with any Macintosh Core Audio Interface from SonicStudio's website.
Amarra automatically switches CoreAudio's sample rate to match that of the file selected from Stereophile's blog.

Is the confusion (that I am experiencing here) due to the fact that the term Core Audio actually refers to a number of layers and processes?

Eloise

You said:
I don't know the technical details of Amarra and SSE (I assume this is SonicStudio's Sound Engine or something?)

Hey Eloise,

Correct, an alternative audio framework.

…but it seams to me that it doesn't bypass much of Core Audio - at the end of the day you can mix Amarra's playback with other sounds produced in other applications…

Sorry but, it does. See below…

It doesn't (as far as I can tell) "deliver the bit stream to the DAC's port" it delivers it to Core Audio's mixer. Otherwise when playing different sample rates why does it need to adjust the values in Audio MIDI, why can you play (and mix in) other audio - just increase the volume (that Amarra has set to zero) in iTunes if you want an example!

SSE doesn’t disable Core Audio; any Core Audio processes continue to work in parallel. SSE writes to the HAL or Hardware Abstraction Layer, the same (end of the chain) API that Core Audio writes to. It adjusts the DAC setting, which results in a change displayed in Audio MIDI Setup.

As I say, I'm approaching this from observing the behaviour, not as a coder. But this is what I observe. I can't find a link, but I believe that Jon from SonicStudio actually commented that Amarra doesn't bypass Core Audio - searching with google gives me these quotes though...
Amarra is designed to work with any Macintosh Core Audio Interface from SonicStudio's website.
Amarra automatically switches CoreAudio's sample rate to match that of the file selected from Stereophile's blog.

Amarra and SSE can’t bypass all of Core Audio, otherwise the data stream would never arrive at the DAC.

Is the confusion (that I am experiencing here) due to the fact that the term Core Audio actually refers to a number of layers and processes?

Among other things, yes. Core Audio is a “framework” which is an appropriate label. It’s contains several software subsystems that handle specific functions. The aforementioned HAL is one of them.

SSE does all the “heavy lifting” right up to delivering the music to the hardware. That heavy lifting includes file I/O, data format conversion like fixed-to-floats, and any user requested processing like EQ and re-dithering. It then writes to the HAL, bypassing even the Core Audio mixer.

I hope my rant makes this semi-esoteric schtuff a bit more understandable…

I haven't seen any polls, but my informal sense was that at least half of the folks here use macs (as music servers -- pretty much everyone here uses external digital to analogue converters), and that mac minis in particular were quite popular.

OS X as you probably know is unix-based, and therefore you can compile and run pretty much anything from (eg) linux, as well as all the standard OS X software.

OS X uses Apple's CoreAudio framework. (See their website for an explanation of this.) One of the features/problems with that, depending upon your point of view, is that individual applications aren't allowed to switch the systemwide sampling rate, to prevent one from messing up another. This means you either have to use an application that breaks the rules (Play.app can do this, and is free), or you have to switch the sample rate yourself.

Applications like Songbird use their own audio framework, I think, and therefore aren't restricted.

I don't have very much experience with Windows, and none with it as an AV platform, but I would be surprised if it is any better in any significant way.

SSE doesn’t disable Core Audio; any Core Audio processes continue to work in parallel. SSE writes to the HAL or Hardware Abstraction Layer, the same (end of the chain) API that Core Audio writes to. It adjusts the DAC setting, which results in a change displayed in Audio MIDI Setup.

Okay... This is the bit that confuses me: how can two things write direct to the HAL at the same time? Both Amarra and (for example) YouTube can be playing audio at once and both come out the same hardware device - yet you say Amarra bypasses Core Audio mixer?

Is Amarra not missing a "Hog mode" ala Pure Music?

Eloise

I think it is designed to allow that so that you can be interrupted by a mail arrival sound while listening to music (for example).

But you can also do the reverse.

I have an HDMI out and optical out. HDMI goes to my TV and soundbar, and optical goes to my DAC and stereo speakers.

I can set the default sound output to HDMI and play iTunes sound (movie, music, etc) through the TV speakers and soundbar, and simultaneously use Play.app to play something completely different through my speakers. All within the confines of the core audio.

I think it is designed to allow that so that you can be interrupted by a mail arrival sound while listening to music (for example).

Surely in this case, iTunes and Mail (for examples) are 2 inputs to the Core Audio mixer not writing direct to the HAL: or are you saying there is no mixer in the same way there is in Windows?

Eloisr

I wasn't saying either since I don't know, but I think Shirley is right.

Eloise wrote:
This is the bit that confuses me: how can two things write direct to the HAL at the same time? Both Amarra and (for example) YouTube can be playing audio at once and both come out the same hardware device…

In our meat world, things appear to happen simultaneously. Yet, in any operating system, data transfer request are buffered up and time domain multiplexed (chopped up in time, then interleaved) based on the order they are received, their priority, etc. The result is two or more audio sources playing “at once.”

Is Amarra not missing a "Hog mode" ala Pure Music?

Rather than “hogging,” SSE tries to play nice with the other children.

Surely in this case, iTunes and Mail (for examples) are 2 inputs to the Core Audio mixer not writing direct to the HAL: or are you saying there is no mixer in the same way there is in Windows?

Core Audio does have a panner/mixer as well as other fun stuff like a generic HRTF for spatialization and a well implemented plug-in architecture, AU.

BTW wgscott, love that marsupial avatar!

In our meat world, things appear to happen simultaneously. Yet, in any operating system, data transfer request are buffered up and time domain multiplexed (chopped up in time, then interleaved) based on the order they are received, their priority, etc. The result is two or more audio sources playing “at once.”

Yes I understand computers don't do anything simultaneously, it's the illusion created by things happening in little time slices however: ... is what you are saying that when another application (inmy example Safari) is trying to play music simultaneously with Amarra that you get...
Amarra sample1:Core audio sample1:A.s2:Ca.s2:A.s3:Ca.s3:A.s4:Ca.s4:...
well you get the idea... output from the audio device? Or as it would have to be
Amarra.sample1:CoreAudio.sample2:A.s3:Ca.s4:A.s5:Ca.s6
as otherwise you'd be halving or doubling (can't work out which) the playback sample rate. I think I was happier with the idea of Amarra and Core Audio feeding two audio streams into a mixer.

The more I think of this the more that exclusive use mode actually is better idea! Why do you want SSE to "play nice" and be able to mix in with Safari sounds, etc.?

Can I also ask - what association do you have with Sonic Studio and Amarra?

Eloise

PS. I'm really trying to understand this ... but I can't see how two audio streams can reliably write to the HAL directly. You need a mixer (in my mind). It's not like connecting 2 audio sourses to a single analogue input!

Eloise,

In my experience using HOG mode and bypassing the mixer and using fixed instead of floating point is a huge upgrade.

Just bypassing the mixer alone would be a huge step forward. Sure you specify your internal speakers as your default core audio output and specify your high end dac via the Audio Application. But you are still going through the layers.

The more layers the more processing time the less quality. That has been proven.

If you look at the processes in the terminal application (don't bother with the damn activity monitor it tells you nothing). You can see a drastic reduction in overall processing time and application processing time when using HOG mode.

Thanks
Gordon

In my experience using HOG mode and bypassing the mixer and using fixed instead of floating point is a huge upgrade.

Just bypassing the mixer alone would be a huge step forward. Sure you specify your internal speakers as your default core audio output and specify your high end dac via the Audio Application. But you are still going through the layers.

I think I'm agreeing with you ... that bypassing the mixer is good. What I'm saying is that I can't see how Amarra can be bypassing the mixer as you can be playing a file from Amarra and also playing another from Spotify at the same time and they are perfectly mixed (same as if you are playing iTunes and Amarra at the same time).

Am I missing something - I haven't found how to specify a different device for output of Amarra (unlike Pure Music).

Eloise

You wrote:
Yes I understand computers don't do anything simultaneously, it's the illusion created by things happening in little time slices however: ... is what you are saying that when another application (inmy example Safari) is trying to play music simultaneously with Amarra that you get...
Amarra sample1:Core audio sample1:A.s2:Ca.s2:A.s3:Ca.s3:A.s4:Ca.s4:...
well you get the idea... output from the audio device?

Hey Eloise,

Software writes to the HAL and HAL takes care of the gory details. That’s what abstraction layers do for a living. They behave as an idealized “real” version would so, in this case, the HAL would behave as actual audio hardware would. All modern OSs abstract audio and graphics subsystems for lots of good reasons. The gory details of how Mac OS’ HAL actually processes incoming data is probably available from Apple's developer documentation, or not.

The more I think of this the more that exclusive use mode actually is better idea! Why do you want SSE to "play nice" and be able to mix in with Safari sounds, etc.?

Sorry to answer with a question but: why not, especially if it gets the job done without “breaking” other services, like user alerts?

Can I also ask - what association do you have with Sonic Studio and Amarra?

Sure, I’m a consultant and Sonic Studio is one of my clients. I work with several audio manufacturers, you can read way too much about my company on my site.

PS. I'm really trying to understand this ... but I can't see how two audio streams can reliably write to the HAL directly. You need a mixer (in my mind). It's not like connecting 2 audio sourses to a single analogue input!

Definitely not like analog…My guess is that, inside the HAL there is simple arithmetic summing of all inputs, in floats, which would be the equivalent of the most basic of mixers. The result of that summation, after further processing, is what is presented to the designated output at each clock cycle.

Hi Oliver,

Definitely not like analog…My guess is that, inside the HAL there is simple arithmetic summing of all inputs, in floats, which would be the equivalent of the most basic of mixers. The result of that summation, after further processing, is what is presented to the designated output at each clock cycle.

How you that work if sample rates are different ?

Elp

My guess is that, inside the HAL there is simple arithmetic summing of all inputs, in floats, which would be the equivalent of the most basic of mixers. The result of that summation, after further processing, is what is presented to the designated output at each clock cycle.

So at the end of the day there IS a mixer inside the HAL is what you're saying!

Elp asked about different sample rates - I guess this is why the Core Audio interface tracks the sample rate, so that that converts everything to whatever rate the music being played is at.

Eloise

My take on this is that - where does Core Audio begin and end? Somehow the HAL layer mixer is "better" than one in Core Audio?

If the higher - bit-depth processing is important during the playback chain, it's then OK for the "HAL" to mix two audio streams together using (presumably) the same level of arithmetic as Core Audio?

If it's a mixer, it's doing some processing. Ergo, the claims about Amarra bypassing the entire audio stack are weak at best.

NB I'm not saying there's anything wrong with Amarra in and of itself, but claims that it bypasses Core Audio completely wouldn't seem to stand logical analysis...

your friendly neighbourhood idiot

I'm glad I'm not the only idiot who thinks that doing mixing = processing /= bypassing Core Audio completely.

I guess it depends on if your definition of "Core Audio" includes the HAL.

Eloise

you're certainly no idiot,

I, on the other hand....

your friendly neighbourhood idiot

You said:

My take on this is that - where does Core Audio begin and end?

Hey iSavant,

My take is that Core Audio ends at any and all of the transmitters designated as audio outputs.

Somehow the HAL layer mixer is "better" than one in Core Audio?

An summing node, whether analog or digital, is not a “mixer” by most people’s definition. Mixers usually have gain staging and panning, at the very least and, by modern standards, that a pretty lame mixer. So yes, I would say the accumulator in the HAL is better for what we all are trying to accomplish: better SQ.

If the higher - bit-depth processing is important during the playback chain, it's then OK for the "HAL" to mix two audio streams together using (presumably) the same level of arithmetic as Core Audio?

Simply put, no. The Core Audio mixer is a “real” mixer, with gain, pans, routing and redithering and Apple only knows what else. Complex convolving, like plug-in processing, is probably done both before and after the mixer, since it depends on where the processing has been instantiated. So, audio passing through normal Core Audio paths must pass through a very complex “process,” in the true sense. Even though some coefficients may be set to unity, others are not, and they all act as operators on the audio data. And, this is floating point not fixed point arithmetic, which means the low order bits (the low amplitude data) are sacrificed, again and again, on the altar of gain staging.

If it's a mixer, it's doing some processing. Ergo, the claims about Amarra bypassing the entire audio stack are weak at best.

Never said SSE bypasses Core Audio entirely. If that were the case, you’d never get audio out of the computer! It bypasses everything right up to the output spigot.

There are many on here who claim to have bit perfect output. However, 99% of those are unable to absolutely confirm their claim. Quite sophisticated test equipment is required for that and I'm sure that most of us do not possess it. While we would all like to have the best possible input into our Dacs, its really a case of trying different options/drivers etc until you find one that suits.

It's important to bypass the "Core Audio" mixer because we don't know what level of processing it does, but it's OK to use another part of Core Audio to mix together the two streams, even though we don't know what level of processing that does?

Any kind of mixer is a multiply. This must have an arithmetic width, and will result in the output increasing in wordlength, so again, some kind of dithering/truncation is probably required at the output of the mixer.

Additionally, if you bear in mind the fact that iTunes has been proven on here to stick the same bits out of the audio output are as in the file, and Amarra/SSE puts out the same bits, there can be no arithmetical advantage to SSE, unless you are using some of the processing (i.e. gain, EQ) - which I would agree SSE should do better than Core Audio.

As a side note, if Amarra/SSE is super low-latency, why is it that when you increase the iTunes volume, the iTunes version comes out before the Amarra one? NB I don't think latency makes any difference for playback...

your friendly neighbourhood idiot

"since I have the best playback for realistic sound reproduction"

Peter, can you share with us the setup of hardware and software that allows that claim..?

"since I have the best playback for realistic sound reproduction"
Peter, can you share with us the setup of hardware and software that allows that claim..?
Peter would be referring to his own software and own designed DAC...

"Peter would be referring to his own software and own designed DAC..."

I know that, but a DAC does not play alone and I am always curious about the complete setup...

Thanx

iSavant said:

So...
It's important to bypass the "Core Audio" mixer because we don't know what level of processing it does, but it's OK to use another part of Core Audio to mix together the two streams, even though we don't know what level of processing that does?

That’s not what I said.

Any kind of mixer is a multiply. This must have an arithmetic width, and will result in the output increasing in wordlength, so again, some kind of dithering/truncation is probably required at the output of the mixer.

Ah hah, you said it. Even the most basic real world mixers need to have, at the very least, additions (the actual summing operation) and multiplies (level adjustment for each input then post-summing gain normalization), re-dithering (another multiply) and then truncation. And that’s not even considering the fancy stuff. In comparison, a summing node is just a summing node. Arithmetically, a significant difference.

Look, Windows, Mac OS and other modern OSs all employ hardware abstraction, and not just for audio. All I/O is abstracted. So, unless you’re anti–computer music, you live with hardware abstraction every time you listen, regardless of who makes your favorite widgets and apps.

Additionally, if you bear in mind the fact that iTunes has been proven on here to stick the same bits out of the audio output are as in the file, and Amarra/SSE puts out the same bits, there can be no arithmetical advantage to SSE, unless you are using some of the processing (i.e. gain, EQ) - which I would agree SSE should do better than Core Audio.

Though you won't hear any manufacturer provide details as to how exactly they manage to get improved SQ from their product, bit perfect output is assumed as an entry level feature in any of the dozens of music playback apps out there. If the above statement were true, why is it that you, I or anyone can head to a dealer or, if their system and auditory faculties are up to it, run any of these apps at home and hear a difference when compared to Apple’s or Microsoft’s default playback? (Have you tried Amarra's bypass button?) It's not, we assume, because Sonic Studio, Channel D or any other manufacturer who states bit perfect operation is lying. It’s because we’ve found better ways to handle audio data that the OS defaults which are, as I’ve mentioned elsewhere in this forum, general purpose systems, designed and built for any and all eventualities.

As a side note, if Amarra/SSE is super low-latency, why is it that when you increase the iTunes volume, the iTunes version comes out before the Amarra one? NB I don't think latency makes any difference for playback...

Simple: the interapplication communication between iTunes and Amarra, which has nothing to do with audio BTW, is relatively slow and of lower priority. In comparison, iTunes is always given a very high priority so its requests are always serviced very quickly.

Oliver ... when I questioned the lack of Hog mode, you commented that Amarra didn't need it because it wrote to the HAL ... but surely the advantage of the Hog mode in Pure Music is that it avoids any need for the mixer being utilised - therefore there IS a need for a Hog more as you (I think) and Gordon have both said that it's best to avoid mixers which (with Amarra) can't in some case be avoided. Likewise in Windows applications where they use WASAPI exclusive mode.

Eloise

The 'quite sophisticated equipment' could be an AV reciever with DTS decoder. Play a DTS track through the digital output of the computer to the reciever.

Mike,

Peter, can you share with us the setup of hardware and software that allows that claim..?

I can do that allright, but please notice you should look at it as a "concept". The very explicit concept of

1. Pass on the data as much 1:1 as possible;
2. Use speed as one of the means to get there.

Since audio is "vague" and almost always a subjective thing to the users of it, I thought to better hunt for a discrete "something", which for me became that 1:1 passthrough of everything everywhere in the chain.

This is very contradictionairy, because where our today's chain start at the digital part of the end result of recording (be it redbook or higher res material), it is not *allowed* to pass that on 1:1. We'd have high levels of harmonic distortion when doing so, thus the first step is to approach this as best as can be. This means throw out all of the existing rules, and create some of your own.

The first part (but I skip ripping) we run into is the playback software. And yes, it should spit out the bytes as they were read from disk. Although this is subject to the last posts in this thread (about hogging the mixers etc. etc.) this isn't all that difficult as long as you are a(n audio) software developer and know where to get what.

Once that's done, the bytes have to be passed on to the D/A converter, and sadly this traject doesn't imply that the bytes are interpreted as intended. It is subject to jitter;
When all has been done in the DAC itself to avoid / eliminate as much jitter as possible, there's still inherent jitter in the DAC itself (I refer to the whole cabinet now), and that jitter is influenced by the software at the other end. It just is, and the verdict on the "exactly how" is still out.

So, still being in the software "layer", it is best if that software influences the (jitter) behaviour of the DAC in a positive sense.
This is my personal take on the software part, and I am the only one doing this. I mean, with "control" and sliders for it (knobs these days :-).
This may be 10-15% of the whole 1:1 job, but this 10-15% is in a rather important area of the listening pleasure. Also it has been proven that it works on any system/DAC/etc.; Part of the proof is that the results are consistent over users.

Next in the chain is our DAC;
It is here where so many options exist, that chances are 100% that a wrong combination is chosen. There's the whole clocking thing, the input receiver, the DAC chips and types used, the I/V conversion (in-chip or not), the gain stage, and ALL influence eachother so much, that it's just a Gordian Knot to solve when you want to do it right. And then I didn't mention PSU design, PCB layouts which may give you noise at -100dB or over -140dB.
Luckily, if you follow the 1:1 route, a lot of combinations fall out, and measuring becomes a great help.

It is here though, where the 1:1 (at least for redbook) is not allowed to apply, so it is here where the chances are. It is also here where it is done wrongly without exception, and thus it is here where all can be gained once you know how to do it right.
Long story short on this part : it can be done (because I have), but it "requires" an overall design where *none* of the parts mentioned are common, or even ever used before.
And mind you, "none of them" is rather drastic, where "one" improves significantly already.

Although theoretically such a DAC doesn't need special software to feed it (the music data), in this case it does because of the lack of the needed support by the OS or hardware parts which just don't exist. So, what's lacking on the general side, was filled in by the (player) software side of things. Part of this is the filtering dealing with the so important 1:1 strategy, while another part is about the sheer needed input sample rate to avoid harmonic distortion *when* this is combined with the special filtering (notice that "filtering" uses upsampling as a vehicle).

Once we are at the output side of the DAC, bad life may start, because we're now outputting transients unheard of. So, this happens as a result of the 1:1 strategy, which carries as one of its properties that transients are maintained. Notice though that a large deal of this happened at the analogue stage of the DAC (with all kinds of implications on the current surge, capacitors which must be able to follow, slew rates of (active) devices used) ... which now apply the same to the following parts in the chain.

The first next part is the amplifier, and certainly not any means of preamplifier or other attenuation means. The first *that* does it killing those transients again, assumed that whatever it will be, will be in the signal path.

Now we have to go back to the playback software again, because it will be there where the attenuation must happen (according to my ideas that is), and there's only one 100% legitimate digital attenuation scheme - and this is in my software. It is lossless, which firstly means that out of an attenuated stream the original can be recreated, but thinking somewhat further it implies "bit perfectness" for that area, because no single byte (bit if you want) is inconsistent with the others - hence stays for the inter relations as how it was in the original stream. Only the output volume is lower.

Still there ?

What we need next is a fast amplifier which is able to follow those transients and what easily comes down to the nessecity to follow a 30V jump within the time of one (redbook) sample.

While specs of amplifiers may show you the capabilities in this area, it is not to underestimate what happens if they do "just not" follow what is needed here. Firstly a voltage peak may arrive too late, while before it's at its peak it has to go down already. This is not just square wave behaviour (for measurement), but incorporates the necessary pre-swing, the overshoot and anything that takes time BUT is depended on what happened before. So, a 30V swing may be possible, but maybe not when a -30V swing just preceeded it ...

When the amps are fast enough to follow all this, we'll have a problem in the last part of our chain : the loudspeakers. If they can't follow our preciously pre-cooked data, it will be extra-wrong. In that case we better had 2000K interlinks to filter (oh yes) everything in the first place. Or a somewhat more fluffy amp. Or a nice preamp. Or a lousy DAC. Or a flattening player.

And so the speakers now have to be ultra fast, and I think this can only be done when they are the most sensitive, hence don't need much to move (their driver's diaphragms).
Here too (out of anything btw) a pre-swing applies before a frequency fully develops. The faster this is, the more the peak (excursion) will be there before it has to distract.

Well, if you are only with me that this is a kind of different approach then, say, tubes which nicely distort when they distort, you'll also see that such a comparison with SS is out of order, because nothing should distort in the first place. And nothing = nothing, and stating that some can't be avoided is out of the question. But -as in my case- it may take you 5 very explicit years to get there. And then to think that indeed the software is my own, the DAC is my own, the amps where under my close watching development, as were the speakers for a large part. And mind you, this is all up to the smallest resistor, the DAC being the most difficult, because all is amplified hugely from there.

It is all about quite undoable stuff; If I only mention the digital attenuation - thus the amps at full gain all the time - while the combination with the high efficiency speakers just *will* exhibit a blast of noise when it would be at -100dB ... that part alone ... go look for it. Go look for complete silence and see how odd your chances are.
Of course, it is me myself who put the requirements in the first place, but in the end it all can be done.

I don't think it is necessary to lay out what I exactly use for amps and speakers, although it is the least of the secrets. Nobody is going to buy that anyway. It is about the principles though, and the necessary knowledge of what goes on and what implies which. In the end it is about data sheets and looking at specs and whether they comply;
No such thing like "an OpAmp measures good but sounds bad" exists. No such think like "the best measuring amp is not the best sounding one" exists. You'd have to understand the implications of that well measuring amp though. It may drive your not being able to follow speakers crazy. Or, it may be able to follow the harmonic distortion it is fed with in the first place.

Lastly, there's a whole debate on "how to measure" underlaying. I won't start explaining the details again, but will mention that it is totally useless to follow THD specs on a DAC chip (or DAC) when it includes the filtering. It would be the first mistake to make (following my concept of approach), and we must take it that these figures are useless. Sadly, I know of no other means than understanding the data sheets and looking at the real merits of things, or measure yourself while knowing how to do it (which is out of the question for any normal consumer).

Allright. I hope this has been a more useful answer than plainly mentioning a few brands.
Peter

I've heard many 'high-end' systems in the 35-odd years that I've been in this hobby (I started pretty young!), and I've owned systems that most people would consider pretty 'high-end'. But let me say that Peter's system is the most 'true-sounding' system I've ever heard, and certainly beats any system that I've ever put together. (I think his great room plays a big part in this though.)

I heard Peter's system ~6 months ago and it looks like he's made some improvements since then.

Just my 2c.

Mani.

Peter,

bla bla bla jitter bla bla bla jitter.

Come on... Tell me, in any asynchronous environment with a dac how your software is going to effect the jitter?

It can't... so if you start there and your wrong there then how is anyone going to believe the rest of what your saying?

What next are we going to ask you what kind of test equipment you have?

No because then we would have to know if you can use it.

Ok here's a question or a hypothesis of sorts...

If your software does effect the jitter in some kind of way that makes it less jitter output then how do you know how much to do? Like for example the jitter modulation on say my dac would not be anything like say an adaptive piece... so how do you know what modulation of jitter you should be correcting for?

With that hypothesis in mind the next question would be how many devices have you verified that said software lowers the overall jitter as heard by the user?

I mean if your perfect dac is the model, then maybe the playback for any other device would be wrong!

I would imagine that if I sent the JTEST out your software and compared it to say J River in exclusive mode that the results on my Prism dScope III would be pretty much the same.

Gang this is just advertising... I don't like it.

Thanks
Gordon