Actually...
If one isolates from the USB processor, and then re-clocks the signal (same approach as being used with the BBB here) then there is no compromise to using USB. Either way will produce the same results as long as the implementation is correct. No sound quality benefit from choosing the BBB method over USB.
In fact, the higher power processing going on with the BBB may be a problem if the board itslef is in close proximity to any analog signals, it is almost certain that a BBB board produces more airborne RF than the low power processor required for USB (XMOS, etc).
This is just another way to do it.
If one isolates from the USB processor, and then re-clocks the signal (same approach as being used with the BBB here) then there is no compromise to using USB. Either way will produce the same results as long as the implementation is correct. No sound quality benefit from choosing the BBB method over USB.
In fact, the higher power processing going on with the BBB may be a problem if the board itslef is in close proximity to any analog signals, it is almost certain that a BBB board produces more airborne RF than the low power processor required for USB (XMOS, etc).
This is just another way to do it.
hmmm...
That would be nonsense, and without an actual jitter measurement I would dismiss the subjective experience out of hand. Of course comparing one re-clock isolation scheme to another is not apples to apples. The only fair way to do a real comaparison would be to use the TPA stuff for both, same clocks and frequencies, one set up via Amanero and one via BBB, then of course playback software for the computer serving the Amanero comes into play, so I would suggest using Linux MPD for playback software to be as close to what is going to be happening in the BBB as possible.
Of course it is not trivial to do USB properly, especially when considering the isolation scheme, clocking, re-clocking, and I2S wiring-so perhaps subjective evals of this are somewhat flawed at this point. according to Lucian's findings, even somethign like a pin header connection on the I2S lines is enough to add considerable distortion to the waveform and the result will be increased jitter.
I do applaud Russ on the new products though: having the Cronus re align everything directly to the masterclock right before the DAC is certainly the best possible way to do this (whether for USB or BBB source) as long as the I2S lines from cronus to DAC are at minimum lengths and on coax cables. And it is cool that there is another way to do things and experiment with.
Of course, it is also possible that some enjoy the sound of added RF, or higher jitter for their occasional euphonic results in certain systems-not saying this IS what is happening, but without jitter measures it is impossible to know.
That would be nonsense, and without an actual jitter measurement I would dismiss the subjective experience out of hand. Of course comparing one re-clock isolation scheme to another is not apples to apples. The only fair way to do a real comaparison would be to use the TPA stuff for both, same clocks and frequencies, one set up via Amanero and one via BBB, then of course playback software for the computer serving the Amanero comes into play, so I would suggest using Linux MPD for playback software to be as close to what is going to be happening in the BBB as possible.
Of course it is not trivial to do USB properly, especially when considering the isolation scheme, clocking, re-clocking, and I2S wiring-so perhaps subjective evals of this are somewhat flawed at this point. according to Lucian's findings, even somethign like a pin header connection on the I2S lines is enough to add considerable distortion to the waveform and the result will be increased jitter.
I do applaud Russ on the new products though: having the Cronus re align everything directly to the masterclock right before the DAC is certainly the best possible way to do this (whether for USB or BBB source) as long as the I2S lines from cronus to DAC are at minimum lengths and on coax cables. And it is cool that there is another way to do things and experiment with.
Of course, it is also possible that some enjoy the sound of added RF, or higher jitter for their occasional euphonic results in certain systems-not saying this IS what is happening, but without jitter measures it is impossible to know.
It's not doing much though is it? (Possibly FLAC to) PCM and then PCM to i2s.
yeah
no, and certainly it appears that the BBB is a good choice for this application. My concern would be having that board in close proximity to analog circuitry. What would be the telling comparison would be an RF analysis of the BBB while processing music files vs. an XMOS or Atmel ATSAM3U2C based USB interface while processing the same files.
Additionally, I am a bit skeptical of any consumer grade computer board, which is invariably built to the lowest possible price point, being put in close proximity to sensitive audio circuitry vs. a USB interface built to higher quality standards.
But again, not trying to rain on anyones parade here, more options to try are really cool, and different approaches are to be applauded. I just think there is no evidence, or theory, to suggest that such an approach has any inherent advantage over USB done right.
no, and certainly it appears that the BBB is a good choice for this application. My concern would be having that board in close proximity to analog circuitry. What would be the telling comparison would be an RF analysis of the BBB while processing music files vs. an XMOS or Atmel ATSAM3U2C based USB interface while processing the same files.
Additionally, I am a bit skeptical of any consumer grade computer board, which is invariably built to the lowest possible price point, being put in close proximity to sensitive audio circuitry vs. a USB interface built to higher quality standards.
But again, not trying to rain on anyones parade here, more options to try are really cool, and different approaches are to be applauded. I just think there is no evidence, or theory, to suggest that such an approach has any inherent advantage over USB done right.
We have Hermes modules for both Amanero and BBB - so all options are open. 
The fact that Amanero supports external clock input makes it very attractive for the purpose.
Also of utmost importance is the clock switching scheme. This was actually one of the tougher things to get right.
We have done tests around signal integrity and as long as you correctly terminated and stacked/connected there is no observable disadvantage to using pin headers - the key is to mind return paths. We have been very careful in this regard. I did some observations with the scope using SMA, uFL, and the pin headers. The very best waveforms at the destination were achieved when directly stacking modules with the headers. 6" SMA was a very close second. uFL - while good for longer distances where stacking is not practical is nowhere near as good as direct stacking via the headers.
Still as Barrows said - there is no accounting for taste, but I know what looks good on the scope.
Cheers!
Russ
The fact that Amanero supports external clock input makes it very attractive for the purpose.Also of utmost importance is the clock switching scheme. This was actually one of the tougher things to get right.
We have done tests around signal integrity and as long as you correctly terminated and stacked/connected there is no observable disadvantage to using pin headers - the key is to mind return paths. We have been very careful in this regard. I did some observations with the scope using SMA, uFL, and the pin headers. The very best waveforms at the destination were achieved when directly stacking modules with the headers. 6" SMA was a very close second. uFL - while good for longer distances where stacking is not practical is nowhere near as good as direct stacking via the headers.
Still as Barrows said - there is no accounting for taste, but I know what looks good on the scope.
Cheers!
Russ
As far as EMI - there is no reason to suspect that it's any more for for the BBB than it is for say a USB device. This comes down to good PCB design more than how much is going on on the PCB. What I can say is having run mine now for months - I am not observing any ill effects from the BBB in my case.
What I can say is having run mine now for months - I am not observing any ill effects from the BBB in my case.
Audio filters are the most problematic. Any DSP effect that might take around 10% or more of a PC core's CPU time will be totally unusable with the BBB, and might just barely work with the latest Odroid. Using Meiro's driver and the BBB's internal hardware, rate conversion, DRC, and EQ should all be doable without much issue, and I'm pretty sure there are prebaked plugins to do that, either with MPD or Jack. But, some DSPs will just be too much for it, or too much in addition to other tasks. The CPU performance is the Achilles heel of all of these cheap SBCs, though. They give lots of IO options, but are built to low price points, and low power envelopes. Intel has been losing money per unit to gain footholds where ARM dominates, if the new teeny tiny Atom systems come to your mind as counterpoints.
As to displays, it depends on what you want to put in. HDMI are available, but you pay dearly. I2C, serial, and parallel displays of various kinds are not uncommon, but support quality, in terms of software, varies a great deal amongst them. As far as displays, you might as well consider it no different than a Raspberry Pi.
Good to know Russ, thanks! It is interesting that your observations re pin headers are very different from what Lucien has reported... although maybe Lucien was talking about pin headers and ribbon cable, and not just a stack. I would also be interested if you had investigated card edge connectors/FFC cables, with their low mass and clamping connector I expect they could perform very well for high speed signaling but have never seen any scope shots. Agree on U.FL, they can be maddening for DIY: I end up getting everything right, then carefully connecting new ones just once.
But in any case, my main point was to suggest that there is no reason that using the BBB (with really good implementation and re-clocking as you have developed) would perform at a higher level, than an equal USB implementation.
But in any case, my main point was to suggest that there is no reason that using the BBB (with really good implementation and re-clocking as you have developed) would perform at a higher level, than an equal USB implementation.
You can't really compare the two approaches directly. The BBB approach is a completely self contained audio appliance complete with UI(mpd,DLNA etc) and direct control over the DAC(I2C).
The USB approach is simpler - but not as powerful.
We support both - and cronus works exactly same for both. The audio signal quality is identical between both.
Oh also - one tested approach is to put teleporter between the Cronus and the DAC - this also works quite well! Since the time delay injected by the LVDS is constant - it really does not add any appreciable phase noise - just a fixed propagation delay.
Cheers!
Russ
I can't account for Lucien's findings (perhaps he was using ribbon) - but I do trust the engineers I consult - and the actual testing I do. You can do pin-headers badly too - maybe that was the case.
There are lots of good options - but one need not go crazy to find one.
I agree with you on the point to be sure. This is the whole reason behind Cronus. Cronus is the great equalizer.
One very practical reason the BBB is awesome for audio - is it's direct playback of DSD without the need for DoP. Direct playback of DSD makes for absolutely seamless transitions in playlists that contain lots of different sample rates and mixed DSD/PCM content. I have yet to see any USB module that handles that task as well - though some do much better than others.
Last edited:
We have Hermes modules for both Amanero and BBB - so all options are open.
Cheers!
Russ
Hi Russ, I'm going to revive my Amanero board, long been left unused after introduction of Botic BBB for I2S, for this Hermes module.
The current firmware version of my Amanero which I think latest is shown as 1.80 (with 1.57 version for Windows driver, though not relevant). Let me assure that this version is okay with the capability of external clock input.
Regards,
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.