This makes my story above true.


This is slightly morte difficult;

Please accept the below as a brainstorm I don't want anybody to understand except myself, possibly informative afterall for those with unexplainable errors or things happening. Remember, XXHighEnd is the first player that's confronted with this phenomenon of Exclusive mode versus (!!) Shared Mode, so there's really no experience from anyone "we" could fall back to.

The first message indicates that that it is impossible to avoid reampling. Mind you, in the context of your problem.
However, where #1 and #2 in this same resulting situation ALWAYS will make something of it, because Vista just does, the second message from #3 tells that what Vista makes from it, just doesn't match what I desire it to do.

However, this is the result of "elements" that operate indepentently from eachother, both messages being true, but possibly not giving you the desired situation. Thus : the sole fact that your soundcard does not allow Exclusive Mode (WHICH CAUSES RESAMPLING BECAUSE OF THAT) does not say that you don't want it to play sound. Now, this other element, obviously anticipating on bit perfect playback where #3 was made for, just rejects the output sample rate (created by Vista) just because it can't resample to this samplerate itself. So what it sees is : In 44K1 -> Possibly out 48 --> error because "I" can't do that.

The whole point here is that in the situation the soundcard can't be gotten exclusively, Vista takes care of the resampling.

Read the last oine again. There I say exactly the same as before, but from another angle. Before I said : when the soundcard can't be gotten exclusively, Vista *will* resample. Where this one sounds negative, the before one is positive.

It is the positive thing #3 could anticipate upon BUT BUT BUT, I don't think I will ever know whether Vista really can make something from it.
Thus the literal situation which will happen in the program is : I want 44K1, Vista tells that's not supported, and then the program must assume something else is (might it be 22K050 or 96K whatever). All is out of the scope of the program as soon as shared mode is in order.

Because now this is getting related to a "structured breakdown" of the sounddevice in order to present the proper messages and making the good decisions, I will not be able to do this in between the lines and without carefully thinking and testing. IOW : This won't happen today.


Johan, can I assume that this won't be a problem for you since you actually should use (or just use) your DDDac ?

This was about a thread like this : http://forum.bd-design.nl/board_entry.php?id=11592#p11660, but never mind if you don't know about that and don't do it.


Ah ! wait a minute ...
So here we will be having another case of "HD Audio Device" I guess ...
But I think your case is different from those "don't want to make sound" and here indeed Engine#3 will be using it in shared mode, and then at the next track it tries to exclusively use itself, can't, quits, and starts at the next track when it can again.

Okay, you can't follow this, but I can.
Anyway this is a case I can't test myself, because this is about a sounddevice not supporting Exclusive Mode (well, that is my guess), but it does allow Shared Mode because the sample rate it supports fits.
Note : which not the case at my place (laptop) because it only supports 48/96 so there's nothing else to do than give an error message (which it does -> "Format not supported", or similar).

The big (in fact huge) pitfall for everyone is, that without being able to look at the effectively output samplerate, you will never (be able to) understand why Engine#1 and #2 do make sound while #3 does not. This is because Vista just resamples to the (by the soundcard) supported samplerate (48 or 96 in my case). Engine#3 avoids just all that, but with the result it can't play.

Conclusion for your situation : This would just be a plain error in my code, and which I couldn't (and can't) test myself.

Johan, to be ahead of things a bit, before I'm going to change the program on this :
When you have sound from #3 by this means of laptop internal speakers ... can you change the volume by the Vista mixer (speaker icon in the taskbar tray) ?

Thanks,
Peter

How are you doing on this Werner ?

It might be good to follow this topic just as well : XXHighEnd version 0.9d stops after one track + errors
Peter

Hi Johan,

Not that it immediately solves your problem, but please look at this post : http://www.phasure.com/index.php?topic=94.msg477#msg477 and look at the whole topic as well (solutions for stopping after each track) and notice that Werner too was bothered by the hanging sound).

It would be interesting to know whether the Delay (in XX) of one second helps you too.

Just for your information : The hanging sound you were bothered with is expected to be caused by the driver (http://www.phasure.com/index.php?topic=123.0). I think that *instead* of that happening, now an unexpected situation occurs because of which XX(engine3) dies.

In any case : never always use the same CDs for testing these kind of things, because it might be caused by the CD and the way the tracks end, which often is not official.
Also, do not use offline upsampled tracks (e.g. to 48K !!) to test this because the program performing the upsampling might have written wrong header data into the file (which would be a typicle cause for this problem).

Tomorrow I will change Engine#3 so that it anticipates better on wrong header data vs tracklength, to exclude that problem to start with.

Peter


Edit : Actually, the more I think of it, the more I think you use offline to 48K upsampled tracks. Just because you are in the DDDac "community" and over at BDDesign this subject started. This would be Werner's problem too then.

Now I think of it ...

Supports asynchronous and isochronous data transfer modes

It could very well be that your current card does not support this. Or better : if it doesn't, the result might be what you hear (just guessing, but it seems logic to me).

Edit : I meant the Isochronous; Asynchronous is normal.

If they can't be plugged to a 400 connection ... no.

In this picture (backside) in the thrid sectrion you can roughly see the 1 800 and 2 400 conections. They are different.

I think a physical 800 ceonnection will pass through an actual 400 logical connection, but you'd have to solve the cabling conversion.

But you do have another Firewire card on order in the mean time ?

If I were you I'd got crazy ... 
I'm really sorry for you Chris.

Now I think of it ... There should be some kind of message when indeed your HD sounddevice is giving you problems as I suggested.
But do you *have* an message ?

If not, something else is going on.

Chris,

When your'e playing with Engine#3, XXEngine3.exe will be visible in Taskmanager;
Suppose you give it high priority (rightclick on the process -> set priority), possibly even "Real Time", does that help you ?
I disabled setting the "thread" priority for #3, just because it shouldn't matter, but supposed it helps you ... I can enable it.

Peter

GREAT !

 

No, you should be able to use it "locally" as well. I never tried it though.
I think you can start at www.freedb.org to check it out.

I'm not sure this is for the unexperienced ... "Downloads" overthere doesn't look promising. I just don't know !

Hi Rupe,

Now I'm not sure whether you previously though to come back when the baby is ready (see your own text), or that you NOW think to come back later ... When the last :

No reason to, because afaik everything works. However :


This is about the HD audio driver which is just not allowing Exclusive Mode. This is unrelated to a baby not being ready, but is about (IMHO) Microsoft providing immature soundcard drivers for the HD Audio internal device. Here is where I promised that (although I thought you indeed were already using #3 at that moment) :


For this device only #1 and #2 can be used, and than Vista resamples in both cases (as it would do with each player).
In the end you just must not use this internal device.

HTH

Not since I forgot about that , although incurred from this :


and


of which I did not see the logic, although literally ("deliver") it would be correct.

But okay.
My conclusion would be it's the PC talking to firewire - or the PC-Firewire card. I'd opt fot the last (also because the route is more easy to check).

I don't think otherwise, bot you would PROOVE the opposite if you'd plug in earphones into the Dell, and then it would be glitch free. So you really must do that !!

Yes.
The question is though, whether your headphones are connected to an output from the PC itself (and not to the Fireface). If so, it's *also* not the Firewire.

?