Bel Canto USB Link Review

Elprior · August 24, 2009

Hi Chris,

Excellent review of the USB Link.

I've been using the USB Link with my dCS gear for several months now.

I first took a look at the dCS U-clock, but considering both were 'limited' to 24bits/96khz, I just could not make my mind into spending much more (and I have no use for an external clock).

About the sonic signature.

Personally, I find it too dry, compared to my drive, on 16bits/44.1khz stuff (since that is the only comparison I can make with my drive). Most of the legato is lost. I thought this might have to do with the stereovox cable (that I didn't like much between the drive and the converter), but tries with a bnc2rca adapter (a cheap one I have to admit) and a very good digital cable were not much successful. So I went back to the original configuration.

About the usability.

Definitely the best part of my system, very slick. Under Media Monkey, it switches resolution on the fly.

The only drawback of this is that the upsampler and converter are a bit slow to resynchronize (up to 4s). So I had to develop a small plug-in for MM to pause playback while changing resolution (I could not do it with the 'ahead on track change' and 'prebuffer' parameters). If this little script can be of any interest to someone else, just ask for it. I have asked BelCanto about this issue, but they answered me that the USB Link is slaved to whatever is asked by the player. BTW, they are responding to emails very quickly.

In the end, this little box is so easy to use that I have hard times playing music through the drive (although I find it a bit better on low-resolution material).

Elp

PS : For those who would like to go windows 7 and wonder if it will work with the link, I am about to test this very soon. BelCanto has already answered me that this should work perfectly. Nice little box.

Elprior · August 24, 2009

Hi Peter,

16bits material is transformed into 24bits, with the extra bits filled with 0s.

Apart from that, the sample rate remains unspoiled (confirmed by BelCanto, and at least displayed at expected value by dCS converter (although that does not prove bit-perfectness)).

Elp.

PeterSt · August 24, 2009

Hi Elp,

Yes, I don't expect otherwise (bit perfectness), but I wasn't talking about that. I meant that under Vista you won't be able to connect the Bel Canto to a 16/44.1 stream unless :

a. You use Exclusive Mode (AKA WASAPI);

b. The player software upgrades the 16 bits to 24 (harmless by itself).

It is simple : If Vista doesn't show a 16/44.1 device, it will resample to the chosen device. Now, Vista's resampling is anything but bit perfect.

In the end it is merely the other way around : the only means to play bit perfect (Vista) is Exclusive Mode (or ASIO), and if the player software doesn't provide a 16 to 24 bits conversion, it just won't play (it won't connect). So, the TAS1020 may convert 16 to 24 bits, but it doesn't get the opportunity to do it, because ... the driver doesn't connect to 16 bits.

IF Vista doesn't show a 16 bit connection, and I don't think it does (so, someone should really check this before it gets steamed up in here).

Peter

The Computer Audiophile · August 24, 2009

Hi Peter - First, thanks for pointing out my grammatical error.

Second, I think you are a bit off on the rest of your comments. I said exactly what I wanted to say in the article and your suggestion that I wanted to say otherwise is incorrect. Interjecting the phrase, "... that should not leave an imprint on the sound, but sadly it does" is not appropriate here. If I used such a phrase I would be obligated to say the same thing in every review because every single audio component has an imprint of some sort and I don't find it "sad" as you suggest.

I'm not sure how you came up with the idea that I, ".. have been struggeling to turn all into something which is not really negative."

My assertion that the "USB Link is fully capable of handling digital audio natively at 16/44.1, 24/88.2, and 24/96. There is no up or down sampling necessary to pass any of these sample rates to the listener's DAC of choice" is 100% correct. The issues you mention are shortcomings of the Windows Vista operating system only. Again, the USB Link itself is fully capable of everything I said although certain software or operating systems may have issues that cause them not to work with any piece of hardware in this manner.

Fortunately you and I have discussed many things off line and I don't take anything you say personally. I realize you are trying to help, but actually think you've created confusion with much of your post. I do appreciate all the knowledge and experience you bring to this site in the forums, but this time I think you are a bit off.

Have a great week Peter :~)

Elprior · August 24, 2009

He Peter,

tested ok on windows xp, and BelCanto guys are claiming the same behavior under vista.

I don't quite see why they would not have included such a test, and claim the contrary.

I can test this very easily under windows 7 (expected to behave as vista, since they are very close).

Elp.

PeterSt · August 24, 2009

Yes, W7 will be similar to Vista, although the possibility exists that 88.2 and 176.4 show up there (they planned to solve that as a bug, which this 16 bit thing is not).

If Belcanto claims a same behaviour on Vista, they clearly did not test it on Vista. Vista works totally different on this, and theoretically creates the problem for devices like this (while it is the device itself doing it).

But if you can test that Elp, yes please and I can only hope that my fuzz about this has no ground.

I don't see why Chris can't do it though. If you have the device, it is the most simple (but if you think this is a Vista bug, well, all is worthless of course).

Peter

Elprior · August 24, 2009

No problem Peter, I'll test this as soon as I go home.

I'll let you know the result, and we'll figure this out

Elp

Wavelength · August 24, 2009

Peter,

I did work with the Windows sound team and sent them a Proton to play with and they discovered the problem was in the middleware section of the audio stack not reporting those particular (88.2, 176.4) to the Control Panel interface. So that will be solved in 7 and an update for Vista will include that from what I was told.

Thanks

Gordon

Elprior · August 24, 2009

He,

I just connected the thing and here is what its reads :

24 bit, 44100 Hz (Studio Quality)

24 bit, 48000 Hz (Studio Quality)

24 bit, 96000 Hz (Studio Quality)

Still no 88200 Hz displayed (W7 RC, this is almost the final release, hope there will be improvement here).

Have to play a 16bits/44.1khz file to test it, but not sure what to expect then.

Plus, this would mean moving the tower pc to the dining room (annoying to say the least), the laptop running windows xp.

I'll be testing this, and again, will let you know.

Elp.

The Computer Audiophile · August 24, 2009

Just to make things clear for everyone. The limitations listed above have nothing to do with the Bel Canto USB Link. They are limitations of the Windows operating system.

PeterSt · August 24, 2009

Thanks. And exactly what I said. You don't need to test it, it won't play (16/44.1).

But if it plays in your situation, Vista will have resampled it (Shared Mode).

The real merits can only be tested with Exclusive Mode Foobar/WASAPI), and you will see that it won't play at 16 bits ouput (XXHighEnd will, but this is because she converts the 16 bits to 24).

Thanks,

Peter

PeterSt · August 24, 2009

Chris, I am sorry, but this is not so. There is no way 16 bits can be output to such a device, because the device improperly tells the (Windows) driver she can accept it. This is not related to the 88.2 and 176.4 bug I started to talk about myself BECAUSE YOU JUST CAN TALK THAT RATES TO THE DEVICE ... because it accepts that for sure. It's only not shown in the list.

If you know more or better, please explain.

Start with telling why the device doesn't show 16 bits for a possibility, which is something the device must tell. There is nothing strange about that, because 999 out of 1000 DACs and soundcards do. These devices, all of the exact same type, do not. If it is a Windows bug afterall that it doesn't come through, fine. But it still won't play at 16 bits output.

Please note the difference with the 88.2/176.4 bug, which won't allow resampling to that rate by Vista in Shared Mode. *That* is a sure bug, and it needs Exclusive mode to make them work at that rate (because they just can).

Yes, it is confusing, sorry about that ...

Peter

PS: I only hope the message comes through that the Bel Canto does not play at 16 bits output on the majority of computers; why or who and what to blame is irrelevant.

The Computer Audiophile · August 24, 2009

Peter - I'm not sure what you are talking about. I just conducted a test using the Bel Canto USB Link, dCS Paganini DAC, Windows Vista Ultimate 64-bit, and Mac OS X Leopard. I played 16/44.1 content and 16/44.1 content was received by the DAC as evidenced by the display on the dCS Paganini. Here are the pictures taken with my iPhone. Please excuse the quality.

<center>Windows Vista Ultimate 64-bit & Mac OS X</center> <center> <a href="http://images.computeraudiophile.com/graphics/2009/0824/photo-1.jpg"><img src="http://images.computeraudiophile.com/graphics/2009/0824/photo-1-33.jpg" alt="Bel Canto USB Link 02"></a> </center><center>click to enlarge</center>

<center>Windows Vista Ultimate 64-bit & Mac OS X</center> <center> <a href="http://images.computeraudiophile.com/graphics/2009/0824/photo.jpg"><img src="http://images.computeraudiophile.com/graphics/2009/0824/photo-33.jpg" alt="Bel Canto USB Link 01"></a> </center><center>click to enlarge</center>

JR_Audio · August 25, 2009

Some small comments added:

I also own this Bel Canto device, just for testing (not for listening). I have tested it with AP System and this device is 24 Bit 1:1 Bit-True, so all data leave the unit, as they enter the unit. 16 Bit as 16 Bit, and 24 Bit as 24 Bit, everything untouched.

The “only” drawback of the Bel Canto device is the relatively high jitter at the output, because of the adaptive mode, without any high effort in reducing the jitter. (I personally prefer a 1:1 Bit True device over some other devices that reach low jitter, with the “help” of ASRC (they have low jitter in dead, but “destroy” the original data and are not longer Bit True).

As with Vista and 88K2: If you are using either the ASIO over the ASIO4ALL wrapper to the device, or if you are using the exclusive Mode in WASAPI, you will have also 88.2 in 24 Bit 1:1 Bit true and automatic sample rate change (Vista SP2 and J.River MC14)

Juergen

Elprior · August 25, 2009

Hi Chris,

weird result indeed.

I am told by BelCanto that a 16bits signal is transformed into a 24bits one with the extra 8bits filled with 0s.

I would have expected the Paganini to display 24/44.1 instead of 16/44.1.

I'll re-test this with the Delius and the Purcell, but am pretty sure they are both (without being connected to each other) telling 24bits input words.

Do you think the Paganini is "kind of" detecting the 0s ?

Elp.

PS : what a nice stack of electronics you are displaying on the picture : BelCanto / dCS / Berkeley ... very nice indeed.

JR_Audio · August 25, 2009

24 Bit out of 16 Bit in

It depends on the setting of your playback software and operating system. In Windows XP, without ASIO4ALL, and in Vista without exclusive WASAPI, you will have 24 bit out of a 16 bit input (and also not bit true). In OSX, when you match the sample rate of the input to that of the MIDI Audio setup, you will be bit true, means 16 bit comes out, when 16 bit comes in.

Juergen

Elprior · August 25, 2009

Hi Juergen,

I'm pretty sure that is not the goal of the BelCanto Link, that is to be used through either ASIO4ALL or WASAPI.

The intend is to get this small box connected, and go for bit perfectness.

Plus, this is not what BelCanto explains when asked about.

They told me that it would be outputing 24bits word for 16bits input, but with the last 8bits full of 0s, and the remaining being the original 16bits untouched.

I don't think Chris was using the WASAPI during his test (see pictures above), did you Chris ?

Else, what's the point at telling this is as easy to use as just to plug it ?

Elp.

PeterSt · August 25, 2009

Dear Chris,

I am staring at your last post for over 90 minutes now, and luckily just some backup from Erp came in, which now drives me to answer anything I don't know as off right now.

...

...

:-) Ok, here goes. First off, I think it must be "some" 100% you did not use Exclusive Mode here. Or in other words, you can't have used a WASAPI based playback means which additonally to it being that, works in Exclusive Mode. The most easy to use - and to trust on this is Foobar with WASAPI plugin (which you need to select for output), and if you do so, you will see that it won't play, unless you set the output to 24 bits (default is 16 or the last you ever set).

Side note : If you see for your 64 bit a 16 bit output setting for the Bel Canto (see Elp's earlier post) then things are different. This IMO can be so because 64 bit drivers are different from 32 bit drivers).

Now, not assuming the latter, you will see that Foobar only plays at 24 bit output ...

Next things are just guessings, which Elp already did for me : it must (or should or can or ...) be so that the Paganini sees that it is 16 bits only what it is receiving (long shot, because I wouldn't know how it can see that), which physically may be very well the case, assuming that Foobar just padds to 24 bits, hence leaves the additional byte at zeroes (which literally is not true, because the 3 byte word will shift one byte, and it is another byte which turns into zeroes, but never mind this at this moment).

The truth on this long shot can be tested by using XXHighEnd by setting "DAC Is" to 24/96 and "DAC Needs" to 24 bits (not 32), and attenuate the volume a tad. This will actually utilize the 24 bits and it will force the Paganini into thinking that it receives 24 bits. If it still shows 16 bits in this case, something very different is going on, but let's put that aside for now.

Assuming you won't go into the trouble of the latter (use XXHighEnd to try), it leaves us with

a. What happens at the Paganini side, showing that it receives 16 bits (leaving in the dark whether it ever will see 24 bits when the things are tweaked as should (XXHE);

b. What this will be worth for any other DAC behind teh Bel Canto.

No matter what, and when my assumptions are correct so far, it must be the Paganini making something of it ... somehow. The "somehow" I denote as "officially wrong because confusing", but that is not the subject here.

The other scenario : Shared Mode.

Because it can be expected that you didn't specifically try WASAPI Exclusive Mode, you must have been using one of the settings as shown by Elp. 24/44.1 would be the most logical that being the closest to 16/44.1 which is what you want. The closing part is the same as from the before scenario : The audio words sent out are physically 24 bits, but since one byte is zero always, the Paganini says it's 16 bits only.

Right now I can't think of more, and I realize that my long shot is about the Paganini discovering to receive 16 used bits out of 24 physical bits, and I don't believe this can happen. Or ... Note that this can only happen when the hardware detects that there's just no low level resolution after x number of received audio words, which indeed would be something I'd dare to decide on myself. In order to understand this, again think of the shifted byte I mentioned. Thus, it is not the loudest byte which is zeroed at padding, it is the softest byte, hence the one which brings the real 24 bit resolution. If that is always 0 after a first signal is detected (and say for 1 second after that), it is the most hard to believe that this lowest byte is zero by coincidence. Conclusion : 16 bits really (which out of all is true of course !).

But if this is (all) so, the Paganini will really be the only one acting like this, and it is just a coincidental "bad case of test equipment".

Lastly :

<cite>I am told by BelCanto that a 16bits signal is transformed into a 24bits one with the extra 8bits filled with 0s.

I would have expected the Paganini to display 24/44.1 instead of 16/44.1.</cite>

This is the confusing part, because it will be true. So, on one side this kind of would proove that the Paganini uses its own intelligence (if this would be happening, read on), but on the other side this part of the game just doesn't come into play. Why ? because there is no way 16 bits output will connect to the driver, be it a Windows problem or other. So, funny enough all manufacturers will tell you this, but apparently they all did not try on Vista WASAPI Exclusive, which is the only mode which tells the real truth and merits because in that mode resampling is just not possible, and only playback software can do it.

Ask Steve N. and he will tell the same as Bel Canto told you.

Ask Gordon, and I don't know what he will say. The only thing I know is that he told me enough to solve the problem for XXHE. By now he too may scratch his head. But I guess we'll soon find out.

Sorry for the long post, and Chris, please let me know where I am wrong, may be wrong, may be right or any other option you may think of yourself. Btw, this is not about being right but about getting these devices to work for everyone without them causing resampling (which one might not be aware of).

Best,

Peter

JR_Audio · August 25, 2009

What means 16 Bit?

If I am sending 16 Bit Data on a 24 Bit Audio-Bus (SPDIF / AESEBU) or TAS1020 USB Device, and if the system is bit true, than I receive the same 16 Bit at the end and all other Bits are Zero (I do not need to fill this with Zero, they are originally zero). So my AP System indicates Bits 17 to 24 are unused and they are zero. If I would send 16 Bit Audio via Wave Out or Direct Sound out to the Bel Canto, I will have activities of all 24 Bits, so not longer bit true. But Bel Canto has not to fill in the Bits 17 to 24 with Zero, on a 24 Bit Audio-Bus, they are already zero, when not used.

Juergen

Elprior · August 25, 2009

Yes indeed.

We consider 24bits instead of 16bits (with 0s on extra bits, ... blablabla) to be harmless (am I right ?), and not as being a huge violation of the 'bit perfect' predicate.

That's also why Peter and I can't understand the Paganini saying 16 instead of expected 24 value.

Chris, we desperately need you on this one.

I agree with Peter : this is about understanding how it will end up with windows (vista/7).

Elp.

PS : excerpt from the mail with BelCanto :

<cite>

It is bit perfect and transmits at the native bit rate-in 24 bit mode but with no upsampling of any kind. 16/44.1 is transmitted at 24/44.1 but the last 8 bits are 0s with the original 16 bits in the 16 MSB positions.

</cite>

PeterSt · August 25, 2009

<cite>We consider 24bits instead of 16bits (with 0s on extra bits, ... blablabla) to be harmless (am I right ?), and not as being a huge violation of the 'bit perfect' predicate.</cite>

Totally harmless, and when read back and transferred to 16 bits again, "bit perfect" will show.

On a complete other matter, when 16 bits could have been processed while it takes actually 24 because of the architecture (I call this "24 bit-only" devices) there's unnecessary processing in the DAC (theoretically !). Depending on the further design, this may make a difference in SQ and the analogue stage.

Compare this with more normal devices, which indeed process 16 bits when 16 are output to them, and which "process" 32 (but throw out the (nulled but not needed so) LSByte) when 24 are output to them. So, an "also 16 bit" device, runs leaner when it's fed with 16 bits only, and runs as lean as can be at 24 bits, because it won't process the 32 bits needed for the communication, (it can't use it ever; see the difference with the 24 bit-only device, which *can* use the padded bits and it won't know the difference with nulled or not -> there's just no low level resolution appearing at the output).

Peter

Wavelength · August 25, 2009

Peter,

<cite>On a complete other matter, when 16 bits could have been processed while it takes actually 24 because of the architecture (I call this "24 bit-only" devices) there's unnecessary processing in the DAC (theoretically !). Depending on the further design, this may make a difference in SQ and the analogue stage.

Not true... dacs don't really know what they are getting. In I2S because of the way it is formatted there is a total of 32 bits per channel. All the most significant information is padded with 0.

Therefore no additional processing is done. The state machines in dacs treat the entire sample the same way every time if it's 16 or 24 bits... because as we know not all the data sample is used and therefore even with 16 bit data not more than 14 is usually used.

Chris the reason the dCS picks this up as 16 bits is because it will see that only x number of bits are coming through. Actually the BelCanto is sending channel information saying it is 24 bits as instructed in hardware mode on the CS8406. But the dCS looks at the chain of data and does not see any bits changing in the upper 8 bits of the 24 bit data and therefore assumes it is 16 bits and displays as such.

Thanks

Gordon

labjr · August 25, 2009

From what I read in Stereophile May issue, John Atkinson wrote that the M-Audio Transit sounded no diffferent than the Bel Canto. Even at high sampling rates.

There's also strong competition from Musiland which, I believe uses their own asynchronous code and does up to 24/ 192.

PeterSt · August 25, 2009

Thank you. But but ...

It seems that you are projecting your vision on the "24 bit-only's" as I describe them, while I put it some other way around : a 24 bit DAC, also being able to process 16 bits (the DAC box as a whole of course) can be fed with 16 bits only and works. It doesn't need padding to 24 ot 32, 16 is just sufficient. At least on the player and driver (PC) side, this processed 16 bits only, and this is more lean (it just needs twice as less CPU cycles at the PC side).

While I think this is true, I also think on the DAC side similar might happen, thinking of the current surge needed there. If you say, in this case, i2s transfers 32 bits anyway - then of course on the DAC side nothing changes opposed to 32 bit padding on the software side ... In that case, still the software side operates more lean (FWTW).

This latter opposed to the "24 bit only" which just needs padding to 24 bits always.

<cite>But the dCS looks at the chain of data and does not see any bits changing in the upper 8 bits of the 24 bit data and therefore assumes it is 16 bits and displays as such.</cite>

Stupid question maybe, but is this because you know, or because this can be the only explanation (not different from what I said) ? In either case Gordon, do you also know what actually happens on a Mac ? I mean, as far as I'm concerned - and not knowing anything much about Macs, there the 16 bit input to the Bel Canto can just work, and the problem is a Windows problem only, no matter the actual origine.

Or is a tricky explanation applicable there too ?

Thanks very much,

Peter

Elprior · August 25, 2009

Sad news, on W7, all I can get out of the BelCanto Link is 24bits/96khz (as monitored by my dCS dac), whatever the file I may be playing (16/44.1, 24/48, 24/96).

This little box is becoming useless (and very expensive) then.

I'm emailing BelCanto right now to enable its true power again (hopefully) !

This is ruining my night...

Elp.

Bel Canto USB Link Review

User Feedback

Recommended Comments

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites

Share this comment

Link to comment

Share on other sites