Thanks for helping
I can't comment on the 48k problem, but I CAN tell you why you can't play 192. Smiley
The TriVista21 DAC will not accept 192. Sad
Understood and it might spur me towards the next DAC upgrade. The EE is on the list of possibles but the list is headed by the April Music Eximus DP1 (if only the UK distributor would bring some in)
I cannot help on ASIO. It has been a long time since I used it. Have you tried Kernal Streaming instead of ASIO? That might help understand if it is an ASIO issue or something else.
The V-Link 192 is designed to run with the supplied ASIO drivers, although it is possible to run with WASAPI configured in JRiver. At the moment I propose to try and sort out the netbook playback as originally planned rather than start swapping the playback computer.
I remain baffled by the way that the V-Link and MC17 lock only at 48kHz.
Bearing in mind that the TriVista will not accept above 108kHz I have experimented with both 88.2kHz and 96kHz files. Both come up as replaying in MC17 at 48kHz and that is the LED that lights on the V-Link as soon as the track starts.
The set up PDF from MF states "The actual V-Link 192 hardware has separate high precision clocks for multiples of 44100Hz and 48000Hz, respectively; the appropriate selection is made automatically by the firmware and is not directly controlled by the USB driver."
With the V-Link showing a current rate of 192kHz before starting MC17 (and with that LED lit) playing a 88.2kHz file immediately shows the current file as playing at 48kHz (and that is the LED that is lit).
MF states "Neither the USB driver nor the V-Link 192 do any sample-rate conversion. Audio will always be played in its native sample rate, as stored on the computer".
Therefore the sample rate conversion must surely be happening in MC17, downsampling 88.2kHz files to 48kHz?
![Sad :(](https://yabb.jriver.com/interact/Smileys/classic/sad.gif)
otherwise if the V-Link were in control via the Asynchronous usb link it would be the 44.1kHz LED that would light up as a the source file requires the sample to be clocked at a multiple of that.
Have the experts at JRiver any further views as to what is happening here? Is this just a MF bug for the Thesycon driver implementation they have chosen, or are there other Thesycon driver issues out there affecting other DACS possibly including the Eximus DP1 I hope to review soon?
Paul