Bel Canto USB Link Review

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.

Hi Chris,

Maybe it helps you to adjust the article on a few places if I tell you that some things aren't completely clear to me ?

It wouldn't make sense for me to say the device sounds great because after all it's an audio converter that should leave an imprint on the sound

I guess you wanted to say here "... that should not leave an imprint on the sound".

Reading further though, I have the feeling that you might have wanted to say

"... that should not leave an imprint on the sound, but sadly it does".

But whatever you make of that, reading along makes me more and more confused.
It looks like you have been struggeling to turn all into something which is not really negative, changed your story and ... made it inconsistent.
Or otherwise it is just me, and I can't get it quite.

Another thing :

Thus, the Bel Canto 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.

I am not sure this is true (implying it is not hehe). Please connect it to a Vista machine, go to the properties of the device - Advanced tab, and see whether a 16/44.1 device shows up in the combobox. If yes, you are correct, if not then at least for Vista the driver prohibits 16/44.1 material to be natively played. At judging this, don't get confused with 88.2 not showing up, which is a Vista bug, and it just can (Exclusive Mode only).

Please note I never had such a device in my hands, but can expect how it operates from the experience of similar devices (using the TAS1020).

Just helping to improve,
Peter

PS: Cross-posted with Elprior

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.

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

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 :~)

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.

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

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

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

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.

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.

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

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.

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.

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

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.

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

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.

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 :

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.

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

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

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 :

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.

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.

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

Peter,

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

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.

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.

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.

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

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.

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

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

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

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)

Peter,

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

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

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.

“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

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

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

What do you mean by not totally error free ?

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 ?

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

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

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

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

@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

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

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.

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

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