MahlerFreak

BEEMB, I don't quite understand what you're saying, but if I get the meaning properly, I don't think this is the explanation. If you're referring to a typical PLL implementation completely losing sync, all DACs that I'm aware of will completely mute the audio. You might, instead, be referring to the PLL in the DAC adjusting it's frequency in a large discrete step to prevent buffer underrun/overrun. It does not seem likely that such adjustments would be correlated so perfectly and repeatably to the screen refresh, unless the buffer is extremely small. BTW, that kind of PLL adjustment can and will occur in any system that uses an external DAC without a separate clock sync to the source. Also as an aside, keep in mind that Peter's system uses a Firewire digital interface, so the original source clock is not located in the PC. I would not put excessive stock in Stereophile's measurements. I'm glad they do them, but what a digital audio device does with a steady state signal, when fed by laboratory-grade power, may or may not correlate well to the way it performs with musical signals and dirty power. Doing recording and analysis of the kind Peter is doing is not trivial. Most analysis tools are designed to extract a particular abstraction from a single signal (a spectrum analysis, or THD, or A-weighted noise, for instance). What Peter is doing is comparing two signals recorded at different points in time. There are reasons this isn't usually done, and reasons that Peter has had to write quite a bit of code to make it happen. But it is the most legitimate way to look at the system as a system, instead of as a collection of idealized black boxes.

BEEMB, as I understand it the graph does not actually show a waveform. It shows the difference between two waveforms from the same test file, at the same point in playback time, with different software settings. One waveform is arbitrarily chosen as the reference - that is the flat line. Any deviation from "flatness" in the other graph line indicates a difference in that waveform relative to the reference. The once-per-second "burst" in differences between the GUI vs. non-GUI waveforms strongly suggests that the difference is correlated to the screen refresh associated with updating the track time counter.

Audio_ELF, if you're really interested I'd encourage you to read the original thread, as well as the thread on Peter's forum linked off of the CA thread - this will save quite a lot of redundant discussion and explanation. At this point I'm quite convinced that Peter is measuring real phenomena, although the exact causes of those phenomena are as yet undetermined (there are suspects, but no convictions). Informed speculation is welcome

To be fair to the iTunes team, they simply have a different kind of problem than almost all the other library developers out there. The installed base of iTunes is almost surely in the 10s of millions, perhaps 100s, with a global geographic distribution. When you have an installed base that big, most of whom are "casual users", just writing the code for a feature is only the very tip of the iceberg. Testing every possible configuration and interaction, documenting the feature, translating into a couple of dozen languages or more, generating the marketing collateral, training support personnel, exposing the functionality through your API, etc, etc. When you consider that only a very small percentage of that customer base is likely to have even heard of FLAC, and add in the fact that, as Gordon says, it generates no revenue - you get the picture. OTOH, if FLAC eventually gets enough traction that even a small percentage (low single digit percentage) of iTunes customers consider switching away from iTunes because of missing FLAC support, then that represents a significant negative revenue opportunity, and the iTunes team will have to be all over it. Smaller companies that cater more to an "enthusiast" audience can afford to move much faster on leading edge developments, counting on their customer base to be more tolerant of occasional problems, missing documentation, etc, in order to get the extra functionality.

I'm strongly considering going - it's mostly a question of finalizing Summer scheduling for my family. I have lots of friends in the Bay area from my old job, so that's another attraction.

@markr, Yes, Sooloos is very cool, and preposterously expensive for what it is, which is nicely packaged but ordinary hardware, well-executed software, and an AMG metadata license. BTW, by far the most important part of that equation: the AMG metadata license. I like Muso quite a bit too - it's my current interface to my desktop Squeezebox-based headphone system - but for me it is definitely lacking in classical-friendly features, and doesn't have enough extensibility in general. It is quite similar to something I have been building for myself as a web server/client interface. I don't know what Songbird uses as the back-end DB, but for the moment it doesn't matter since the front end exposes only the conventional Artist/Album/Song style of navigation. It does have some nice linkages to online resources, which is also one of the best features of Muso - that stuff actually expands the music experience a lot more than you might think. And there are a bunch of folks building interesting plug-ins for Songbird.

"I just want to listen to music" - TimbrePitch It's funny, I agree with that sentiment completely, which is why I don't use iTunes. I tried to put together what we now call a "music server" based on iTunes about 3 years ago. My music collection is large (nearly 2K albums worth now) and eclectic (more than half classical, but lots of jazz, blues, and rock/pop too). The more music I got ripped into iTunes, the more it became an incoherent mess that made it almost impossible to find anything. I went through lots of trouble trying to use the tools that were there to help organize things, but in the end I decided I just wanted to listen to music, and went back to listening to CDs directly, for which I already had an organizational system. After trying many other different products off and on in the meantime, I finally settled on dbPowerAmp for ripping, and J River Media Center for library management. These tools in combination allow me to accomplish all of the important tasks to me - ripping, tagging, organizing, navigating, searching - with far less time and effort than it takes in iTunes. And these are tiny companies, with very limited resources compared to Apple. In my previous life, I spent lots of time on the subject of software "ease of use". One of the things we learned very early on is that this breaks down into two broad elements: 1. "learnability", the ease with which functionality is assimilated, and the "stickiness" of that assimilation next time you use it, and 2. "usability", relating to the time, effort, and repeatability involved in accomplishing specific tasks. By those criteria, I found iTunes very learnable, but not very usable - for my specific requirements, of course. I find most of the other library managers (hello, Foobar) neither very learnable nor very usable. dbPoweramp is idiosyncratic in its interface, but quite usable. J River is not as quite as simple to learn as iTunes out of the box, and it obviously takes longer to learn all of the functionality because there is so much more there. The point is, it all depends on what your personal tastes and requirements are. Thank goodness not everybody was satisfied with iTunes, or I wouldn't have a music server, and that would be a shame, because my music server does indeed now let me enjoy music more. BTW, in the final analysis, all of these products are pretty dated in their navigation paradigms, and in look and feel. For some examples of what that means, look at Sooloos: http://uk.cinenow.com/videos/2052-sooloos-distributed-by-meridian-ise-2009 or for some of the same flavor, a new one-person effort called Muso: http://klarita.net/muso.html

Hi Chris, Well, my view might be "cynical and somewhat old school", but it is supported by both my personal experience and by the known facts. I am a former CTO of a large software company, and I've had significant high-level dealings with pretty much all of the large technology players like Microsoft, Google, and Apple. I would say that Apple was, in general, the most closed and insular of the partners I dealt with, both from a business and a technical standpoint. But I don't necessarily consider that a knock on Apple. Apple's differentiation in the market comes from the simplicity and seamless interoperability of their products, which is very difficult to achieve if you don't control most of the major elements of the solution (just ask Microsoft, or use Windows . Not for nothing does Steve Jobs have a (deserved) reputation as a serious control freak. I don't necessarily agree that Apple would make more revenue by supporting FLAC, but it isn't my opinion or yours that counts. If Apple saw broad interoperability with other competitive elements in the media ecosystem as being in their enlightened self-interest, I think we'd already have seen some very different outcomes from what we're seeing now. The limited format support is just one issue. Obviously, there is no direct support from iTunes for competing music stores or services (Amazon? Last.fm?). And Apple's recent decision to encrypt the synchronization interface to the latest iPods and iPhones, and then to pursue legal action against folks who were trying to reverse-engineer the interface to keep other software products compatible with Apple hardware, can hardly be seen as a move in the direction of openness. But to the point of my previous post: why not simply start with a product which is already further along in the direction you want to go?

I notice that most of the items on the wishlists above have to do with iTunes. IMO, putting too many hopes on iTunes isn't likely to produce the results we want. To put it in context, iTunes does not generate a dime of direct revenue for Apple. iTunes exists to serve as an enabler for Apple's revenue-generating media businesses: iPod, iPhone, iTunes Store, AirTunes, AppleTV. Building the most powerful, flexible music library manager is not the primary focus. For instance, try to imagine you're the product manager for iTunes, and you're telling Steve Jobs that iTunes should support this new open format (FLAC) that is delivered only from competitive music stores, and won't play back on any Apple media hardware. How long do you think you'll keep your job? 24/96 downloads currently don't generate enough revenue to constitute a rounding error for the iTunes store; if such formats do become significant, Apple can afford to be a follower on that trend due to their dominant presence in the online music market. Apple is locked to Gracenote as the exclusive metadata provider; licensing other metadata providers at the scale of operations of the iTunes store would be very expensive, and will only happen if large segment of their customer base starts to demand it - and they'd have to break the Gracenote contract, too. And remember, again, advanced metadata that is not supported by Apple media hardware is not going to be of interest. I think a more productive line of attack is to focus on products which exist solely to be excellent music library managers. There are several such in the PC arena, most of which have covered those wishlist items years ago. And fortunately, there is now an alternative to iTunes in the Apple arena - the open-source player Songbird (www.getsongbird.com). Even though it's still quite new, you can see the kind of features you'll only get when the business model is not constrained to one media ecosystem. For instance, broader format support, and the liberal use of online resources from a variety of different content providers. And you can talk directly to the developers on their forums. BTW, I'm not associated with Songbird in any way, and don't even regularly use it myself (J River is better on PC), I just point it out as a real alternative for Apple fans.

Edited 5/7 - After rereading my original post, I am dismayed and embarrassed by its nasty tone. I am not at all negative, confrontational, or disrespectful in person, but those are all qualities of my original post. Although it is in some sense cowardly to do so, I thought it better to excise the nastiness and innuendo, and let the substance stand. I apologize to the other readers of this thread, and to you specifically, Chris. --------------------------------------------------------------------------------------------------------------------------------------------------- Well, as they say on lots of other forums, POP! Let me see if I can mediate a bit here. Peter definitely has some rough edges, and they're not helped by English as second language. And there are better things to make undiplomatic comments about than an event that is perhaps the culmination of Chris' brief career as a new-generation audio journalist. On the other hand, Peter is doing something which very few high-end audio vendors do: he's subjecting his opinions to actual measurement and analysis, and sharing that data publicly, wherever it leads. In other words, he's doing a lot of work that you might hope this site might do on its own, but does not have the resources or perhaps expertise to do. Chris is to be commended for bringing together this symposium, and I am strongly considering attending myself. I don't blame him for being defensive about the caliber of event, and the caliber of people he's convinced to attend. It's really quite an accomplishment - kudos! But I also have to say, Chris, that you don't always apply sufficient critical thinking to the opinions of the experts and vendors you associate with. The Amarra podcast is a good example: the reason cited by the Sonic people for their audio superiority was transparently irrelevant to the way most people on this site use music servers, yet you let it pass without comment. Meanwhile, you have in another context almost trivially dismissed the Blue Smoke server, without understanding the critical importance of digital filter algorithms in the predominantly 16/44.1 consumer environment. So it is a legitimate question whether the presenters at your symposium will have new, interesting, and plausible insights into the relationship between software and sound, and if so whether they'll be interested in sharing them and subjecting them to some critical discussion. There are other parts of your symposium which are obviously very interesting on the merits, such as the audio recording sections. I would say to Peter and Chris: you are very complementary, and you need each other. Peter provides technical substance that Chris doesn't, Chris provides a voice for new discoveries and information that Peter will likely never realize. As a virtual "team", you can enrich the whole computer audio experience for us.

BEEMB, if you scroll up quite a way in this thread, you'll see that Daniel Weiss of Weiss Audio, and author of those graphs in the PDF, discovered that he'd left the iTunes equalizer switched in. His second set of graphs don't show anything like the same kind of difference that the first set did. But meanwhile, Peter of XXHighEnd has been doing measurements of the actual output of digital playback systems when driven by different software environments. The initial conclusion is, that software does have a measurable effect, although the mechanism is not yet fully understood. See this thread: http://www.computeraudiophile.com/content/Its-Friday-here-so-here-BIG-one

If it is just "noise", won't a toslink connector reject it? It might induce more jitter, but it would be a good test. This won't do much, since the components are still interconnected through the ground lead of the AC mains. And if I'm not mistaken, Firewire connections may be galvanically isolated by design, in any case. This is slightly OT, but lest anybody think that noise transmission through AC mains is an esoteric consideration, it is an accepted fact of life in the pro audio community. Basically any component which has a conventional power supply design will inject noise into the AC mains; digital components have many additional noise creation elements which will contaminate the system ground, as previously noted. The noise created by different components essentially "accumulates" as they each do their part to pollute the power supply and the mains ground. In a pro audio environment with many different components in close electrical proximity, treatment of AC mains power with power conditioners like those made by Equitech and others can reduce the measured noise floor by as much as 15-20 db. That is not a minor tweak!

This is fascinating. Let me see if I can sum up what we think we know thus far, so that I can understand it. If we play back and record the identical digital signal through an identical PC-based digital playback and recording system, we consistently get a strong statistical correlation between the digital samples in our recording. If we modify something in the software portion of the playback environment, the statistical correlation between digital samples in the recording goes way down. We are assuming, for the moment, that the change in correlation represents a distortion of one playback signal relative to the other (rather than a some factor impacting our recording or comparison environment). Given that assumption, what do we know about this distortion? Two things stand out for me: 1. At least some of the distortion occurs in regular temporal patterns, and 2. the distortion patterns don't change with the content of the source audio signal. If we put 1 and 2 together, we have an indication that the distortion is, at least in substantial part, uncorrelated with the audio signal. In other words, it is the kind of distortion we commonly call "noise". Now, our computing environment is just full of electrical signals which represent "noise" relative to our audio signal. The CPU, memory bus, PCI bus, disc controller, graphics controller, and video monitor are prominent examples of subsystems that rely on "noisy" signals. Can software create such noisy signals? Yes, software does create such noisy signals; in fact, in a reductionist sense, that is how software works How would this noise make its way into our output signal? Well, the noise could impact the effective timing of the digital bitstream, by modulating the digital audio clock or "blurring" the leading edge of bit transitions. Or more drastically, large fluctuations in voltage could be interpreted as false digital samples. Or, the noise could be injected into the analog circuitry of the D/A converter. Based on what we know thus far, none of these possibilities can be rejected. How would the noise reach sensitive digital or analog circuitry? Either through direct electrical connection - signal interconnects or AC mains - or through electromagnetic radiation. Given the architecture of Peter's system, electromagnetic radiation does not seem a probable pathology - the digital interface and D/A converters are effectively inside their own Faraday shields. This would leave transmission through interconnect or AC main as a likely culprit. It might be an interesting experiment to try measuring the noise between the "ground" side of your single-ended audio output during playback, and an entirely independent ground, and see if there are differences in that noise which correlate with different software settings? In any case, as you say, this will not be easy - but you will have the satisfaction of adding completely new knowledge to the audio community

Peter, can you tell us more about the system under test here? Is the DAC internal or external to the PC? If external, are you using an internal or external SPDIF interface? The pattern of "breakup" associated with the ticking clock is strongly suggestive of electrical noise from the graphics interface leaking back through the PC's PSU, or through the bus ground, or similar ... But if you're using something like a Weiss or other Firewire interface to output SPDIF, then noise from the PSU is a less likely culprit, of course. Are you using any noise-reducing AC power conditioners or cables?

No, actually it sounded slightly brittle or glassy in the treble, and slightly congested. The differences were very slight, but they seemed to me quite consistent compared with my Weiss AFI1 as a source (both feeding the AlphaDAC). And switching to the other case seemed to clear most of it up. I suspected heat as well, but the card isn't located over a heat source, seemed no more than warm to the touch, and didn't change character when listened to from a dead-cold bootup. I actually suspect EMI more. I posted more on this in a thread in the forum ...<br />