> In the third computer (connected to the RME Babyface and the Phasure NOS-1), in Cantabile I'm using
> the ASIO Fireface USB driver for the RME Babyface, but again Cantabile also sees the DirectSound
> drivers for the Babyface.

Just as an experiment, in this third computer I tried switching Cantabile's input to the driver labelled "DirectSound - SPDIF/ADAT (1+2) (RME Babyface)", but I could not get this to work.  Cantabile refuses to see any input via this driver. So Cantabile does in fact seem to be dependent on the ASIO driver for this device (the RME Babyface) to work properly.

Again, this has nothing to do with the availability, or lack thereof, of an ASIO driver for the Phasure NOS-1, since the Voxengo Recorder VST plugin that's driving the Phasure is not in fact using (or even seeing) any ASIO drivers -- it's only got MME drivers available.

By the way, you might wonder what's happening with the "official" output (as opposed to the "diverted" output from Voxengo Recorder) of Cantabile on this third computer (the one actually driving the NOS-1).  Answer -- I've left it "unassigned" (and also I've unchecked the "Output" checkbox in the "Master Levels" section of the top toolbar under the "Home" tab).  So I guess Cantabile is happy feeding a VST chain even if the ultimate output is both unconnected and unassigned.  (Which is nice, as it saves USB bandwidth that would otherwise be used just filling a formal requirement for an output device.)

But no-go with DirectSound.

Peter,

You wrote:

> I'm wondering where you find the time. . .

I just retired at the end of last October.  I've got nothing but time.  ;->

> Suppose I'd like to try some of these route(s) ...
> What in your chains is able to do this without using ASIO (WASAPI or KS) ?

Nothing in this chain is absolutely **dependent** on ASIO (though I'm using ASIO in most of it), as far as I can tell.

Let's see, starting with foobar2000 in the first computer -- I'm using the ASIO Fireface driver for the RME Fireface 400, but I could just as esaily be using either DirectSound or Kernel Streaming drivers for the Fireface 400.

In the second computer (connected to the RME Fireface UFX), I'm using the ASIO Fireface driver in Cantabile 2.0 Lite, but Cantabile also "sees" DirectSound drivers for the Fireface UFX.

In the third computer (connected to the RME Babyface and the Phasure NOS-1), in Cantabile I'm using the ASIO Fireface USB driver for the RME Babyface, but again Cantabile also sees the DirectSound drivers for the Babyface.

Voxengo Recorder (in the third computer) **only** sees MME drivers (for both RME Babyface and Phasure NOS-1), so of course I have that driver selected (for the NOS-1).

I haven't actually tried switching to any of these other drivers, but I have no reason to think they wouldn't work. I always pick ASIO if it's available.

Oops -- I take that back.  In the second computer (connected to the RME Fireface UFX), Cantabile sees DirectSound drivers for **either** ADAT 1+2 **or** ADAT 3+4, but not both (a similar limitation exists when using a USB connection to that box instead of Firewire, with or without ASIO).  So using a DirectSound driver I'd only have 2 channels at 24/192 instead of the 4 that I need to get Cantabile to do both input and output on the same box at 24/192.  I guess this is a limitation of the RME drivers.  I'd have to find a different -- and undoubtedly much more expensive -- interface box if I couldn't use ASIO on this middle machine.  But that has nothing to do with the Phasure NOS-1.

> > The trick to tying them together was the discovery that
> > the freeware DAW Audacity. . . has a feature called
> > "software playthrough" that lets you turn on monitoring
> > and feed audio from your selected recording device. . .
> > to your selected playback device. . .
>
> I just discovered, quite by accident, that Windows 7
> will do "playthrough" from one sound device to another
> automatically, without the need of other software. . .
> If you check the box "Listen to this device" you can then
> select any other device in the "Playback through this device"
> drop-down.

In case anybody's interested, and for what it's worth, I've discovered a third way of bridging two different USB audio devices on a single computer, and this third way seems (so far at least) to work better, with fewer audible glitches, than either of the above.

There's a kind of software that functions as a real-time (i.e., streaming input to output, not just processing files in a DAW) host for VST (Steinberg "Virtual Studio" DLL) plugins -- i.e., a software "effects rack".  There are a number of these programs, both free and for money:
http://bedroomproducersblog.com/2011/05/16/bpb-freeware-studio-best-free-vst-host-applications/
http://www.sonicprojects.ch/obx/freevsthost.html
But the first one I tried out, and that I've continued to use, seems to do the job fine: Cantabile 2.0 Lite. That's the free edition of the software -- Cantabile 2.0 Solo and Cantabile 2.0 Performer are the paid-for versions, with capabilities I don't need.  All these versions include the ability to use MIDI instruments, but as I'm not a musician, I haven't paid much attention to any of that.
http://www.cantabilesoftware.com/
(There's a demo of Cantabile Lite on YouTube
https://www.youtube.com/watch?v=msOqxC5hPPA ).

Now Cantabile (or any other VST host I know of) doesn't, in and of itself, allow you to "bridge" two different sound cards (or USB or Firewire interfaces or ADC/DACs, or what have you).  You pick a **single** device's driver, and from that single device's selection of input and output channels you can choose the VST host's inputs and outputs.  (This makes perfect sense from a clocking point of view.)

However, it turns out there's a very interesting (and free) VST plug-in called Voxengo Recorder:
http://www.voxengo.com/product/recorder/
Voxengo Recorder sits in a VST chain and allows you to divert the audio stream into a file (hence the name "Recorder") **or** to "break the rules" by diverting the audio stream to a different audio device on the computer.  While doing this it also continues to pass its audio input on to the next VST plugin in the chain.

So the bottom line is that I can use Voxengo Recorder plugged into an "FX rack" inside Cantabile 2.0 Lite and bridge USB input from the RME Babyface to USB output on the Phasure NOS-1.  This is all happening at 24/192.

Unlike with the Windows 7 "listen to this device" playthrough feature, I can pick specific drivers (ASIO for the Babyface, though Voxengo Recorder is restricted to MME drivers) and I can play with buffer sizes (maximizing both the size and number of buffers, since I don't care about latency at all).  And this does seem to reduce the glitch frequency below what I was getting with Windows 7 playthrough.

As an aside, I've also expanded my experimental playground from the two-computer system I described in my earlier posts in this thread to a **three**-computer system.  The playback computer (running foobar2000, feeding an RME Fireface 400 clocked by an Antelope Isochrone) remains as before, and the laptop feeding the Phasure NOS-1 (but now using Cantabile 2.0 Lite and Voxengo Recorder to bridge the RME Babyface to the NOS-1) remains the same as before, but I've got a new computer in the loop.  The ADAT S/MUX4 (from an Apogee Big Ben being fed dual-wire AES from a dCS Purcell hardware upsampler) that was going directly to the RME Babyface now goes first to an RME Fireface UFX connected by Firewire 400 to the dual-core Windows XP machine I'm typing this on.  This third machine is also running Cantabile 2.0 Lite and is taking 24/192 from the Fireface UFX's ADAT 1 input and sending it back out to the Fireface UFX's ADAT 2 output (the RME Fireface UFX has 4 channels of 24/192 [or 8 channels of 24/96, or 16 channels 24/48] over ADAT, but only if you're using the UFX over Firewire; if you're using it over USB you're restricted to half as many ADAT channels).  The Fireface UFX sends 24/192 ADAT S/MUX4 optical on to the Babyface (that's sitting on top of it), and so on out to the Phasure NOS-1 as before.

In this middle computer, inside a Cantabile 2.0 Lite FX rack, I've been playing with two plugins -- the Fabfilter Pro-Q 2 parametric equalizer (just the demo version so far) followed by iZotope Ozone 4 (just for the MBIT+ dither).  I've been experimenting with various dither settings in iZotope, at the 24-bit, 20-bit, and even 16-bit levels, with and without various strengths of noise shaping.  I'm planning to try out a couple of 16-bit 192kHz NOS dacs with this arrangement -- an Audial Model S USB (Philips TDA-1541A) and an MHDT Labs Stockholm 2 (Burr-Brown PCM56).  Noise shaping over a 192kHz bandwidth is an interesting proposition, if the noise-shaping curve actually takes advantage of the full bandwidth.  Details of this as it might apply to MBIT+ are nonexistent, but when the algorithm was "MegaBitMax" and was part of Alexey Lukin's "ExtraBit Mastering Processor" (before he licensed it to iZotope), Lukin claimed "A new version of ExtraBit Mastering Processor 2.0 has been released. This version features special optimized dithering for high sampling rate modes, such as 96 kHz, 192 kHz, and others. Try our state-of-art dithering to 8 bits at high sampling rate and you'll never return to 16 bits.   ".
http://audio.rightmark.org/lukin/
(He was making a little joke there about 8 bits, but the possibilities at 16 bits, with a 16-bit NOS DAC running at 192 kHz, are more interesting.)

John Stuart (of Boothroyd-Stuart; i.e., Meridian Audio) also remarked in a 1996 paper, "This document shows that a combination of noise-shaping and a new pre-/de-emphasis characteristic for 96kHz (88.2kHz) applications, can result in an effective addition of up to 7 bits to the channel capacity.  For linear PCM systems operating at high sample rates, this technology is important, it ensures e.g. that a 16-bit channel operating at 96kHz can provide an effective dynamic range equivalent to 23 bits in a normal 48kHz PCM channel."
https://www.meridian-audio.com/meridian-uploads/ara/dvd_96k.pdf
Presumably this works even better at 192kHz, if the noise shaper is designed to take advantage of the full bandwidth (as MBIT+ **might** be if Alexey Lukin didn't "dumb it down" when he turned it over to iZotope).

Oh, one last thing about VST hosts -- I've also successfully used DX plugins in Cantabile 2.0 Lite, via something called DXShell:
http://www.kvraudio.com/forum/viewtopic.php?t=177538
To get my DX plugins to work in Cantabile, I did indeed first have to run the supplied shell2vst tool, which finds all the DX plugins installed on the computer and generates a whole set of corresponding "shell VST" plugins that can then be treated as ordinary VST plugins by a VST host such as Cantabile.

All the above is for Windows.  I'm afraid I'm not a Mac kind of guy.  ;->

Peter,

You wrote:

> . . .try XXHighEnd. . .

Well, of course, I **have** tried XXHighEnd.  I've purchased two licenses for it over the past several years, the first for 0.9z-6-1 (I think it was, even before I bought the Phasure DAC), and more recently a fresh license for 1.186a.

I've also had two licenses for HQPlayer (first 2.8.4.3 and more recently 3.6.1.1).

So I'm not unfamiliar with XXHE.  All issues of sound quality aside, you've got to admit that foobar2000 is more convenient to use than most of the alternatives.  I got into computer audio after the Winamp age, I've never been tempted by JRiver Media Center, nor have I ever been tempted to switch to a Mac for the sake of Amarra, Audirvana, or PureVinyl.

;->

> Nick,
>
> You wrote:
>
> > But again re reading your first post I think the laptop is still
> > reading its disk but there are newly introduced SPDIF and upsampleing
> > steps in the data path.
>
> I would suspect that in fact it's not using the disk at all
> (that is, on the laptop that's "bridging" the RME Babyface USB
> input to the Phasure NOS-1a USB output via the built-in
> Windows 7 playthrough capability).

I can confirm that Windows 7 playthrough produces no disk activity at all.  The disk activity LED on the laptop stays completely dark (once Windows has had a chance to settle down after I've stopped using the keyboard and/or mouse and closed the screen).

I had to disable the CD/DVD ROM drive in the laptop to make this determination, because before I did that the disk activity LED was blinking steadily about once a second (a Google search of this phenomenon suggested that it was because Windows 7 is polling the CD/DVD drive to check for an inserted disk once a second, and sure enough disabling the drive in Device Manager did indeed stop the blinking).

During the course of trying to stop the disk activity LED from blinking, I opened the service manager and went through the list of Windows services, stopping as many as Windows would allow me to.  I left the Windows Audio services running, and the Phasure NOS-1 service (and services that it depends on), and I also left the Multimedia Class service running, for whatever that's worth.

I did all this while the audio was still playing.

Interestingly, since stopping all those services, I have not noticed a single playback glitch of the sort I had previously been attributing to buffer over/underflows.

So maybe this is a viable long-term arrangement after all.  I'd still hesitate to recommend it to anybody else, because the stability of the whole collection of components may depend on the particular devices being used.  But I have to say, I think I've stumbled into some remakably good sound with this setup.  ;->  (I think it's the best I've heard from the NOS-1.)

Windows playthrough does seem to be surprisngly stable -- I've left the system playing overnight (with the volume turned all the way down ;-> ) and next morning it's still playing -- no freezes or crashes.

It's even possible to unplug one or both USB audio interfaces (the Babyface and/or the Phasure), and then plug them back in and have the audio resume automatically.  (Though one thing to be aware of is that when using Windows playthrough the source and destination devices are automatically selected as the default Windows recording and playback devices.  So Windows sounds -- the bonk-bonk when you disconnect or reconnect a USB device -- get played through the Phasure, and the stereo system, if that's connected while the other USB device is disconnected or reconnected.)

I haven't had to reboot the laptop since I started all this.

(By the way, a Microsoft programmer named Larry Osterman is the guy who wrote the code for the Windows 7 playthrough feature -- he calls it "Capture Monitor".
http://blogs.msdn.com/b/larryosterman/archive/2009/08/04/a-few-of-my-favorite-win7-sound-features-capture-monitor-aka-listen-to.aspx )

Nick,

You wrote:

> But again re reading your first post I think the laptop is still
> reading its disk but there are newly introduced SPDIF and upsampleing
> steps in the data path.

I would suspect that in fact it's not using the disk at all (that is, on the laptop that's "bridging" the RME Babyface USB input to the Phasure NOS-1a USB output via the built-in Windows 7 playthrough capability).

Remember, there are actually **two** computers in the system I'm describing.  The computer that has the music files and the music player is the one I usually use for audio playback -- an HP minitower (quad-core i7, with Windows 7 64-bit).

The (current) architecture of the whole system is not unlike that of a dual-PC system using HQPlayer on a PC connected over a LAN to HQPlayer's NAA (Network Audio Adapter) on a second PC that's actually performing the job of feeding the audio to a USB DAC (or the similar arrangement using JRiver Media Center on one PC connected over a LAN to a second PC running Jplay and feeding audio to a USB DAC).  Except that instead of using Ethernet to connect the "control PC" to the "audio PC", I'm just sending the data via S/PDIF (or ADAT).  And it's the RME Babyface USB interface that's getting the ADAT (or S/PDIF) -- the laptop only sees USB data coming in and going out; it's certainly not doing any sample-rate conversion, and it's not reading or processing audio files.

I've actually got a sort of "optical bus" running around the house.  The source PC (running foobar2000, usually) is connected over Firewire to an RME Fireface 400 that's clocked by an Antelope Isochrone.  The Fireface sends optical output to the first audio-system "station" on the bus -- the "station" is either an Apogee Big Ben or an RME ADI-192DD that takes in the optical and then passes it along to the next "station" (the optical links are up to 50' Hosa glass cables).  The Big Ben or ADI-192DD can then feed a DAC, or a signal processor (like the Purcell), etc., etc.

I also installed that "Fidelizer 6.5" program on the laptop (the Toshiba laptop's also a quad-core i7 machine running Windows 7 64-bit; both machines have plenty of memory -- 6 or 8 GB, I can't remember exactly), and put Fidelizer into "Extremist" mode, so the laptop should be pretty quiet --
I don't think Windows would have any need to page to the hard drive, and I can't see why it would be putting any audio on the hard drive -- I would think the buffering would all be done in memory.

Oh, speaking of the Purcell -- I just noticed that in fact when you're doing upsampling from 44.1k to either 176.4k or 192k, with 24-bit output word length, both dither and noise shaping are automatically turned off, and cannot be turned on, at least with the firmware in the unit I'm using (these things go through multiple generations). I hadn't noticed this before (I'm used to using the Purcell in other modes, such as doing 44.1k->96k and then
reducing output word length to 18 bits to feed an Audio Note NOS DAC capable of taking 96kHz). So much for the theory in that IAR article about noise shaping!

And as far as playback glitches are concerned -- they do happen from time to time (every 15 minutes or so maybe?) and are quite audible, even with Windows 7 playthrough and Fidelizer.  They sound like buffer underruns to me -- the audio drops out, comes back, drops out for about a second or two altogther, then goes on for a long while before the next one.  There were a lot more of them when I was using Audacity to do the playthrough (and they were different -- raspberry-sounding things: brrrrrr for a second or so.  A buffer overflow in that case?).  So again, I'm not really recommending this to anybody.

Nick,

You wrote:

> Great post and a result getting a recombined 192k stream into your NOS1a.
> I would be interested to hear what the resulting sound is like compared
> to playing at 192k directly to the NOS1a. . .

Well, I'm not actually seriously recommending a setup like this to anybody.  My intention was more along the lines of announcing "Look at the flying pig!" and suggesting a way in which somebody with a lot of electronics at their disposal (USB interfaces, digital format converters, what-have-you) can play with their toys.

But as to sound quality -- well, this might be rather system-dependent in my case.  The system I'm experimenting with is rather a "dog's dinner", as the British say.  My Quad ESL-63 electrostatics started showing their age a while ago (I've had them for more than 20 years, and I bought them used) -- they started arcing-over occasionally, while turned on but not playing, in response (it seemed to me) to the downstairs neighbors' cooking smells (like an audio smoke detector, if I'm not totally imagining the correlation).  So it's time to have them cleaned and/or serviced and/or refurbished (and/or recycled -- but I don't want to think about that ;-> ).

Anyway, in the meantime I looked around for a pair of relatively modest speakers that wouldn't be too embarrassed to stand in for Quads, and I bought (used, unheard) a pair of Paradign Signature 2 v2 (with the beryllium tweeters).  These are being driven at the moment by an unmodified Carver Pro ZR1600 (a Tripath-based amp -- full-range Class D -- that some folks were raving about 11 years ago) whose balanced inputs are being fed by an Audio Experience (a Chinese direct-sale brand) "Balanced A2" tube balanced line stage.  (I've basically retired my tube amps.  Unless I experience a change of heart, which I suppose is always possible, I'll be using full-range Class D [Tripath is defunct, but ICEpower, Hypex UcD et al. are still around] for power amplification, and tubes only in line-level preamp stages, for the foreseeable).  So anyway, like I said, a bit of a dog's dinner.

As I mentioned, I've been experimenting with software upsampling ever since I stumbled across a computer program called Eximius DVD2One more than a decade ago.  Most recently, I've been playing with realtime upsampling in XXHE, HQPlayer, and foobar2000 (with the SoX plugin).  And even more recently I've been playing around with an iFi iDSD Micro, to see what upsampling to DSD sounds like (in HQPlayer, foobar2000 with Maxim Anisiutkin's ASIO Proxy driver, or offline with Yuri Korzunov's -- Audio Inventory's -- "AuI ConverteR 48x44 PRODuce-RD").

In fact, it was after hearing the DSD results that I got really annoyed with my collection of upsampled PCM files, so just on a lark I decided to try out the dCS Purcell again -- to go back to the unit (or at any rate the consumer successor to the dCS 972 pro unit that started it all) that created the "upsampling" juggernaut back in '99 (Jonathan Scull's review of that in _Stereophile_ remains to this day the most affecting piece of audio porn I've ever read, http://www.stereophile.com/digitalprocessors/260/ ).

So what's the difference with the Purcell (in comparison to a batch of files I upsampled with iZotope's 64-bit SRC to, variously, 192k, 96k, and 176.4k -- [settings: Steepness 4; Max filter length 2,000,000; cutoff scaling 1.28; Alias suppression 200.00; Prering 0.00%]).  This is totally subjective, and may have more to do with my current mood than anything else, but -- a bit more midrange (not getting lost between the bass and the treble), plenty of ambience, but with a bit less "hollowness" than before, and most importantly, a bit less sharpness in the upper midrange (especially on piano tone -- it's important to be able to listen to Alfred Brendel play Mozart piano concertos on Philips without getting a headache ;-> ).

It's perfectly possible one might be able to match the sound of the Purcell with a different software upsampler, or with different settings.  There's been a lot of discussion on Computer Audiophile (and even Hydrogen Audio) about trying to match the characteristics of Ayre's "apodizing" filter by playing with settings in SoX or Izotope to minimize pre-ringing, use minimum-phase filtering, etc., and I was going along with all of that.  Maybe I was barking up the wrong tree (I doubt if the Purcell follows that mantra).  On the other hand, dCS's filter algorithm (**whatever** it is) **was** the one that got everybody's juices flowing in the first place, 15 years ago (assuming it wasn't just a marketing stunt that all the reviewers got suckered in by).  On the other hand, I've seen an article on line from International Audio Review ( http://www.iar-80.com/page21.html ), presumably from back around the turn of the century, that claims that the Purcell's "magic" had nothing to do with upsampling per se, but everything to do with the noise-shaping that it applies (which is actually a user-selectable option) when converting back to fixed-point output after doing its internal arithmetic).  I have no idea if the author of that article knows what he's talking about (I fear the worst ;-> ).  So who knows?

Peter,

You wrote:

> What I recall is that when W7 was around XXHighEnd did not support KS
> yet, and one of the first things I tried was that PassThrough. So must
> have been WASAPI. However, it did not work well enough. . .

One thing that occurs to me is that with the setup I'm using (with Windows 7 playthrough), there are two independent clocks -- the one in the S/PDIF or ADAT coming in, and the local clock in the Phasure NOS-1.  So, sooner or later, depending on how closely the clocks are matched (and the master clock in my system is an Antelope Isochrone, so I imagine the two clocks are pretty close, but still not absolutely identical), there will be a playback glitch eventually, because a buffer in the computer will either overflow or run dry.

I know there are DACs out there that are deliberately designed to work this way (Doede Douma's DDDAC comes to mind, and there are others) -- "exotic" D/A boxes that clock their DAC chip locally rather with the extracted clock from incoming S/PDIF, and that let the two clocks freewheel against each other, glitches be damned (for the sake of the sound quality in between the glitches ;-> ).

It's considered bad engineering practice, but so was NOS once upon a time (and still is, at least at 44.1k).  "Good" engineering practice would be to put an asynchronous sample-rate converter (like a CS8420, AD1896, or SRC4192) in between the two clocks.

There was an amusing thread on Computer Audiophile a while back in which "Miska" (of Signalyst/HQPlayer fame) debated with a non-technical audiophile about this sort of thing.
http://www.computeraudiophile.com/f6-dac-digital-analog-conversion/mytek-stereo-192-a-5555/index113.html
The audiophile was using a setup with an independent clock in the DAC, and raving about the sound quality, and Miska was trying to explain why this inevitably leads to glitches and is considered bad engineering practice.  They never did reach a mutual understanding.

The answer to this conundrum is that a "civilian" audiophile is perfectly entitled to put up with glitches at home for the sake of the sound in between, but in a studio or other professional setting this would be considered completely unacceptable.  But even the "civilian" audiophile is not entitled to complain about the glitches, under these circumstances.

I just discovered, quite by accident, that Windows 7 will do "playthrough" from one sound device to another automatically, without the need of other software.  In Control Panel -> Hardware and Sound -> Sound -> Manage Audio Devices, under the Recording tab, if you pick a device and then click on the Properties button, there's a "Listen" tab on the next screen.  If you check the box "Listen to this device" you can then select any other device in the "Playback through this device" drop-down.

Seems to work fine.

I've been playing around with online and offline upsampling for years now (including with XXHE), most recently offline using iZotope's 64-bit SRC (selected as a DSP effect in a Sony SoundForge batch) trying out settings from posts over at Computer Audiophile (primarily from folks who use the real-time iZotope SRC available in Audirvana+ on the Mac).  I even recently coughed up the bucks for AuI Converter producer edition, which can off-line upsample to DSD512 (the resulting .dsf files are **huge**, but they sound good, and I can play them back in HQPlayer or foobar over USB to an iFi iDSD Micro).

I've been a little frustrated with the sound of PCM upsampling recently (variously, to 96k, 176.4k, or 192k, played back over various DACs,
NOS and otherwise).

So on an impulse I conceived an experiment, which I frankly didn't expect to work.  I have a dCS Purcell hardware (synchronous) sample-rate converter that I decided to take out of the closet and try again, just for kicks.  Using the Purcell to go from 44.1 to 192 is problematic unless you have a dCS DAC, because when the Purcell is outputting 192k, it's doing so over dual-wire AES.  There are a number of discussions on the Web with folks lamenting the difficulty of getting from dual-wire to single-wire, but I discovered a way to do it using **two** Apogee Big Bens: dual-wire from the Purcell into the first Big Ben (input set to AES "DOUBLE"), then ADAT S/MUX4 from the first Big Ben's optical output to the second Big Ben's optical input (with the second BB's input set to S/MUX 4, of course), and then from the second Big Ben you can take quad-speed single wire out via AES or even coaxial S/PDIF.  There's no way to do this with a single Big Ben (at least not with any firmware revisions I have access to).  Nor can I do it with one or even two RME ADI-192DD digital-to-digital converters.

So the first DAC I tried with this setup was a Wyred4Sound DAC2 (with the ES9018 "Sabre32" chip), which I certainly thought sounded better fed by the Purcell at 192k than the last time I'd heard it.

But then I thought -- I wonder if there's any way I can get to hear the Purcell through my Phasure NOS-1a.  The Phasure is a USB-only DAC (unless there's an S/PDIF input I haven't found ;-> ).  There've been naive queries on the Web from people wanting to know if there's any way to run USB-only DACs from S/PDIF inputs (like this one: http://www.head-fi.org/t/381903/spdif-usb ) and the answer to such queries has always been a brusque NO!

To cut to the chase, here's how I got it working.  I connected an RME Babyface USB interface to a Toshiba Windows 7 laptop with the Babyface driver installed on it, and connected the ADAT S/MUX4 optical at 192k from one of those Big Bens to the Babyface.  I also connected the Phasure NOS-1a to another USB port on the laptop (the laptop also has the Phasure's driver installed).

The trick to tying them together was the discovery that the freeware DAW Audacity (I'm using 2.0.6, the latest) has a feature called "software playthrough" that lets you turn on monitoring and feed audio from your selected recording device (in my case, the RME Babyface) to your selected playback device (the NOS-1a).  This playthrough monitoring doesn't work with all drivers -- WASAPI doesn't work, and when I tried an Audacity with ASIO support compiled in, the ASIO drivers didn't work either.  It has to be either MME or DirectSound.  Either of those work.

So I've got an elaborate S/PDIF (well, ADAT S/MUX4 to be precise, but it could just as easily be S/PDIF) to USB "converter" going, to be able to listen to the Purcell doing 44.1->192 to the Phasure NOS-1a.  It sounds pretty good!  (On the Purcell, I've got 24-bit output, "Filter 1", and 9th-order noise shaping selected.)

Sometimes, things that "shouldn't" work, do.

Peter,

You wrote:

> I derive that this happens since 0.9z-3. Is that correct ?

Actually, this is the first time I've tried XXHighEnd, so 0.9z-3
is the first version I've ever used; I have no experience with
earlier versions.

> > . . .when an album first loads up for playback, sound does not
> > begin until some seconds after the beginning of the first track.
>
> This would be completely new to me; Can you maybe recognize
> that this is related to the laptop's speed ?

Well, it's a 1.6 GHz quad-core i7-720QM (with DDR3 1066 memory).

However, I just noticed that most people around here are still
sticking with Vista, so maybe I'll try installing XXHE on a Vista
desktop machine I bought last year just before all retail
machines started to be sold exclusively with Windows 7.
It's an Asus Essentio, with a (quad-core) i7-930 at 2.66 GHz
(and 9GB of RAM, not that that would make any difference).
It has (64-bit) Vista Home Premium, which would perhaps be
more congenial to XXHE.  I'll likely be contacting you about
transferring the activation.

Hi.  I'm a first-time XXHighEnd user who
recently installed (and purchased and
activated) XXHE 0.9z-3 on a
Toshiba Qosmio X505-Q850 laptop with
Intel Core i7-720QM processor
6GB RAM
64 GB solid-state disk + 320GB SATA hard drive
Windows 7 Home Premium 64 bit

I have UAC turned off.

The XXHighEnd directory (& data directory) are on
the solid-state drive.
Music is on an external eSATA drive.

I used dbPowerAmp and some shell scripts to convert
a WavPack collection with embedded cuesheets, used
with Foobar, and with structure
D:Artist1Album1.wv
D:Artist1Album2.wv
D:Artist2Album1.wv, etc.
to an XXHE-compatible collection using Flac and
external cuesheets (which were batch edited to point to
their corresponding Flac files),
with structure
D:AArtist1Album1a.cue
D:AArtist1Album1a.flac
D:AArtist1Album2a.cue
D:AArtist1Album2a.flac
D:AArtist2Album1a.cue
D:AArtist2Album1a.flac, etc.
(The use of folder name "A" and filenames a.* prevent
the total path-length from becoming too long for Windows --
this collection contains lots of classical music with
long names.)
The "Music Root" is set to point to D:A.

Output is via USB to an M2Tech HiFace Evo (and thence
via AES/EBU to an Apogee Big Ben and various DACs).

In Settings, "Engine" defaults to "#3 Engine" when I select
the HiFace as the Output Device.  I've set the "Processor
Core Appointment Scheme" to "Scheme 4" under Processor Settings.

Under DAC Settings, "DAC is 24 bits 192.0 KHz" is selected
(the subsequent default of "At> 16 bits the DAC needs" to
"32 bits" works, and so does "24 bits".  I've left it at "32 bits").

Under "Memory and Disk utilization", I've set "SFS (Split File at Size, MB)"
to both 100 (which was the default) and 20.  Apart from the expected
variation in delay at start of playback, both work equally well.

Most of my listening has been done with "PeakExtnd" and "ArcPredict"
activated, and with the sample-rate slider set to 2x (Double), but
I've also experimented with 1x sample rate (44.1 kHz) with the
other two options turned off.

Music files were originally created as WAVs and cuesheets by
Exact Audio Copy ripping the original CDs.

Using the above arrangement (and with all combinations of the options
mentioned above) I can click on the "Library Area" button and
see the list of artists in the leftmost window.  If I click on an
artist, I see the labelled, red-outlined squares with the XXHE logos
representing all the albums in the artist's directory (I don't use cover art).
If I double-click an album icon, I see all the tracks (retrieved from the cuesheet)
listed in the middle window, and I see an icon for "a.cue" in the
rightmost window.

Here's the problem I've encountered:  during playback, sometimes
when a track boundary is reached (not necessarily at every track boundary,
but if the problem occurs, it always occurs at the same track
boundary for a particular album), when the track that's playing
ends, the "bounce bar" in the track list (middle) window will
advance to the next track, but the music will jump back to the
last minute or so of the previous track, play to the end again,
and then skip back again.  It will do this over and over for
maybe half-a-dozen times, and then playback will stop and
I will see a Windows "App Crash" message for "Engine #3".

If I swap the music library disk for a copy which has had all the
cue sheets deleted (with just the *.flac files remaining, in the
same directory structure), and if I then select an entire album
for playback, that whole album will play without interruption.

Nothing I have tried has altered this behavior.  (I have not
tried running in "Unattended Mode", or installing AutoHotkey.)
The same cue sheets have worked without any problems using
both Foobar 1.1.1 and cPlay 2.0 (on the same machine, and using
the HiFace Evo with either Foobar's WASAPI plugin, or with
ASIO4ALL 2.10 for cPlay).

So for now, at least, I'm constrained to using XXHE without cuesheets,
and to listening to albums from start to finish (or up to whenever I
decide to stop playback).

Apart from this, the only other problem I have encountered is that
when an album first loads up for playback, sound does not begin
until some seconds after the beginning of the first track.
If I then stop and restart playback, I can then hear the beginning
of the first track.

It does sound good, however.