XXHighEnd

This could be useful for HiFace users. Below is the reply from Marco - the Hiface tech guy:

"hiFace hase an internal buffer of 8192 bytes, that is 2048 samples in total (1024 per channel). Of course, the bigger the player buffer, the better. It's a trade-off between memory usage and CPU time, the smaller the buffer, the les the memory used but the more the CPU time (more transfers have to be done in a second)."

I am running Adaptive mode with 2048 for buffer and Q1=1. Seems OK.

Ivo

If his HiFace can be addressed with 16 bits this is 64 samples. But if not - or it is used for anything above 16 bits - this is 32 samples (in 32 bit mode). :yes:

Peter

Hey Peter, don't get up too early ! :smack:

And then to think I knew I must be doing something wrong.
Of course 8192 bytes is 2048 samples. But it is 1024 samples when the HiFace is addessed in 32 bits.

Peter

8192 bytes / 2048 samples = 4 bytes per 1 sample = 4*8 bits per 1 sample = 32 bits per sample.

So, I guess XX is talking to HiFace with 32 bit samples if DAC is is set to 32 bits.

From the above, as I understand for HiFace I should be using "Device buffer size" = 2048 because it is as Marco said.

The question: Is that OK that I am using 2048 in both Special and Adaptive modes? I just want to understand given we know the underlying HW details what would be the right "Device buffer size" setting. Not talking here on Qs as it is pure XX stuff.

Peter, can you confirm my understandings?

Ivo

I must be careful :) but this would be for one channel. So, your result will be 16 bits per sample (and don't try to rephrase your line above, because it uses "sample" as a known constant, which it is not).

Thus, the buffer size stays the same (2048) but depending on the size of the sample (16 or 32 bits per channel) more or less samples fit into it.

Peter

So, if I understand correctly, XX talks to Hiface with 32 bit samples. This is from what I see in the left upper part of XX when I run it in QAP. At the left I see the original bit rate (for 16/44) it is 16 bit samples and 44000 Hz and then in right side I see 32 and 176000. So, I guess this means that XX sends 32 bit samples down to the HiFace, right?

So, about the buffer... Marco said that HiFace buffer is 2048 samples (1024 for each channel).

1) Is it true that using 'Adaptive mode' I should be using 2048 value in XX? (The tool-tip states that it is extremely important to specify correct buffer size here of the underlying HW)

2) Is it true that using 'Special mode' I should be using the same 2048 value in XX?

I just want to know if my mentoring is right according to knowledge about HiFace and the way XX is built. Only from this point I can go further and start investigating how actually the 'Q' impacts the SQ.

Ivo

Ivo,

Right.

Yes.

No.


Ad 2 (No)

You can go as low as you want and your system is capable of. However, this is about the "internal" latency only, which just matters (as you will know or are able to hear).
Adaptive mode is only about the "net" or external latency. So, if all is right you can't go under 2048, hence under Q1=1 with a defined Device Buffer of 2048. IIRC 2048 was indeed my setting with the HiFace.


Although you sound as logical as always, I don't think this is true always. For example, once you like Adaptive Mode better, anything can happen. Even Normal Mode can be better, although I wonder whether there's anyone having real experience with that (at least I don't. :no:).

Peter

Why do I still have problems with Adaptive mode with 2048 for buffer and Q1=1 (attended)?
Had to set it to 4096.
In unattended mode it's ok

Possibilities :

1. Your PC is too slow to "manage" Attended;
2. Same as 1 plus you play hires material;
3. You imply something (with Attended) that "spikes" too much, especially when playback begins.

Ad 3.
The "Too many buffer errors" may happen within a tenth of a second, and in that particular time period (again, I estimate it to go wrong at the start of playback) e.g. the Wallpaper may be written. This is a typicle example of a too high spike. But it would also be *the* example of consuming 10000 times less cpu cycles when done at Unattended and "Services Off".

Peter


PS: When you have some spare time, please mention your setup and stuff in your signature (kind of like I do it). This helps with guessing things at finding answers. Thanks !

1. I have a 2500 Mhz core 2 with lavel2 cache of 1 MB per core
2. no hires material, just flac's 16/44.1
3. XXHighend and Windows XP are the only programs running on this PC
   Never have the "too many buffer errors" message anymore but on some albums I have some short gap's, most albums play perfect.

PS: When I can find the time I shure will mention my setup!!

Hi Peter,

After reading your "Guide to Glitchless Playback" I have still some questions on the buffer stuff. Actually, I do not have glitches or stalls, since I moved from laptop to normal PC box equipped with the Hiface unit. Even more, I can have small and large Q1 values with the same buffer size setting and I hear smooth audio.

Engine4, KS, Special mode. I set "Dev buffer size" = 2048 samples in XX. This is because I talked with Marco and it is right number if 32 bit samples are going down from XX to Hiface. So, as I get from your guide, longer XX output buffer is when Q1-->max and shorter XX output buffer is when Q1-->min. In both cases I do not have glitches, just different CPU utilization via Task Manager.
Question1: From the above, what length of XX buffer is ment to give the best SQ if the character of PC allows having the whole range of Q values? I did listen at both when Q1=max and Q1=min and at both times the sound is acceptable.
Question2: Where does *latency* comes into picture here? As I get, the ideal setup would be having as small as possible the driver buffer and the same small software buffer, so the latency is at minimum. Can you comment here?
Question3: What about 'Adaptive mode'? Do Q values act the same like having larger Q means having longer buffer?

Note: There is no word in your guide about DMA. I am not sure how in Win7, but in earlier Win versions HDD could have been working in PIO mode, so utilizing the CPU on every access. So, having DMA working as intended may solve lots of problems with disk access, thus reducing possibilities of having glitches and reducing load on the CPU.

Ivo

Hey Ivo ... I hope you can still sleep ... :)


I don't know ...
I don't know because this is not a measurable and/or scientific thing. But as far as we all are with everything, it now looks like the longer is the better because it seems to create the necessary emotion.

But it is so way way difficult to talk about it without our common knowledge on how it sounds. So, this is why the words in italics are there, and I try to derive this "vision" from all yours (visions);
Yesterday I had a flawed setup (DAC wise) and so I listened to something which could be more common like, say, you perceive sound. From theory I tried to solve it with extra detail and thus used a fairly low latency (512 dev and 4 samples XX). But it worked counter productive. Extra bad, and I clearly had to use Adaptive and 2048 for the device.
I only want to say : there is no way I would be able to so clearly make the choice when all sounds as should, and thus, how does this work out at your place ? I can't know ...


I think I just did. It is no science. But that the sound will be very different is a fact.


Yes. But only internally (XX). So, here the Dev buffer always determines the lowest possible latency (like a Dev buffer of 2048 will never be able to have an internal latency lower than 2048). With Special Mode it is the other way around ... that never can have an internal latency longer than the Dev buffer.

Peter

UDMA is already integrated in the system, UDMA mode 6 to be precise.
Check HD-tune Pro for eg.

(http://i33.tinypic.com/1zdahyg.jpg)

Roy