New OSX Opensource audiophile player : Audirvana

[wgscott]

Prior to 0.8.1, I could use my iTunes plug-in trick to pick a playlist or album from iTunes (or, more importantly, the Remote.app) and it would automatically load, go to the first track, and start playback. Now it loads, and then nothing happens, and it is poised to play the penultimate track. Is this an unintended consequence of some other change, or an intended feature?

 

I confirmed (by rebuilding) it is one or both of these changes. Maybe my hack was dependent on a bug (although it works with Decibel).

 

It does now deallocate the Halide Bridge like it should.

 

[damien78]

@wgscott: the changes you mention are a bug fix for an inconsistent behavior when dropping a track before the playing one, or at the position of the loaded one.

You may need to ensure the first track is selected for playback before starting it. Maybe by issuing the "previous" command each time you insert a track ?

 

Regarding halide bridge deallocation, is it ok if you first stop playback before exiting ? BTW, what is the improper setting that remains (as seen in HALLab) ?

 

@Joebah: do you get this buzz noise when you press stop ?

And when you first stop, then quit ?

For you settings, as the DAC is capable of more than the bridge, the only setting you may want to tweak is the additional latency to allow the DAC to sync to the new sample rate.

 

@57gold: try with and without integer mode, or maybe tweaking other settings. And be sure not to have run Fidelia before as there have been reports of Fidelia not leaving the device in a proper state after exiting, leading to clicks & pops in Audirvana.

 

Damien

 

[Joebah]

@Joebah: do you get this buzz noise when you press stop ?

 

@Damien: Unfortunately, I don't recall exactly what the sequence of events was. It it happens again, I will make a note and let you know.

 

[Jud]

There's been considerable hubbub, brouhaha, and even foofaraw here at CA regarding SQ differences between llvm-compiled and gcc-compiled Audirvana.

 

I have a proposal for Damien that could go some way toward helping to provide a few data points for the ongoing discussion, and might even get him some useful feedback on compilers and Audirvana SQ.

 

Here's the idea: Along with the normally labeled downloads (for those who don't have time or inclination to play along), provide 3 additional downloads labelled Audirvana A, B and C (or 1, 2, 3, or whatever). Two of these will be Audirvana binaries from one compiler, one will be a binary from the other compiler. Then the user community will report back (a) which two files they believe are identical binaries from the same compiler, and (b) which they prefer with regard to SQ.

 

Along with seeing what proportion of users can accurately identify which binaries are from the same compiler, this could help eliminate any self-imposed pressure on the part of users to be consistent in SQ preference with what they've previously posted here, and might thus be helpful to Damien in deciding which compiler to use eventually for Audirvana 1.0. In order to help serve this function, the reporting from the user community should be done privately to Damien. Then after some length of time, Damien could publish the results to a breathlessly waiting CA/Audirvana community.

 

What do Damien and the rest of the user community think about this?

 

[jhwalker]

if Damien is.

 

It wouldn't be double-blind testing (since Damien knows which build is which), but if the votes are counted accurately, could be revealing.

 

It will be very easy to tell the binaries apart, however, so not sure what utility that (i.e., "a") will be. Sound quality should be the only variable (i.e., "b").

 

 

 

[housteau]

I think it is a good way to go.

 

[Jud]

Yeah, two binaries would be one size, one another. Dang. Wonder if this could be obfuscated somehow.

 

[AudioExplorations]

I would love to see this happen, the files would have to be indistinguishable so that the results are not invalidated by someone unintentionally noticing that either A or B is X cause they are the same filesize for example.

 

I would be highly interested in the results, I have come to terms with different players sounding different, but the same player with different compilers is still a hard pill for me to swallow.

 

[4est]

Do we really need to be tricked into finding the truth? Seems sort of sad if we would need to do that instead of trusting our ears. If one is worried about expectation bias, just don't label them with what compiler was used.

 

I downloaded the GCC version and ran it, but did not compare it to the other as last weekend was a Fidelia weekend. I am getting a little weary of going back in forth with the three players I prefer (Audirvana being one of them), and do not really want to get into the compliers. I am hoping you guys can come to a consensus. Lately I have been choosing one to run for a few days at a time...

 

Thanks Damien for the max rate limiting feature. I informed my friend, and he was excited to try it...

 

[Jud]

Forrest writes:

 

Do we really need to be tricked into finding the truth? Seems sort of sad

 

Heh, well, I think that one was kind of decided when Galileo didn't listen to the fellow who said "Why go dropping things out of towers? Can't we just trust our good common sense?"

 

For me it isn't 'tricking' people into finding 'truth' (whatever that is). We've all seen a lot of sometimes fairly impassioned discussion about this topic, which indicates how fascinated with the subject we all are as audiophiles. As an audiophile I'm just incredibly curious what the results might be.

 

if we would need to do that instead of trusting our ears. If one is worried about expectation bias, just don't label them with what compiler was used.

 

Trying to filter out expectation bias is certainly part of it. Another distinct but related question is whether we can reliably hear differences at all.

 

Now of course there will be ways to distinguish between files - Damien has checksums for the downloads. But I wonder if there is a way to at least make gross characteristics like download size the same so that those who wish to play along can do so.

 

[57gold]

Played with options and clicking doesn't go away.

 

Have another issue, when I close Preferences window, screen heading goes to Finder, and when I click on CD player visual for Audirvana, Preferences window reopens?

 

Am I supposed to delete and reload program? Not sure of the best way to do that?

 

[wgscott]

@wgscott: the changes you mention are a bug fix for an inconsistent behavior when dropping a track before the playing one, or at the position of the loaded one. You may need to ensure the first track is selected for playback before starting it. Maybe by issuing the "previous" command each time you insert a track ?

 

I'm limited because I can't figure out any way to issue commands to Audirvana, eg, Applescript, Fscript, etc.

 

Regarding halide bridge deallocation, is it ok if you first stop playback before exiting ?

 

Yes, this works great. Thanks.

 

BTW, what is the improper setting that remains (as seen in HALLab) ?

 

Sorry, I am not sure what "improper setting" refers to? Do you mean what was happening in the older version?

 

[wgscott]

It isn't our ears, it is our brains:

 

$90 wine tastes better than the same wine at $10

 

 

 

[Joebah]

Here is what caused it: While a track was playing, I selected and deleted the entire playlist, including the track that was playing.

 

[Jud]

Yep, definitely well aware of that research. The elimination of the "label" is one reason for the proposal I made; another is to get some data on whether people can reliably detect distinctions. (By calling it "data" I don't mean to overly dignify any results that might be obtained.)

 

I think use of "the scientific method" is easily the best way of improving audio engineering and thus the musical experience for all of us. Skepticism is a fundamental, tremendously important part of that method.

 

However, we need to try to be sure our modelling of reality is as parsimonious as possible, but not so parsimonious we ignore potentially significant factors. While I agree we humans are *very* subject to suggestion; and that we must look for answers in science and engineering, not what Miska calls "handwaving;" still I think we must be very careful, based on object lessons from the recent past, not to be too certain we've considered absolutely all potential factors that may affect the sound. For instance, applying the reasoning in some of the more "reductionist" comments in this and other threads would deny the possibility that jitter could be audible.

 

How do we know where to draw the line between being sufficiently skeptical that we aren't being fooled (by ourselves or others), but we aren't leaving out something potentially significant? Only way I can think of is through trials and data.

 

[wgscott]

we need to try to be sure our modelling of reality is as parsimonious as possible, but not so parsimonious we ignore potentially significant factors.

 

Or, to put it in more parsimonious terms: Occam's Razor can slit your throat.

 

applying the reasoning in some of the more "reductionist" comments in this and other threads would deny the possibility that jitter could be audible.

 

cf: http://hddaudio.net/viewtopic.php?id=63

 

 

[damien78]

@wgscott: I was referring to how you detected the halide not being reset correctly. And HALLab can give the detailed information of the device settings that have been changed and not reset to normal state.

 

For A/B testing of compilers, I'll make two versions, one named A, the other named B. Both will have same size (adding padding to the smaller one).

Plus I'll make it after adding one or two bugfixes not committed in svn so you can't tell by recompiling it by yourself and compare files.

 

Damien

 

[4est]

There is no absolute wine reference whereas sound reproduction is just that, reproduction. There is a reference, even if it is elusive.

 

Well, in this case they cost the same- whatever you were willing to pony up. Furthermore, at the time "flat earthers" were backed by the science of their time.

 

I find it a bit sad that so many have such strong convictions one way or another as to not trust their observations enough to overcome those convictions. I do not have a horse in this race, but just want the best sound I can get- period.

 

[Jud]

Damien, thanks so much for your willingness to "play along."

 

Hopefully we will all have some fun with this, and maybe you will even get some decent feedback on SQ for your development purposes.

 

[Jud]

I find it a bit sad that so many have such strong convictions one way or another as to not trust their observations enough to overcome those convictions.

 

If that is really what is happening. :-)

 

I personally feel I can trust my observations on my system with reasonably thorough listening, but feel I must be open to the possibility that I'm fooling myself. Or what if folks who say it should be impossible to distinguish find to their surprise that they hear differences? We've already got strong convictions on both "sides," I just want to see if observations have any shot at shaking those convictions either way. To me, the possibility of surprise is what gives this some measure of fun and interest.

 

I...just want the best sound I can get- period.

 

Completely agreed; I think everyone reading this (with the possible intrusion of the real world to the extent of inserting "on my budget") would agree as well.

 

 

 

[djn04]

I picked up an Ayre QB-9 over the weekend and I've been demoing the various 3rd party playback option.

 

At some point I think something went wrong with Audirvana and integer mode. When I try to use integer mode all I get is static. Like a white noise sound. If I turn off integer mode everything is normal.

 

I've tried uninstalling fidelia and decibel using app delete and reinstalling audirvana but the static remains.

 

Any ideas what I did and how I can get integer mode to work again?

Thanks.

 

[Jud]

wgscott writes:

 

applying the reasoning in some of the more "reductionist" comments in this and other threads would deny the possibility that jitter could be audible.

 

cf: http://hddaudio.net/viewtopic.php?id=63

 

Ouch. I think we can manage to be a lot more civil and fun-loving in whatever discussion results here. But if you ignore the bickering, the results are quite interesting for an issue on which I believe there is at least some degree of agreement in the audio engineering community (i.e., generally that jitter negatively affects sound, though I don't know if there's wide agreement on details such as the extent of the effect at various levels of jitter).

 

BTW, as an HST fan of long standing, love the sig.

 

[wgscott]

Maybe we should frame the question slightly differently: If the same code compiled on the same platform with two different compilers sounds different, then the most parsimonious explanation is one of the compilers is introducing a run-time error that the other is not. If we want Damien to spend time trying to uncover this potential bug, then don't we at least owe it to him to make sure that the perceived differences are in fact real?

 

The point of the wine article is that expectations can actually lead to physiologically-based changes in perception. There are clear physiological reasons why the differently priced samples tasted different, and those physiological changes are triggered by mental states (expectations). If you substitute speaker cable pricing for wine pricing, you can see how your ears may genuinely hear a difference.

 

[Jud]

wgscott writes:

 

If the same code compiled on the same platform with two different compilers sounds different, then the most parsimonious explanation is one of the compilers is introducing a run-time error that the other is not.

 

Possibly correct? Sure. But not the one Damien (who I'm going to presume knows more about the potential for run-time errors than we do) first mentions as a possibility:

 

Regarding explanation of these impacts, I like CG's one: the different opcodes running in CPU generate different loads on the computer PSU that goes into mains. Then the DAC is fed by the same mains...

 

In addition to mains noise, there is also RF noise that is emitted by the wires going in/out of the computer.

So bit perfect is just the beginning of the story. Otherwise any transport would sound the same...

 

Careful with that [Occam's] axe, Eugene!

 

[Terry]

I think we should all be happy that Damien is so willing to let us test his program. I for one wish we were testing very close to the end not where we are. I can hear differences in the two but I can not really say which one is the absolute best or which one will be the best when he nears pr is at 1.0. I can understand the desire to test this but not at this time/ I will remain a very interested observer as it is one of my three favorite and see where this all goes. I am a but perplexed we are having all this discussion when he has said he would be willing to enable blind testing on our end. The fact that he knows which one is which to me means nothing as we choose randomly and we can not see his reaction to our choice. Have fun and maybe iof the is going on a say .96 I will enter into the battle.