Guys!
I'm happy to inform you that I brought the AB-11 back to life! Atmel support suggested that I should try updating firmware again, only this time without 'erase f' parameter. Guess what? It worked - leds glow, music plays
Cheers,
Marcin
What do you know? The flashy blinky worked but I got "File not validated" or something on the audiowidget ones - both Alexses and Georges.
I will try to add the erasepart now when it seems to be working...
That did it I'm streaming to it from Linux right now the leds are flashing but no sound. OK, closing in on this now. Any helpful ideas? I will test from XP as well as a starter.
Brgds
Last edited:
that's for sure.
My point was that there are many subtle mechanisms which may eventually affect the perceived SQ besides the most obvious ones.
All else being equal, IMHO/IMHE different noise and/or even different timing of the incoming signals may produce (slightly) different alterations on the output signal, which in turn may indeed result in (slightly) different perception of the reproduced sound.
I stress on the word "different", meaning different from a qualitative and not only from a quantitative point of view.
And I always stress on the words "perceived" and "perception" because IMHO this is the key point (too often overlooked by many "pure" EE). Problem is, what we usually measure (and optimize for in designs) often have only little and vague correlation with the perceived SQ. THD and noise to name a few.
BTW: talking about (in-band) noise, there's a huge difference whether it's correlated or uncorrelated (and that's obvious from what I was saying about our perception mechanisms). Relatively large amounts of uncorrelated (random) noise are likely ignored by our perception, while possibly tiny amounts of correlated noise, even if buried well below the background may affect the perceived SQ.
Detecting and understanding this kind of problems with our current standard set of measurements is extremely difficult, if possible at all. To gather a better understanding of what we're doing and learning how to design for better SQ (rather than for better more-or-less-meaningless specs) we would rather need to set-up a measurement and analysis system which somehow "mimics" our perception. But that's another story...
Oops, sorry for going way OT.
I trust what you say. But unfortunately I have different evidence from listening tests.
Playing the same file, on the same audio system, through the same async USB interface using two different laptops produced obvious differences in the perceived sound. Even using two different OSs (Linux and Windows) on the same laptop produced smaller but still clearly noticeable differences in perceived sound.
Of course we have sent "bit-perfect" output to the USB in all cases. And we did blind tests.
Thus, there must be something. Not believing in magic, differences in noise and/or timing are the only logical explanation that I can imagine.
well, yes and no.
I agree that this looks like a chaotic system, so indirect and involving so many independent variables that's likely impossible to control and design for in a predictable way.
But, on the other end, there seems to be some empirical "regularities" so that apparently some systems/software does indeed (more or less) predictably produce (slightly) better results then others.
Understanding exactly why and controlling it in a "preemptive", theoretical way would be a whole different problem... likely impossible to solve.
granted! Not to mention how much it does affect the perceived SQ...
In my little humble experience, I've come to the conclusion that in just about any audio device the power supplies are perhaps more important to the perceived SQ than the audio circuit itself!
granted.
Yet, even with all the best instruments of the world (and the required knowledge and experience to use them properly...) IMHO it would still be (mostly) blind luck to design any kind of audio device which produces a really good perceived SQ.
(problem being what I was saying before: the lack of good correlation between measured quantities and perceived qualities. Fact is, we still don't really know what we should measure and how!).
Last edited:
Ops, I forgot to say...
noise floor modulations may well be causing changes in perceived SQ, as can the characteristics of the noise itself. For instance, much more than the noise level per se, perceived SQ may depend on how much the noise is self-correlated and/or correlated to the (music) signal...
Thank you for this comment. This means, if there are no vintage digital sources like cd, dab and dvd, the needed DAC must have only inputs for USB (PC), HDMI-Audio (BD/high resolution broadcasting) firewire (Apple serial bus) and ethernet (LAN/WLAN).
Which commercial DAC products, kits and diyprojects are there in this manner?
Thank you for comments.
OK, I will continue to be on topic discussing the Open-source USB interface: Audio Widget.
I can now program it in XP as well, I have even got a few seconds of audio out of it but it seems as I have some pins on the MCU hanging in the air. The leds continues to blink sometimes and then just one of them. On other occations both leds are lit and so on. I will try to find thinner solderlead tomorrow and see if I can't get it firmly in place without causing any shorts.
But the audio dosen't play more than five seconds - then silence. Just as it looses sync or something.
Brgds
I can now program it in XP as well, I have even got a few seconds of audio out of it but it seems as I have some pins on the MCU hanging in the air. The leds continues to blink sometimes and then just one of them. On other occations both leds are lit and so on. I will try to find thinner solderlead tomorrow and see if I can't get it firmly in place without causing any shorts.
But the audio dosen't play more than five seconds - then silence. Just as it looses sync or something.
Brgds
In the interest of keeping on topic, I'm responding to this question on the grounds that any new USB interface might want to also implement other inputs to be more universally applicable, and thus reach a wider audience.
To get to the question, I think your list is wrong. Including HDMI-Audio is just as bad as including SPDIF. That's because HDMI is another push-model interconnect where the clock comes from the source, and is particularly problematic because the DAC cannot perform flow control on the data stream. I realize that HDMI is the absolute latest fad in the home theater market, and this makes it incredibly frustrating that the old, flawed design of SPDIF (and AES3) is being replaced by a new, flawed design in the form of HDMI and HDMI-Audio. But popularity is no substitute for a workable design. It's basically been proven that the best clock is internal to the DAC board and thus the DAC board must be the master clock.
Getting back to an open-source USB interface, I suggest that it might be really useful to include FireWire and/or ethernet interfaces on the same board, if for no reason other than to increase the number of people who might buy the board and thus lower the cost due to higher quantities. Each adds potential noise and complexity, and the FireWire port might be rather difficult to develop given how difficult it is to obtain documentation and experienced developers, but in principle these are all solvable challenges.
The only thing I would say is that any consideration of adding HDMI support should be canned.
Thanks, I will have a look there. I doubt that optocouplers will be welcomed by the majority of audiophiles - they not only introduce pulse jitter but also tend to not be so stable over the longer term. However my information on this latter point might be well out of date. Using an opto means also providing isolated power to the receiving end - unless you see it as the responsibility of the I2S receiver to supply power to this part of your circuit. Then compatibility becomes an issue to consider - the interface is no longer 'native' I2S.
Optos might well be suitable for the WS and DATA lines of I2S (assuming that timings can be met) but using them for the clock signal seems to me to nullify a primary reason for going to async USB - low jitter.
I'm incidentally of the view that galvanic isolation is not necessary, what is required is the reduction of common-mode conducted noise. This might well be able to be minimized by increasing the CM impedance substantially without full galvanic isolation.
True enough, but we do rather have to make the products we design attractive to end customers who want to interface them using existing standards, however flawed. If 'push' is bad (and I agree its sub-optimal) then I2S is tarred with the same brush. But what else is there for an interface such as the one being discussed on this thread - do you have any suggestions?
The whole point behind async USB (as I see it, please correct me if this is mistaken) is its lower jitter. But then separating a USB interface into two parts - USB-> I2S followed by I2S-> DAC does rather nullify this advantage does it not?
Agree.
The low jitter is provided by the master clock oscillator that is on board the DAC board. We just need a way to convey the master clock to the uController so that the uController can throttle the USB stream using async rate feedback.
In the audio-widget design, it so happens that the i2s signals are generated by the uController itself. Note that theoretically (not proven by actual implementation), the master clock (or divided master clock) from the DAC board to the uController can have jitter (from an optoisolator) at the point of entry to the uController, and the i2s signals themselves can have jitter (from an optoisolator and from uController internal divider logic and noise etc.). As far as the uController is concerned, as long as the master clock and the i2s signals are SYNCHRONOUS to the master clock, it need not be jitter free.
So Borge's suggestion of using opto for the master clock and i2s may be workable.
Of course, an alternative of using opto for the USB side between the PC and the audio-widget will be nice - but there are no such devices at USB2.0 480mbps that we are aware of (let alone the cost if available).
We have designed the audio-widget for attaining good SQ through:
1. low jitter master clock direct to DAC;
2. async out with rate feedback, especially with uac2 to enable high sampling rate (88.2/96/176.4/192) and 24/32 bit music material playing at the native sampling/bit depth - without any resampling;
3. good DAC selection and analog design.
This is NOT for casual users who are satisfied with mp3 or 44.1/16 CD quality music. This is NOT for users who want convenience and re-use of their old/existing equipment.
We want to attract users who are discerning, who listen for and appreciate good SQ, and some of whom to join our open source effort to come up with improved widgets with superior SQ at reasonable cost.
So (advertising starts here) buy an audio-widget from Borge or George and listen to it. Compare it with your existing system and give us your feedback
Alex
In the audio-widget design, it so happens that the i2s signals are generated by the uController itself. Note that theoretically (not proven by actual implementation), the master clock (or divided master clock) from the DAC board to the uController can have jitter (from an optoisolator) at the point of entry to the uController, and the i2s signals themselves can have jitter (from an optoisolator and from uController internal divider logic and noise etc.). As far as the uController is concerned, as long as the master clock and the i2s signals are SYNCHRONOUS to the master clock, it need not be jitter free.
So Borge's suggestion of using opto for the master clock and i2s may be workable.
Of course, an alternative of using opto for the USB side between the PC and the audio-widget will be nice - but there are no such devices at USB2.0 480mbps that we are aware of (let alone the cost if available).
We have designed the audio-widget for attaining good SQ through:
1. low jitter master clock direct to DAC;
2. async out with rate feedback, especially with uac2 to enable high sampling rate (88.2/96/176.4/192) and 24/32 bit music material playing at the native sampling/bit depth - without any resampling;
3. good DAC selection and analog design.
This is NOT for casual users who are satisfied with mp3 or 44.1/16 CD quality music. This is NOT for users who want convenience and re-use of their old/existing equipment.
We want to attract users who are discerning, who listen for and appreciate good SQ, and some of whom to join our open source effort to come up with improved widgets with superior SQ at reasonable cost.
So (advertising starts here) buy an audio-widget from Borge or George and listen to it. Compare it with your existing system and give us your feedback
Alex
In keeping with the nomenclature above, the USB-I2S module is not a "push interface". The clock generators on the analog board are located right next to the DAC. This means MCLK goes from the analog side to the digital while the other I2S signals go from the digital side to the the analog.
The USB-I2S module is an MCLK slave, receiving 11.2896/12.288MHz. And by means of asynchronous USB, the PC is also clock slave, even though it is the data master.
So my idea, although not yet implemented, is to use optos from AB to module for MCLK and from module to AB for I2S. Adding a bit of jitter to the clock seen by the MCU isn't such a big deal, I _blieve_. But adding jitter to the DAC is absolute taboo.
Børge
If you separate the USB and DAC into separate chassis with separate power supplies and an interconnect between them, then I2S is most likely going to nullify any advantages unless a reverse I2S feed between the two systems is added to transfer the clock from the DAC to the USB processing board.
On the other hand, if USB and DAC are in the same chassis, then cross-connecting data and clock between the DAC and data source is not going to be much of an issue. You don't really need a totally standard interconnect within a common chassis, so it's quite a different problem than connecting component stereo equipment.
I get the impression that the folks who are designing and building these USB-to-I2S-to-DAC systems know what they're doing with regard to the clock.
There should have been a standard I2S-over-cat5 definition long ago. Ethernet phys won't have a problem sending MCLK on one pair from DAC to source and then I2S (or even SPDIF now that it is synchronous) on return pair(s). But that train has long ago left the station...
My application for optocouplers is mainly to split ground loops. I don't really want PC ground = USB ground = DAC ground = amp ground = power ground = PC ground. That kind of loop will induce noise currents on the ground loop, just like any old loop antenna. And those currents will in terms set up voltage differentials on internal ground routing and in interconnects.
My application for optocouplers is mainly to split ground loops. I don't really want PC ground = USB ground = DAC ground = amp ground = power ground = PC ground. That kind of loop will induce noise currents on the ground loop, just like any old loop antenna. And those currents will in terms set up voltage differentials on internal ground routing and in interconnects.
The easiest point to break the loop should be PC-to-USB, since the data lines are differential and the power is optional. It seems like the safest choice is to not even connect the traces from USB jack for Vusb and GND.
Of course, that removes a convenient source of power, but the analog circuits, post DAC, will need some sort of boost above the minimum USB voltage anyway, so an external power source that is audio grade should be better anyway.
I personally prefer balanced audio, even with a DAC output, so that affords another opportunity to break a potential ground loop. Balanced outputs connect ground for shielding purposes, but proper balanced inputs should not connect the ground at all since the signal is differential and doesn't need a reference to ground. Thus, you can also break the DAC-amp ground.
Between these two easy options, it should be fairly simple to avoid ground loops. Designing an audio grade power supply will be less easy in comparison.
Thank you for your explanations. Unfortunately the HDMI port was called in the advertisements as the ultimate interface for both video and audio (the actually reason for using this system must actually be copy protection reasons) and thus all known manufacturers of DVB television/radio receiver stuff and blu ray (BD) player stuff use this interface together with the old SPDIF optic or coaxial port.
Therefore computer experts don't buy such components in this days and work with universal network player (media player) and professional server technology for recording/replay together with an high end audio computer set-up - e.g. from the German supplier Nenotec - go to
http://www.nenotec.de/welcome/welcome_page.html
But not all user's are experts in this respect and they are perforce compelled to use only typical consumer stuff like BD's from Denon/Panasonic or DVB stuff e.g. from dream multimedia.
This means, no USB/Firewire/Ethernet can be use - only HDMI.
If this situation is present - what is in the context of these possibilities the best solution ??
So far, I always thought that the return of the MCK from LC-Clock located near by the DAC solves all problems regarding Jitter.
Last edited:
sure it would. Problem is, this is not standard. You can not feed-back the master clock to any existing "digital source" without invasive (and possibly complex and extensive) modifications of the source itself.
Thus, if I have understood correctly what you have in mind, basically the answer to what you'd like is simply... no way.
If your goal is top-quality audio, you can NOT use any existing or future commercial device which has a digital output based on an intrinsically flawed design as a digital source.
At most, you can provide "auxiliary", secondary inputs based on the most common existing standards (that is, S/PDIF and its optical-based twin, Toslink) as a commodity to allow connection of just about any device to the audio system. But you can not expect these to provide "top-quality" audio.
For top quality audio, you have to use either slaved sources or asynchronous links.
But, AFAIK, none of the existing standards for digital audio interconnect allows for slaved source. And (again AFAIK) only two standards for async audio exists: UAC1 & UAC2. That is the ones used by this project.
Any other solution would be non-standard, thus completely useless with respect to both existing and future commercial devices.
BTW: talking about "non-standard interconnections", an IMHO very interesting, general and easy to use solution could be replacing the uC with a more powerful system directly running an MPD server which accepts audio streams from a network connection. Plenty of MPD clients already exists for just about any platform, so such a device could by easily used right away by anyone... but that would be a completely different project.
Last edited:
I think this is an unfortunate line to take, there's plenty to indicate that 44k1/16 is perfectly adequate and that a 'superior SQ' is not achievable.
To describe somebody who is 'satisfied with ... 44.1/16 CD quality music' as a 'casual user' is to denigrate the judgement of the many users and professionals who have assembled and weighed up the evidence in a far from casual manner.
Doubtless, superior paper performance is achievable, and a performance margin is desirable, but encouraging people to believe that an audible superiority is achievable is to fly in the face of the available evidence.
I've thought a few times about offering assistance to what has appeared to be a very worthwhile project but I'm certainly not encouraged to put my skills behind a development driven by ideology. To my mind the purpose of a device such as the audio widget would be to put audible differences beyond question, not to encourage further in-fighting and an overkill 'arms race' in an already confused and confusing arena.
There is also FireWire Audio. It is every bit as much of a standard as UAC. I even have 24/96 audio interfaces which work in Mac OS X without a driver, because the default Apple drivers work with the FireWire Audio standard.
Granted, designing open-source hardware based on FireWire would be much more difficult than USB. Actually, I would like to work on such a project, but it's difficult to find the time and the funding. One of the reasons I made my suggestions above is that it would be interesting to create a board that has all three (USB, FW, EN), even though that would be even harder.