Hi Mani, thank you for posting this.

Yes, I have an idea ... Well, I think I have;
While everything plays at 32 bits (once the DAC has more than 16 bits), I don't think I anticipate on 32 bit input files. Think of something like

If not file = 16 bit then
  file = 24 bit.

This may look a kind of stupid because this data can be just read from the file, but it is about the explicit telling to WASAPI what the bit depth is which by itself goes with tricks and tweaks (because it is half flawed).

Now, because you are so nicely willing to make this clear without own benefit, I want to solve it indeed for everyone, may it ever be needed. Solving means testing, and I never saw such a file coming by. Therefore I want to ask you whether you are willing to email that file to me to sales at the phasure com address. You can go here to send large files : http://www.phasure.com/index.php?topic=721.0
Please note that it is not the beast idea to cut the file, because it will destroy the original length data in the header, and it might be specially organized (I just don't know yet).
But if I can buy it somewhere, that's very okay with me. But then you might have a link for me ?


On your problems ...
Yes, I recall you mentioning it at DIYA. Nothing came from RME ?
Btw, as how you write it now, it looks like I should be having a problem with it too ? ... and oh, I don't use the Fireface anymore. (a most special I2S connected DAC instead hehe).

Curious what the Weiss will bring you ...
Peter

Ah, ok. I know this problem is there, and this was at least one reason to put in that safety button.
I think I have currently solved it (for the next version), but it requires more testing to be sure. Btw, stopping playback with Alt-S (at Unattended) would incur for the problem also.

And no, the Services button is not needed in advance of playback. Note though (and this is the wacky think) that when playback starts, the current state of the services is saved, and it is restored to that state when XX is brough up again. Thus, once the services don't run (like in the situation you described) and you start playback, that not-running state is saved, and at a next normal bring up (like with Alt-X) will not run the services.

All would be 100% waterproof if I'd be allowed to always start the services when playback is not going on.
Which I probably will do ...
Or as I told earlier, make a setting checkbox per service (there will be more in the future).

Telstar,

You beautifully provided those log files, but as it turns out I need those from XXHighEnd (the XX files). Can you please :

Turn on logging, let it happen again, and at the moment the error message is on the screen, draw a copy of the XX log file and post that.

Thanks !
Peter

Do you mean the "Services" button doesn't do its job ?

That is not a PCI interface card ... it is a DSP (Digital Sound Processing) system which outputs its data over normal Firewire cable. This is indeed no Firewire protocol ("Cardbus" instead). But what to do with it ? nothing ...

But what happened to your Engine3 stuff ?

Leif, I moved your post to a new topic on the Support board.

Hahaha, I still don't understand. Does RME have something like a PCI Firewire interface ? maybe they have, but I don't think so ...

You would have

a. A random PCI Firewire interface card, or the one provided by the motherboard (never good !).

b. A random Firewire device connected to it. Could be a disk, a sat-receiver, an outboard soundcard, an RME Fireface ...

I really wouldn't know where RME would use their own 1394 protocol. Maybe they do, but then it goes unnoticed. To me anyway.

Hi Leif, sorry to hear about that. But can (could ) you bring XXHighEnd forward by means of Alt-X ?

Yes, Dave / SeVeReD reported similar. He has arranged for it even better though !
When he starts playback, his low figures drop to even more low. This is exaplainable I think.

However, what you know say is another one : during conversion it drops ...
I did not know that.

On a side note : my Vista system too, shows the 1000us always (I thought it was unique ). I must check the conversion period ...

In the end it will tell us that the method used may say something, but is not reliable. It will depend on measuring its own received responses to interrupts, and I am sure stuff can speed that up. This is why the report of Dave didn't puzzle me much. Now it is the question : what is it that may speed up interrupt responses at the conversion ?

One thing I know (and it may be very important to myself) : there is no way I can make a plain copy of a file myself as fast as the FLAC conversion does including the conversion. Russ, you may just have found the reason why ... (although quite unknown still).
Thus, I have examined all the means of copying (quite a few exist at the low (C) level), and while an e.g. 100MB file may take 5 seconds to copy, a 100MB FLAC conversion may take 1-2 seconds. I never understood that ...

Vista compliant : Yeah, this happens more often. But that is different from squeezing out all the stuff Vista has in it. So, in this case you are dealing with "WASAPI" (which is another means of producing sound, like DirectSound is another), and for that to go the explicit support is needed. The "compliant" can be seen as : it will run e.g. DirectSound on Vista like it does on XP. On that matter, Engine#1 and #2 will just do OK in Vista under those compliant devices.

Understanding Firewire and how it can carry SPDIF is not the easiest task. I may have been the first exploring this for audiophools' reasons (must have been 2005), and although in the pro world this all will be common stuff, for us this seems a strange combination of things which is far from intuitive.
It is best and most easy to just learn that it is so ... "Firewire can carry SPDIF". With this in mind, it is only a matter of getting it out at the other end of the cable.

A Firewire device which indeed shows all as should does help a lot of course. But think of this :
Once all the drivers are installed for such a device, and the device is Firewire connected to the PC, the PC shows all the sound devices. Amongst them is an SPDIF device, and to the user this is no different from thinking you have a coax (or toslink) cable going somewhere, and that at the other end an SPDIF connected device is hanging around. To make it even more clear : under XP the Fireface will show two SPDIF devices. One "normal" and one MME driven device. MME is a certain topology present under XP, but not there under Vista. Anyway, two SPDIF devices, and one cable only. It is sorted out within the Fireface (or within the driver).
Besides (for pro devices) ADAT devices will be there. ADAT is not different from SPDIF, apart from that it supports 8 channels per ADAT device instead of 2. Thus, when you'd choose an ADAT device, you'd be having 8 channels, and when you use the first 2, you again have "SPDIF". This comes down to the capability of using 4 SPDIF channels onto the one device. This can actually be used for e.g. DTS if the DTS stream is decoded in software, and the 6 channels can be output over ADAT. In (e.g.) the Fireface they are all available, and you could decide to pass the two main channeles through as SPDIF to the audiophile DAC, and let the other 4 play by the Fireface, and connect the mid, subwoofer etc. to the analogue out there.



To my own experience (and I'm sure Russ's too) the Juli@ is a good option. And far less expensive than a FF.


I am not aware of this. If you mean, use it as a network hub ... that won't go, because there are no Firewire outputs on it.

HTH a bit !
Peter

Mani !!!

You once anounced you got moving which would take you quite some time. I guess you now did, right ?

Personally I'd love to see your postings again !
I was quite on my own with the digicheck and all, lately.

G'day Andrew,

Before I get blamed for wrong advices :


... but none of them is using it as a DAC, which is what you probably perceived from what I said. The RME Fireface is always used as an outboard soundcard and passes through SPDIF to the audiophile DAC. I know, quite an expensive means to pass through SPDIF ...

Personally I'd never use the "pro" devices for a DAC. I guess that includes a Weiss ...
But then I am into non-oversampling (with reasons), so I would never end up at the pro devices by nature ...

Peter

It just slips into my mind (besides it should be VERY late at you last posting) ... do your Firewire devices show as "Loudspeakers" or as SPDIF or ADAT ? If Loudspeakers, you will be using XP drivers, and that may be the culprit.

?

Hi Andrew,

This Shared Dac Test is not official (I didn't even anounce it at any time), but theoretically -if that does show supported rates while Exclusive (the one but last Dac Test in the list) does not show them- it would mean that the rates shown at shared are only supported after resampling.

Don't hang me on this, because it's not official, hence not worked out decently.

The gerenal problem is that when the official Dac Test does not show support at certain rates (or all), the Dac doesn't talk properly back to the OS, or indeed does not support it. In your Firewire case I hardly can believe that though, and I only know it of USB devices. Otoh, the only experience I (we here) have on Firewire is the RME Fireface. And some propriatary Firewire interface I created for myself to the DAC ... that worked too.

I hope we can work it out ...
Peter

Hahaha, ... how to get it back there ? indeed it is over two years ago I shut it down.
But I will, as long as I can get it back ...