Bel Canto USB Link Review

PeterSt · August 26, 2009

Hi Elp,

No ... I don't think so. You (hopefully :-) made the mistake of using Shared Mode, and exactly every soundcard etc. would show the same;

First of all 24/44.1 and 24/48 can work too, if only you set the output in the device's properties - Advanced to that respectively, unless the dCS can't dig that or needs a manual setting to accept it, then you must switch that along accordingly.

To get around the strict output as per that setting in W7, use a WASAPI Exclusive Mode player. If the dCS accepts it, you will be able to play 16/44.1 (converted to 24/44.1 which is harmless), 16/48 (same), 16/88.2 (same), 16/96 (same), 24/44.1, 24/48, 24/88.2, 24/96.

Having to use such a player is nothing special or a negative. Otherwise you'll just have no bit perfect output, as with all soundcards/DACs. There's really no difference.

Great that you took the effort of testing it, but try to finish it off and avoid sleepless nights !

:-)

Peter

Elprior · August 26, 2009

He Peter,

thanks for the answer, I'll certainly give a WASAPI player a try.

In my perfect world, I would have sticked with MM (including my customizations) but there is no WASAPI plug-in to be found (one for winamp that is applicable, but said to not be bit-perfect by its author).

Anyway, I'll give Foorbar or XMPlay a try, to check this.

What I find a bit odd, is that I didn't have to go the ASIO route under windows XP to make the Link work ok.

Maybe I was mistaking then, but at least the sample rate was displayed correctly by the dac.

I'll let you know if you saved my nights ;-)

Elp.

PS : yep, the dCS locks to new resolution on the fly and it eats anything (even dsd, though on separate ports) up to 24/192 (in dual aes only) (considering the price, that's a minimum feature I would say).

PeterSt · August 26, 2009

Ah, ok. But that will save your nights allright. One thing :

XMPlay is not the means to use for this, because it allows Shared Mode just the same, and that is not under your control. In fact (at least the last time I looked at it) everything XMPlay can't do (and the Bel Canto really would be the first example of it) is turned into Shared Mode, and next it says nothing (and you can't see it's in Shared Mode, unless you really know what to look at etc. which this is all just about (a tad too difficult for some normal human beings :~)).

The only reliable means I know are Foobar and XXHighEnd because they both don't allow Shared Mode (or anyway from Foobar I prooved that myself (IOW it's not common knowledge AFAIK)) and from XXHighEnd I know of course.

Might you try XXHighEnd for it, set the "DAC Is" to 24/96 and "DAC Needs" to 24 bits (Settings Area). If you want you now can also easily check the 88.2 which just takes ticking the "Double" (with or without Upsample) checkbox in the main area (at the left).

Good nights of sleep guaranteed (with Foobar too), but have a nice wine in advance and enjoy the listen (Foobar mwah, haha).

Peter

PeterSt · August 26, 2009

What I find a bit odd, is that I didn't have to go the ASIO route under windows XP to make the Link work ok.

Maybe I was mistaking then, but at least the sample rate was displayed correctly by the dac.

No, you were not mistaking, and this is the exact reason why I told earlier that Vista works completely different;

In XP you will receive the sample rate (by KMixer as how it is called there) the file denotes. In principle !

Only when another file is already playing (could be a coincidental ding-dong, you've got mail") that takes preference, and you could end up at 8bits/8KHz. So, in XP counts : first come first serve, and the first denotes the bit depth and sample rate. In normal circumstances that will just be the bitdepth/sample rate from the file you play.

In Vista all is hung up to the rate you set in that Properties-Advanced screen. Although Vista is relatively new, this is from the middle ages by now, because all the various file formats from today make this the most awkward job for the pilot there is. It's just no way of working. So, imagine a player that auto switches sample rates when needed and as denoted by the files (like XXHE does) then without notice Vista starts to resample the lot which is never what you'd want. When the player does not auto-swtich sample rates and all (like in XXHE you can switch this off) you are all the time going to that properties screen to adjust, noticing that 88.2 and 176.4 are not even allowed, which just stops all.

IOW, this just (ALL) doesn't work at all, but who knows that (this thread is a nice example of it, I think).

According to Microsoft (or better, our AmirM, former head of MS audio development) all is solved by Exclusive Mode.

And it is. It is a bit sad though that all existing software has to be completely rewritten for that, and in a development area which isn't one of the most modern.

MS herself always said that WMP wouldn't allow for Exclusive Mode, because it is against the principle of being able to hear your email coming in, during audio playback.

Yeah, the world is almost turning backwards.

XP was NOT better, because it did not allow bit perfect playback, unless with ASIO or Kernel Streaming.

Vista/WASAPI does, and under Exclusive Mode it's guaranteed. Kernel Streaming doesn't exist anymore (offcially) and WASAPI exceeds latency times of ASIO by far (towards the good side). The effect ? go have a listen ...

Peter (sorry to be a tad offtopic)

Wavelength · August 26, 2009

Peter,

<cite>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).

Take a look at any data sheet for I2S and you will see that 64 bits are sent to the dac all the time. There are 32 left and 32 right and because of the way it was constructed you can put 1 to 32 bits active on each channel. The thing is that the dac has no idea.

While true a single bit variation will draw less power than say a 24 bit variation... but that could be said true for any data stream. There would be no difference though playing a 16 bit stream through a 24 bit dac than a 24 bit track with the same data as they would look identical to the dac's structure.

In regards to the dCS, I am only going on my usage of the CS8406 part in hardware mode. This is the same controller BelCanto uses in their design.

Peter, I also know PC's really well. I have some 5.4M I designed in the field including many bios's, mother board design, power supply even monitors (suck). I wrote 135 applications for Windows and over 64 different board level products.

With Vista/7 there is less of a difference than MAC in the Audio Architecture as there was with XP.

Thanks

Gordon

JR_Audio · August 27, 2009

dCs Bit Indication

Yesterday I was at the German HiFi magazine “Audio” and have had also the chance to play around the actual dCs combo with USB input. I have had my notebook with me with XP (SP3) and Vista (SP2). The dCs indicates exactly what I was sending in. Indicating 16 Bit, when I play 16 Bit files and indicating 24 Bit, when I played 24 Bit files. So nothing wrong with that.

As I told above, I own also the Bel Canto USB Link 24 96 and this is 100 % totally transparent, aka 1 :1 Bit True, so when you have the wrong indication in the dCs front panel, while you using it directly or via the Bel Canto Link, the fault is in you Software Player (and settings).

PS: Neither Media Monkey nor Winamp allow 1:1 Bit True Playback natively, because they both are missing the exclusive WASAPI Mode under Vista. Direct Sound Out and Wave Out aren’t Bit True natively no matter what software you are using. I am very happy with J.River MC14 or you can use also Foobar with a correctly working WASAPI out Plug-In.

Juergen

Elprior · August 27, 2009

Peter, Juergen,

Hard pressed to find free time yesterday, I just gave the ASIO mode a try on windows XP using Media Monkey (laptop, far easier to move than the w7 beast).

As you both said, this moved the play to bit-perfectness.

Indeed, my dCS stack (older version than what you tested Juergen) now indicates 16/44.1 when I play such material... interesting. I realize I have never listened to my music in good conditions so far.

Now, and I expect it to be an ASIO fault, you can not touch anything while this is playing (unless you like when the sound cuts). I mean, playing with ASIO parameters cuts the sound (understandable), but moving forward in the track does too (ugly), not to mention changing from one track to another one (automatically, or manually, with gapless option checked) (really ugly too). I can't say this is a much user-friendly experience Hope this does not apply to WASAPI exclusive mode.

Anyway, thx a lot for your answers.

I think there should be such a tutorial on CA that clearly states how to reach bit-perfectness. Is there ? if so, please don't hurt me...

Elp.

PS : I'll try and compare XXHE and Foorbar in my rig under w7.

JR_Audio · August 27, 2009

“Japanese” ASIO

I guess you are using the “Japanese” ASIO in Media Monkey, but these plug-in (also possible in Winamp) is faulty. You can tweak here or there, but at the end, the chance that you will be happy is low. You should try foobar with ASIO out Plug-In (but on some machines also not totally error free (on mine it is)) or J.River MC14 which offers everything you will need in the windows world.

PS: I also guess that a lot of people are not playing back bit true, for example Windows Media Player and iTunes for Windows can’t do this, but if you are happy with this, it is also OK, no problem with that. But you are right, there should be some sort of step by step instructions, how do get Bit Perfect Playback in XP and in Vista.

Juergen

Elprior · August 27, 2009

Yep, I'm using this one along with ASIO4ALL (which double the opportunity of cuts, in case you are too curious).

<cite>

You should try foobar with ASIO out Plug-In (but on some machines also not totally error free (on mine it is))

</cite>

What do you mean by <cite>not totally error free</cite> ?

So in the end, for correct support of both ASIO and WASAPI exclusive mode, I end up with this choice : foorbar, JRiver or XXHE. Will that fix this seriously annoying cuts thing ?

Elp.

PS : btw, any idea why ASIO4ALL is required ? Is it not supposed to be supported by the Link directly ?

PeterSt · August 27, 2009

any idea why ASIO4ALL is required ? Is it not supposed to be supported by the Link directly ?

No, only Firewire connections do that (if supported, but I guess all do).

For fun, you could try this http://www.usb-audio.com/ which is an ASIO implementation of USB (not free, but there's a trial with bleep in it). I doub't this will work for the Bel Canto though.

I end up with this choice : foorbar, JRiver or XXHE. Will that fix this seriously annoying cuts thing ?

I say Yes. But there may be more ...

Was it you who said something about "the synchronisation takes long with the Bel Canto" ? anyway, someone said that, and maybe it is related. So, this is about automatically detecting the sample rate offered, and when the communication isn't correct regarding this, something nasty might happen (and this is prone for skipping during playback). I can't tell about Foobar or JRiver, but in XXHE doing so (skip etc.) completely reinitializes the device, and actually there's no change with starting from te beginning. Of what I saw off it, Foobar does this correct too, but I didn't explicitly test it. Going from track to track (gapless) does nothing in XXHE because all is in memory and the audio engine doesn't know about tracks as such (unless the format changes, then the device is re-initialized).

HTH,

Peter

PeterSt · August 27, 2009

Hi,

The dCs indicates exactly what I was sending in. Indicating 16 Bit, when I play 16 Bit files and indicating 24 Bit, when I played 24 Bit files. So nothing wrong with that.

As I told above, I own also the Bel Canto USB Link 24 96 and this is 100 % totally transparent, aka 1 :1 Bit True, so when you have the wrong indication in the dCs front panel, while you using it directly or via the Bel Canto Link, the fault is in you Software Player (and settings).

This confuses me, and maybe others as well ... I mean, I am not sure what the real message is in the context of, well, the fuzz I created;

My first question could be : is this about the same dCS Chris used ? (I think I read later in the thread about different versions ?).

If so, was Chris using a faulty software player ?

If so - or if not so (confused) is what I - and later Gordon told about the 8 bits being 0 and detected as 16 by the dCS not true ?

Or maybe better : what is the conclusion of this all ? that the Bel Canto doesn't moles bits (regarding virual bit perfect) is without doubt (from the start), so it is only about when / where it can be used bit perfectly. The answers to that are quite known also. But (and I quote again)

The dCs indicates exactly what I was sending in. Indicating 16 Bit, when I play 16 Bit files and indicating 24 Bit, when I played 24 Bit files. So nothing wrong with that.

It can't be as simple as this, and is therewith confusing (well, everything in my eyes). Two argument from my side :

1. With Vista Shared Mode there is no way you can input 16 bits to the Bel Canto;

2. With Vista Exclusive Mode there is no way you can input 16 bits to the Bel Canto.

So maybe you can elaborate a bit on exactly what you tested ?

Excuses in advance if I overlooked it.

Peter

Elprior · August 27, 2009

Hi Peter,

yes I did say the synchronization had a cost with the BelCanto Link.

But, this is under the circumstances of using MM, and changing the resolution (from 16/44.1 to 24/48 for instance).

And of course, it takes time at the dCS level, which reload part of the its internal software I believe (roughly 2s are spent by the dac and even 2s more by the upsampler, if coupled). That's why I had difficulties departing from MM that I had customized to wait until the dCS is ready to rock.

According to BelCanto, this has to do with the software, the Link being slaved to whatever it is asked to do.

As I see it, changing resolution must have a re-initialization cost somewhere in the Link, but that's ok.

Others dacs (than the dCS) may handle this synchronization quite faster, and thus be more transparent.

As for the dCS displaying 16/44.1, this is my case too now that I am using ASIO, with a version different from the one displayed by Chris. A clue though : the dCS takes 0s to display sample rate, when it takes 1 good second, to display the bits depth. Maybe that has to do with the detection, or maybe not. Juergen might answer the question, since he is able to analyze the bits train.

Elp

JR_Audio · August 27, 2009

ASIO4ALL, Bel Canto, dCs,

ASIO4ALL is necessary to have natively access to the sound card (in this case USB device) without any driver and, most important, to bypass the Windows Sound system. This works in XP and also in Vista, but in Vista you can use also the exclusive WASAPI mode instead. And to have access to the ASIO4ALL Wrapper, you need software with an ASIO out.

Foobar: Some say, that the ASIO settings are resetting from time to time. I have heard this from some users, but on my computers, it runs fine. Sorry for repeating so many times, please try J.River MC14, witch has ASIO Out and WASAPI Out already build in, and you can adjust the behavior for start, stopp, skip, scan, everything. I am using exclusively FALC Files and have no problems, on a lot of computers.

One other issue: The Bel Canto is slaved by the playback software, so the bel canto needs only two blocks to synchronize, so this is no problem.

With the dCs it take a while, to synchronize, so you can’t go gapless from one sample rate to an other. So I would take 0.2 Seconds gaps, when skipping, (this is fast enough), and if you have a live album, where you need gapless, this is no problem, because this will be in one sample rate and also you will continuously let them play.

@Peter: In Vista SP2 I am running J.River MC14, set to exclusive 24 Bit output WASAPI and this works perfect with the Bel Canto and with the dCs, 16 Bit in – 16 Bit out, 24 Bit in – 24 Bit out. It is important to set J.River to 24 Bit out, because internally it works with 32 Bit in order for volume control or Reply Gain function, so without setting to 24 Bit it will not work in exclusive WASAPI Mode with the bel canto.

dCS: I was using the Puccini U-Clock and the Puccini CD/SACD Transport, so slightly different to that of Chris, but I was using only the digital filter and D/A part of the transport. And again, the Bel Canto is switching sample rates very fast, but the dCs really need some time.

Juergen

PeterSt · August 27, 2009

@Peter: In Vista SP2 I am running J.River MC14, set to exclusive 24 Bit output WASAPI and this works perfect with the Bel Canto and with the dCs, 16 Bit in – 16 Bit out, 24 Bit in – 24 Bit out.

Sorry to be so thick Juergen, but if you set the player to output 24 bits, the DAC at the other end should receive 24 bits. But in one line you say functionally " ... and when I play a 16 bit file the DAC indeed shows 16 bits".

... which comes down to the dCS recognizing that 8 bits are zeroed always.

True ? yes.

But the Bel Canto still doesn't accept 16 bits.

It is important to set J.River to 24 Bit out, because internally it works with 32 Bit in order for volume control or Reply Gain function, so without setting to 24 Bit it will not work in exclusive WASAPI Mode with the bel canto.

... and allow me to again find this confusing. You are not setting JRiver to 24 bits because otherwise the volume control etc. won't work (properly), you are setting it to 24 bits because the Bel Canto doesn't accept 16 bits. Yes, you seem to say that in the end, but what is the first part for ? unrelated, I would say.

We are running in circles now.

Additionally, and not to confuse further more, but because I KNOW ... despite what may have been said about "I2S outputs 2 x 32 bits always etc" (response from Gordon) that confuses just the same. I tell you :

When a player outputs 16 bits, it outputs 16 bits and not 24 or 32. Allow me to KNOW, because I write that software.

When a player outputs 16 bits to a 24 device that needs padding to 32 bits, I STILL output 16 bits and that works (in the 16 bit domain). There are 16 bits transferred over the cable in that case.

I can NOT output 24 bits to such a device, because then it will NOT work, because nothing padds for it in that case. Disclaimer : but it sure can exist that devices padd themselves. But, if they don't they don't hence fail, and thus the player *must* output 32 bits which always works. It is the driver which tells the possibilities here.

When a player outputs 16 bits to a device of which the DRIVER tells it needs 24 bits, I can NOT output 16 bits to that device, because the DRIVER rejects it in the first place.

When a player outputs 24 bits to a device of which the DRIVER tells it needs 24 bits, I can NOT output 32 bits (padded) because the DRIVER rejects it in the first place.

On a side note : do not look at anything else but WASAPI for this, because anything else may change the stream into whatever is desired, and at the PC side it will be arranged for afterall, though behind the player. In WASAPI this is not the case, because just nothing is there behind the player. So, without analysing the stream (or other means to draw conclusions) you're in the blind. So, more direct to the play buffers than WASAPI does not exist, unless you are the programmer of the ASIO API or Kernel Streaming on XP.

So, where does this leave us ?

It looks like everybody seems to understand, but me. That is, for me still one question remains :

Does the Bel Canto accept 16 bits input under a Mac or not ? 16 bits are 16 bits; see above.

Peter

JR_Audio · August 27, 2009

Running in circles

We are running in circles with questions and answers, so I just want to answer some last points:

Mac and Bel Canto: I have tested the Bel Canto with OSX Tiger and Leopard and both work 1:1 Bit True, what goes in, comes out.

Padding: As soon as a digital audio bus is running, there are all data zeros up to the bit width of the device. So if you took a spdif transmitter (like the one in the bell canto) and supply them with master clock (system clock) and l/r clock, but without any digital data at the input, this device sends out 2 x 24 bit zeros.

So when the player plays back 16 Bit data, he just fills in this 16 Bit and left the other 8 untouched. So with the AP (and the dCs, RME Digicheck, iZotope Ozone and also Wavelab) I see 16 Bit in Use and 8 Bit unused. This is Bit True. The bus is still 24 Bit, but only 16 Bit are used, when only 16 Bit comes in.

And when setting in J.River the output to 24 Bit (this is also possible in Foobar), than the same happens as described above and the volume control and the replay gain control are still working, but truncate to 24 Bit. To set to 24 Bit is only necessary, that the output of the player can talk to the input of the DAC.

And if I have a 16 Bit USB device (for example PCM2706 from Burr Brown / Texas Instruments), than I have to set to 16 Bit output, when using the exclusive WASAPI Mode in Vista in order that the output of the player can talk to the input of the dac.

I hope this helps.

Juergen

laurent · August 27, 2009

A question for Chris (and to Gordon),

Did you compare the usb link to the standard usb input on some dac like the Bryston or the Bel Canto?

On those Dacs does the combined usb link + dac sounds "better" than the dac alone with its standard usb input?

I understand that the soundstage was thinner than with the Lynx Aes.

Gordon mentioned once that Bnc was to be preferred to coaxial. Does using the Usb link with a coaxial adapter can have an influence?

Thanks for your great input

Laurent

Ps : I would like to test one usb link but apart from ordering one I yet haven't found a way to test one in France.

PeterSt · August 27, 2009

I am 200% sure you are 200% putting your efforts in this to make it clear. But somehow it is so confusing to me. It will be my english, and I am sorry for that. But I picked one thing out of your last post, which to me seems key :

To set to 24 Bit is only necessary, that the output of the player can talk to the input of the DAC.

I can't be sure how technically you are speaking, but to me this sounds like "having said this all, when you don't comply to this, nothing will work anyway".

If you can agree with this, than we both agree on everything, and it is my suggestion to leave everything further to the interpretation of the readers here. If they don't understand they will ask (I suppose), and I hope you will be answering. If not, I will try.

I can only say : thanks !!

Addendum ...

So if you took a spdif transmitter (like the one in the bell canto) and supply them with master clock (system clock) and l/r clock, but without any digital data at the input, this device sends out 2 x 24 bit zeros.

Having an agreement on everything for a long time by now, this may be a far too technical outlay, because it is unrelated to the playback from a player. Thus, while per your outlay the DAC is playing all the time as long as it is under power (but plays silence), as soon as a real player interferes with, say, something like sending 2 x 32 bits (if the driver would accept that in the first place) all is one big mess all over. Without further detail I am sure you will agree with that.

To me it looks like an electrical engineer (I am not blaming you of being one) has a totally different perception of these matters than the poor software engineer who only has to comply with the hardware, "that's all". Uhm ...

This latter of course was merely for fun, but it looks like there is a sense of truth in it. This intrigues me deeply, just because it is difficult (at understanding eachother). It looks like : everybody is right, nobody understands, some have sound, and nobody knows whether it's good.

A marvaless result of something I started - not.

I am not cynical, just sorry I responded to a by itself all so good review (which actually triggered me because of some gramar I couldn't deal with).

I won't say "out" and won't say "done", but if everybody now says "all is clear !" then I suggest it just is.

Fingers crossed,

Peter

Wavelength · August 28, 2009

Peter,

Maybe a better way to understand this is lower than you are thinking (software wise at the device level). While you can look deep into the hardware and determine the max bit width most applications assume or request a max bit width.

So in the case of the BelCanto as Chris has listed the output of the USB Prober we see the max width as 24 bits.

Ok assuming the application layer and sound interface layers sends 16 bits and it is untouched. The USB device driver will padd that 16 bits with 8 zeros to send the correct amount of data.

Now in the beginning of USB 24 bit audio I thought it was necessary to allow both 16 and 24 bits. You can enumerate to do so and when the interface is set to 16 the device driver will only send 16 bits of data and when 24 it will send only 24. Later I found it was a waste of time indicating both 16 and 24 and did what Centrance had done for BelCanto and set the interface to 24.

When I move to 32 bits, now that will be different as we can tell that now float32 will not really work as well for audio based at 32 bits and therefore I will probably enumerate for both 24 and 32 bits allowing the customer to optimize for whatever software and os they are running.

Thanks

Gordon

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