New Dichotomy - Async vs. Non-async DACs

[cfmsp]

 

Idiot_savant says: "My apologies"

 

"I thought the bridge was another box, rather than ( as it would appear ) an add-on for the PWD - this would go a long way to reassuring me about the architecture..."

 

Agreed, I also thought the bridge would be a separate box. Now Paul's comment about taking the computer out of the listening room makes more sense to me, although as I_S pointed out, if you jam some of the same type circuits (as were required in the computer) INTO the DAC, you're complicating the engineering to provide highest quality sound.

 

Alas, my interest in the Bridge module waned upon learning about the user interface. Not being able to select my own front end software is a TOTAL non-starter for me.

 

clay

 

[CG]

"I've promised not to go on about clocks over external links, but the devices you mention ( dCS, Esotetic ) use PLLs rather than the raw clock. I may start another thread at some point with some reasons as to why some companies use PLLs, but not today... since CG may be about maybe he would contribute (please?)"

 

I'm going to take a somewhat radical view here. Please, nobody take offense.

 

Talking about all this stuff is bench racing, to use an old term. Unless you're going to actually design and build your own DAC system - which could be a very rewarding project if you're up to it (I don't think I am...) - you're not going to be able to do much about any of it.

 

There's so, so many variables in any sort of audio reproduction - read the thousands of posts herein, entirely about the relatively narrow field of computer based audio - that just selecting a particular clock methodology as the basis for your choice in buying a DAC is pretty goofy. It's about like choosing a mate based entirely on the color of his or her hair.

 

When a competent DAC manufacturer suggests that you the user really ought to try out all the choices that might work for you in your system and listening context to see what you like, s/he isn't just waving his/her arms to cover up snake oil marketing of his/her product. Well, they could be, but those aren't the competent ones, are they? What they are saying is to make your choices based on what sounds best to you. Musicians try loads of instruments to find the ones that work for them. This is no different. I personally think that any manufacturer who is encouraging you as a customer to base your buying decision on your own taste rather than his or her marketing is doing the right thing.

 

I will say that there are no currently available practical technologies that approach the phase noise (aka jitter) performance of discrete fixed frequency crystal based oscillators. But, there are even huge differences between crystal oscillator designs and implementations - as much emphasis on the second as on the first. Voltage controlled crystal oscillators as sometimes used in PLLs probably fall into second place. The hierarchy goes down from there.

 

But how the clocks are used within a system really does matter. It's really easy to screw up a good clock design through its support circuitry and application. A clock with less theoretical potential well executed can blow away one with a lot of potential done badly. In an audio DAC, you also have to deal with whatever interface system there is, the noise conducted to the DAC through that interface, power supplies, the digital filter system, the linearity of the DAC chip itself, the current to voltage converter needed for most DAC outputs, and a bunch of other considerations. In a computer based system, the software used for playback makes a huge difference for a number of these aspects, even if that's an inconvenient thing to consider.

 

Finally, there is another system component that goes beyond hardware, software, and even the acoustical environment. That would be you.

 

There's loads of information available to quickly conclude that people hear differently from one another, just as they favor different characteristics in mate appeal, the foods they like, and on and on. Some of it is genetically based, some is learned at an early age, some is developed later on in life. One of my own absolute favorite sound reproducers in our house is an RCA Model 9T table radio that was built when my parents were just kids. It also happens to be a favorite of my teen aged daughter. Who knows exactly why, but I don't care; neither does she.

 

It really is true that a lot of people truly can't hear the difference in much of this, and that's no criticism. The fact that some refuse to accept that many others can hear a difference could be subject to criticism, but they're entitled to their own stupid opinion. Other people favor certain details over others. This is why listening in your own context is not just important, but critical.

 

Sorry to go off the precise trajectory for this thread topic.

 

 

 

[cfmsp]

 

wonderful post, CG.

 

As to the point that we all hear differently, I'll share an anecdote about vision that might illustrate that point.

 

Mine is poor with regards to unassisted 20/20 type performance. I'm near sighted at 6.0.

 

Whenever an opthalmologist looks at my optic nerve for the first time, they freak out, and not in a 'good way'.

 

As hobbies go, I'm a nature photographer - more so than an audiophile - so my vision is quite important to me, especially color.

 

Hang in there, we're getting to the relevant part. I have different colour palettes between one eye and the other. Probably not noticeable to the vast majority of the population.

 

Yet, when I took a color test - in which 64 very slightly different color chips had to be placed in the exact order - I scored near perfect, with my only mistakes (2) being at the very end of the spectrum.

 

I have no illusions that my hearing is as good as my vision, probably guessing it to be average at best, since I don't hear what others claim to be night & day differences.

 

About that, there's a quite funny saying that says - most every male believes that they are ABOVE average in both driving and sex.

 

I imagine there's not an audiophile in the world that believes his/her hearing to be below average (as compared to other audiophiles).

 

So, yes, we all hear differently, some better than others. And some might hear exceptionally well, even with 'damaged equipment'.

 

clay

 

 

 

 

 

[Audio_ELF]

So, if I've understood correctly, the Birdge turns the PWD from a pure DAC into a Network music streamer in the same vein as the Linn DS range (though I think it's been said tht it's DNLA nt UPnP)

 

This has been asked but I don't think answered - have PS Audio created their own control point software, or are they relying on other people's software (i.e. PlugPlayer on iPhone; Cidereo on Mac; etc.)? Certainly nothing I've seen approahes the ease of use of iTunes, Media Monkey or even FooBar 2k :-)

 

Eloise

 

[cfmsp]

 

As if to drive the point home about issues caused with multiple clocks...we changed the time zone from daylight savings to normal here in the US last night.

 

I'm sitting in a hotel room about to depart for the day's activities, wondering what time it is. My computer says 11:08, my iphone says 10:08, and the hotel clock says 12:08.

 

Guess I'll have to check the clock in the car, KNOWING that it is one hour fast, since it doesn't try to keep itself in sync (plus it is off the grid).

 

Clay, who is glad his DAC doesn't suffer such 'challenges'.

 

 

 

[bordin]

Hi Clay,

 

>I'm using Gordon's Async USB Streamlength now - in the $900 Proton

>via Grado headphones. Sounds wonderful, and it's not even broken in.

 

Today, I just had a chance to play with the Wavelength Audio's Proton Asynchronous USB DAC. First of all, my friend and I couldn't manage it to sound under Windows 7. However, it was successfully detected by Windows. Switching to OSX made things a lot easier. Just plugged the Proton and played the iTunes. That's it ! It is the second verdict for me that Mac and OSX is the environment of choice for computer audio.

 

In this setup (Oritek Preamp, Oritek X-2 interconnect cables, Wharfedale Opus), the Proton sounded very good indeed.

 

I switched to my Metric Halo ULN-2 (Firewire powered) for a comparison. The ULN-2 sounded so musical and fantastic as usual. This confirms that the transport mechanism is one critical part among the other parts inside a DAC. To get the best sounding, every component must be in concord. The ULN-2 might be comparable to the bigger models of Wavelength Audio products.

 

 

There was also a Weiss Minerva Firewire DAC in the shootouts. It sounds so great, but my personal preference is still the ULN-2's. I think the sonic "flavor" of the AKM4393 D/A chip ("warm" tonal, very well balanced, extended, crisp, articulated, spacious, dynamic & detailed) has caught my ears.

 

BTW, the ULN-2 has opened up another world to me, the Internet Radio through iTunes on OSX. Classical programs sound unbelievable ! They don't sound like Internet (AM) Radio broadcast on Windows.

 

Intriguingly, should the dichotomy be Firewire v.s. Non-Firewire ? My gut feeling would add another one at the bottom line - Windows v.s. OSX ? We need to look at the whole picture of music reproduction in computer audio(phile), don't we ?

 

[I. G.]

I don't get why DAC makers don't simply put an Ethernet port and a simple Linux-on-a-chip receiver/player into their devices. It would simply play the received files and channel them directly into the DAC chip through I2S or whatever the most direct way without so much fuss. 24/192 is about 10mbps, so I guess the basic 100mbps Ethernet network should be enough even for hi-rez audio.

 

[cfmsp]

 

 

"Intriguingly, should the dichotomy be Firewire v.s. Non-Firewire ?"

 

Firewire was on it's deathbed when I bought my ULN-2, and will always lose out to USB, except to the cognoscenti perhaps, due to the numbers difference. [Remember Sony's Betamax?] Better to enlist Async USB in the cause of putting the legacy DACs (aka dinosaurs) in their place, IMO.

 

I'd kidding, JR & Jeff! ...sort of...

 

"My gut feeling would add another one at the bottom line - Windows v.s. OSX ?"

 

That one's been decided, AFAIC. For reference; iTunes (better on a Mac), AIFF (better metadata support than .wav), and the Mac-only superior audio software/hardware providers - Sonic/Amarra, Metric Halo, Audiofile Engineering (Wave Editor, Sample Manager and soon-to-be Twilight), etc.

 

YMMV,

clay

 

[Audio_ELF]

I.G. asked ... "I don't get why DAC makers don't simply put an Ethernet port and a simple Linux-on-a-chip receiver/player into their devices. It would simply play the received files and channel them directly into the DAC chip through I2S or whatever the most direct way without so much fuss. 24/192 is about 10mbps, so I guess the basic 100mbps Ethernet network should be enough even for hi-rez audio."

Have you actually read this thread?

 

If you think about it ... this is pretty much what PS Audio are doing with the Bridge add-on to their PWD. The main problem (for audio manufacturers) is the writing of drivers and control systems. The only computer based player I know of that will talk to a Network device is FooBar 2k which has a UPnP Control Point add-on. Unless you are using UPnP (or possibly could develop MPD under Linux) you've got the issue of creating your own bespoke drivers, etc. with no guarantee that they will still work when OS X 10.7 and Windows 8 come out (or even OS X 10.6.2 and Windows 7 SP1). Thats why most HiFi companies are sticking with standard USB devices and (open source) UPnP for networking.

 

Clay later commented... "Firewire was on it's deathbed when I bought my ULN-2, and will always lose out to USB, except to the cognoscenti perhaps, due to the numbers difference. [Remember Sony's Betamax?] Better to enlist Async USB in the cause of putting the legacy DACs (aka dinosaurs) in their place, IMO. :)"

But remember how long BetaMax stayed around in the professional arena in the form of BetaCam LONG after it died in the home. Only with the advent of DV and Mini-DV did it go, and then it's still around I think though HDD and solid state recorders are replacing them in Hi Def format. (Sorry that was completely off topic but hopefully demonstrated a point)

 

Eloise

 

[Wavelength]

Bordin,

 

I am a little confused as to why the Proton did not work in Windows 7. The guy who writes all the USB drivers for Windows uses a Proton for testing. In an email he said it should link up right away when plugged into any USB port under Windows 7.

 

Are you sure you put the Volume Slider up to a listenable level?

 

Also one thing to note about the Proton is that if you are not using the Volume control feature that you should not turn it up all the way. Basically for line use you should only set it up to 90% as the last 10% is intended for Headphone only.

 

It will sound a lot better at 90% than 100%.

 

Thanks

Gordon

 

[cfmsp]

 

 

"Are you sure you put the Volume Slider up to a listenable level?"

 

I'll admit to experiencing this when I first hooked up my new Proton this weekend. The setting in Audio Midi was set to zero, when I'd never seen it set to anything other than max.

 

"Also one thing to note about the Proton is that if you are not using the Volume control feature that you should not turn it up all the way. Basically for line use you should only set it up to 90% as the last 10% is intended for Headphone only."

 

Gordon, Is there a separate Proton volume control app? I"m not thinking that YAVC (yet another volume control) is needed but I didn't see anything that I would call the Proton volume control that, e.g. should be set to 90% as you suggest above. Are you referring to the standard "Mac" volume control?

 

thanks

clay

 

PS, the Proton sounds wonderful already, but there is a clicking noise if the unit is shaken (softly). Is that normal, or is something loose inside?

 

 

 

 

 

 

 

[bordin]

Hi Gordon,

 

We tested the Proton with my friend's PC having an Asus Xonar Essence STX card installed. As I mentioned the Proton was recognized correctly by Windows. We tested both audio devices with the Sound Control Panel, the "Test" menu/button. The S/PDIF output of the Essence card sounded correctly. For the Proton, the meter levels lit up (L then R) but there was no sound.

 

There might be something with my friend's machine. So, I let him figure out later on and switched to OSX for the shootouts.

 

I'll let you know when my friend gets it work in Windows 7.

 

[Happy]

An Ethernet/Wireless (IP) interface on a DAC is straightforward. example: Sonos. It does require compute cycles on the DAC (aside from the DSP processing). There are no significant driver issues; Single chip linux devices with ethernet drivers are abundant and inexpensive. However by putting processing on the DAC one (further) needs to separate the analog and digital sections. - Is this a DAC with a computer in it; or a Computer with a DAC in it?

 

We are in a process of transition (growth, innovation) - manufacturers are currently differentiating with the 'sound' of their DAC, next will be the async connection to the computer (local USB,F/W) then will come Ethernet (seemless integration into the home network - no need to colocate computer and audio system). After that, differentiation will appear at the software level (examples ... streaming radio/satellite; per month subsciption to all music, room eq). The problem is that Audiofile sound is a small market (compared to home entertainment 5.1, home automation) so most of the investment $ go there: a good example here is Logitech's acquiisition of Slim Devices.

 

Aside:

We never mention the Logitech Transporter here; never used one but the specs/price are reasonable. Of interest in their use of a multicore MIPs device, GE, wireless, low jitter, 24bit/96K DAC, wordclock input for approx $2000. Imagine the next gen BADA with the DAC of the BADA and the processing of the Transporter.

 

/Paul

 

[Wavelength]

Clay,

 

No there is not other volume control but the system wide unit. That will change the Proton's analog volume control.

 

When you first plug the Proton in it should come up at like 20%. It is best to check the box in the System Preferences: Sound: Output to allow for control of the volume in the menu bar.

 

The clacking is normal a combination of the wiper on the battery holder and the headphone jack.

 

Thanks

Gordon

 

[Wavelength]

Bordin,

 

We tested the Proton with my friend's PC having an Asus Xonar Essence STX card installed. As I mentioned the Proton was recognized correctly by Windows. We tested both audio devices with the Sound Control Panel, the "Test" menu/button. The S/PDIF output of the Essence card sounded correctly. For the Proton, the meter levels lit up (L then R) but there was no sound.

 

Well I am a little confused... if the meters light up then would there have to be music coming out?

 

Again when you plug the Proton in for the first time the volume will be really low at like 20% of FS. You have to use the System Wide volume control to increase to a usable level. Ounce that is set the next time it is plugged in Windows will set it to the last volume control setting as long as you plug it into the same port.

 

Thanks

Gordon

 

[sandyk]

Hi Gordon

It will be due to the selected Sample Rate setting and the DAC in use. I use an Asus Xonar D2X

With my X-DAC V3 which only goes to 24/96,but upsamples to 24/192,

if I set the sample rate to 192, and play 16/44.1 there is no audio out, although the Display meters works.

There are other weird little variations on that too, when playing 24/96,with the setting at 24/96, audio outputs via SPDIF, but the meters don't show. (I just tried again)

I now have mine set to 24/96. I got caught with that initially.

 

SandyK

P.S.

I am using Creative Media Source Player, so that may also be part of the equation ?

 

[Wavelength]

Sandy,

 

Even more confused because what does any of this have to do with getting the Proton to work with Win7?

 

~~~~~~

 

Well if the X-DAC only accepts up to 24/96 then why would you try 192?

 

Why not try a real player and see what happens.

 

Thanks

Gordon

 

[sandyk]

Hi Gordon

I confuse myself sometimes too !

I was referring to this post, but perhaps it just shows that I should have breakfast and wake up properly, before I post anything! Sorry about that.

 

 

"Bordin,

We tested the Proton with my friend's PC having an Asus Xonar Essence STX card installed. As I mentioned the Proton was recognized correctly by Windows. We tested both audio devices with the Sound Control anel, the "Test" menu/button. The S/PDIF output of the Essence card sounded correctly. For the Proton, the meter levels lit up (L then R) but there was no sound.

 

Well I am a little confused... if the meters light up then would there have to be music coming out?"

 

 

 

I initially set the Asus Xonar control panel at 24/192 on the basis of having some 24/192 material. That was before I remembered the limitations of the X-DAC V3, and that it only up upsampled to 24/192. Weird things do happen with these cards, including in my case at least, the meters not working with the 24/96 settings when playing genuine 24/96 material, despite Audio coming out via SPDIF. I just double checked this anomaly.The meters do however work when playing 16/44.1 and 24/192 at the 24/96 setting via SPDIF.

SandyK

 

P.S.

I better have that coffee now !

 

[jkeny]

I think what Charles was referring to (I think you are referring to a post over at AA?) was that the jitter of the QB-9 was below the threshold of John Atkinson's test equipment, which is 120 pS. In any case, I am not aware of any measurement techniques as used by those who publish measurements (Stereophile and HiFi News) that can actually measure jitter below the 120 pS level, so I am not sure how you could be aware of any products that have been measured to produce below 120 pS of jitter. I have seen JA report measured results below 120 pS, but I assume these are anomalous, because in his own article on measuring jitter he mentions that his test equipment cannot measure below around 120 pS. I suspect this may be why JA no longer seems to give a pS value for jitter on very high end products, but tries to explain how to interpret the jitter spectrum graphs instead.

Perhaps Charles/Gordon might be better able to clear up the measurement of jitter for us.

 

Just to further add to the confusion - Charles Hansen stated on DiyHiFi about the AP2722 that http://www.diyhifi.org/forums/viewtopic.php?p=40486#p40486 "AP only specs that model to have a jitter measurement floor of 1000 psec" - this was stated in relation to a graph http://www.diyhifi.org/forums/viewtopic.php?p=40486#p40486 that was posted showing the noise of the Musiland DAC being slightly higher (2 -5dB) than the AP2722 noise. Now the figure he states is 120 ps when he's talking about his Ayre QB-9. Was this disingenuous? Maybe it should be cleared up - I already posted this same observation on AA but no response?

 

[Audio_ELF]

SandyK said... "I initially set the Asus Xonar control panel at 24/192 on the basis of having some 24/192 material. That was before I remembered the limitations of the X-DAC V3, and that it only up upsampled to 24/192. Weird things do happen with these cards, including in my case at least, the meters not working with the 24/96 settings when playing genuine 24/96 material, despite Audio coming out via SPDIF. I just double checked this anomaly.The meters do however work when playing 16/44.1 and 24/192 at the 24/96 setting via SPDIF."

SandyK ... when you are using a SoundCard with SPDIF link the computer will let you set the output rate to anything the card supports. With a USB connection (i.e. the Proton) you can only set the output rates to those the device supports.

 

Eloise

 

[sandyk]

eloise

Yes, I do realise that, just as I realise that you should set the volume level to 100% with these cards when using SPDIF OUT, and use a volume control in the preamp etc. But sometimes people momentarily forget these things,(especially at my age !) then realise later on what a stupid mistake they have made. Doesn't explain the display not working on 24/96 setting with 24/96 material though does it ? BTW, these cards don't even come with playback software like the Creative cards do, or even give information on that aspect. A much younger friend of mine is also using previous Creative Media Source Player software that came with his original sound card, for the same reason.

SandyK

 

[bordin]

From > Some thoughts on async etc on October 24, 2009 at 15:23:20

 

I'm going to take a stab at this and hopefully do it in a nice even handed way.

 

Lets tackle the USB/I2S point first.

 

There is a conceptual difference here, USB is a computer bus, it is a way to get data in and out of a computer, so is firewire, I2S is not. Processors do not have an I2S "bus" to talk to the outside world. I2S is an interface designed to go between chips on a board. It CAN be used to go between boxes with appropriate drivers and connectors, but you still need some way to connect to the computer, something has to get the data out of the computer and generate the timing signals going over the I2S interface.

 

Currently there are three methods in use for getting the data out of the computer, PCI card, USB and firewire. A DAC with an I2S or S/PDIF interface (in any of its physical transport flavors) must still get its data and timing from something connected to the computer through one of these methods. A DAC connected to an I2S interface generated by a box connected to a USB bus is not going to be any better than a DAC that had that USB interface builtin.

 

From theoretical grounds the best way to get the computer data to a DAC chip is to have low jitter oscillators right next to the DAC chip generating the timing for the chip and that clock also being used to control the rate at which data comes from the computer so it matches the rate at which data goes into the DAC chips.

 

In traditional unidirectional S/PDIF, AES/EBU and I2S this cannot happen since there is no way for the DAC to control the rate of data from the computer. The DAC has to somehow deal with the data rate coming out of whatever generated that timing. All the many varied methods that have been invented to deal with this are essentially band aids used to deal with the non-ideal topology.

 

So how DO you do it right?

 

A PCI card can get data off the PCI bus at whatever speed it wants so it seems an ideal way to do things right. But that means putting the whole ball of wax on a PCI card, sitting inside of a computer, usually powered by the computer's power supply. There are a lot of engineering hurdles to overcome to get really good sound with this method.

 

The PCI card can also be used just as a digital interface, but then you need some method for getting the data to the DAC box. If you use I2S, S/PDIF etc you still have the problem of the PCI card generating the timing not the DAC. To do it right you would need to have some method for getting timing data from the DAC to the PCI card. This method works great and is not that hard to implement, but for some reason has hardly ever been implemented commercially. (I have done this myself and it DOES work great)

 

Both USB and firewire have both adaptive and asynchronous modes. In the adaptive modes the DAC has to adapt to the data rate coming over the bus, in async the DAC controls the timing. The async mode is exactly what we want, the low jitter clock can be right next to the DAC chips and no band aids are needed. (BTW firewire is no different in this respect than USB, most implementations use adaptive mode and a few use async. The assumption some people have that just because firewire is being used it is automatically async is not true)

 

Async USB is not just marketing BS, if implemented correctly with very low jitter local clocks its one of the best methods for achieving extremely low jitter at the DAC chips.

 

The problem is there are no off the shelf USB audio async chips available. There a few that theoretically can do async mode but they have to be programmed to do so. The manufacturers do NOT provide the programming to do this. This is what Gordon did, he spent almost two years writing the code to implement async mode on one of these chips. It is NOT easy!! Several years ago I tried this myself and gave up after 4 months of beating my head against a brick wall, Gordon stuck it out and was successful.

 

This effort he put in represents a huge investment on his part. As with any major R&D effort the payback for this has to be implemented by a slice of the price of the product sold to customers. The price of the actual hardware used to implement the async mode is quite low, its the intellectual property of the firmware running on that hardware where the value lies.

 

Then there is the rest of the DAC. One of these boxes is not just an async interface, its a high end DAC using high quality components. Most of the cost goes to other parts of the box, the DAC chips, I/V conversion, analog out stage and power supplies. I'm going to make a guess here that the reason for spending all the effort on the async interface was not to have some new marketing buzzword, but because he had figured out how to do a very good job on the DAC chips, analog stage, power supply etc and the limitations of the computer interface of existing solutions was the major bottleneck in achiveing exceptional sound. Going with async USB was one of the few methods to do it right and get jitter low enough to not hinder the rest of the design.

 

This is primarily why you see audio async only on expensive boxes, its hard to do and only people who are doing the rest of the equation very well are willing to pay the price to implement it properly.

 

There IS another way to do async USB, that is to throw away compatibility with the official audio async standard. It still takes significant firmware coding, but not nearly as bad as the official async mode. BUT you have to write custom drivers on the computer since you are in effect inventing your own custom USB protocol. If you go this route you have to be willing to write drivers for all the major platforms AND maintain them, provide upgrades when new OS's come out and provide support to end users. This is a lot of effort and most high end companies simply do not have the resources to implement this. The EMU 0404USB and that little new Musiland thingy have gone this route.

 

The HRT MusicStreamers (at least the ones anybody has seen) do NOT use an async interface, they use the adaptive mode like everybody else.

 

The one that is interesting is the Musiland thingy. It actually implements an async mode, but NOT the official one, so it requires a custom driver. They took an asynchronous bulk data mode implemented by the USB chip they use and wrote a custom driver to implement an audio interface for it. But then they messed up the rest of it by using a frequency synthesizer to generate the audio clocks rather than using very low jitter oscillators! They seem to have enough programmer resources to write the drivers, we shall see how well they do with multi-platform and long term support. They seem to be putting in the required effort for driver writing but are selling a very low priced product. We shall see whether this is economically viable.

 

The other thing I want to touch on is the AES/EBU digital interface (the XLR one). Any such interface needs to be able to pass high frequency digital signals, to do this right takes a broadband RF connector with a consistent impedance over a broad frequency range. The XLR connector is a LOUSY RF connector. There are many designs out there that are MUCH better RF connectors than the XLR and any of them would have been a better choice. As far as I can tell the only reason the XLR was chosen is that studios have miles of mic cables with XLR connectors. Because mic cables are lousy digital interconnects they chose to use a very high voltage level, 3-5 Volts so they would have some chance of having some signal left at the other end. (almost all other high speed digital interconnect systems use somewhere between 250mV and 500mV). Just think what it means when you put 5V onto a 110 ohm system, thats almost 50mA of current the driver has to provide, thats a huge amount of current switching very rapidly. That rapidly switching high current supplied to the driver chip is going to induce significant noise on the power supply traces and ground plane on the board. There is a high probability that noise is going to increase the jitter of the output signal.

 

Its one saving grace is that its balanced, if the input receiver is done right this can make it not quite as bad as it should be given the lousy composition of the rest of the system.

 

I'm not trying to say that the AES/EBU is always going to sound terrible, some companies have spent a lot of engineering talent trying to overcome its inherent liabilities. Its just that this interface could have been SOOOO much better if it had been designed on technical grounds rather than giving in to studios that wanted to use mic cables as digital interconnects.

 

I still think the best way to implement this whole getting audio data out of a computer is with a dedicated ethernet chip that can be timed by an external clock. Boxes such as the squeezebox are a step in the right direction, but still rely on computers themselves with all the issues of processor load etc. Its actually possible to implement something like the netjack protocol on a fairly simple custom chip that is actually doing far less processing than a USB receiver chip. My goal is to one of these days make such a chip.

 

There is more I want to share but this has gotten long enough so I'll stop now.

 

John S. (Who is he ?)

 

Another insight

 

[jkeny]

Now there's a knowledgeable guy, John Swenson, who's opinion I appreciate & trust - he has no commercial bias (yet?), AFAIK & his opinion has historically been well thought through and even-handed!

 

[cfmsp]

 

"Now there's a knowledgeable guy, John Swenson, who's opinion I appreciate & trust"

 

Agreed, he's one of the few reasons to read AA, IMO.

 

I referenced his posts above in another thread on CA earlier today.

 

Clay

 

 

 

 

[Wavelength]

John,

 

Basically Cypress has an interesting view on USB development. They offer (now version 3.4) a device driver that is generic. You can then piggy back onto this and create BULK mode interfaces for almost any type of virtual product you want to make.

 

The Musicland does this to create their board and ASIO driver. So in a sense you don't really need a lot of software experience. You can use the already completed Cypress code on the CY7C6801xA parts then basically write the wrapper for what ever you want to make then link the generic device driver to the wrapper and then change the name of the code running on the USB processor to match and your done.

 

The problem is that it does not work on Linux or MAC. There is also a problem if more than one product uses this generic driver that things tend to fall apart. So this is not really a commercial avenue to work against. Though it does present PC users the basis to DIY Audio.

 

Many of the Firewire products use this general means of making an async product the same way. Usually if the Firewire device came with a device driver then it probably is using some BULK mode interface.

 

The same is true of the EMU0404... though it does present the operating system with 16 different generic asynchronous interfaces for input and output up to 24/96.... it does require a specific BULK mode interface for rates above that.

 

There are a ton more like this in the PRO industry.

 

Thanks

Gordon