is apple lossless real lossless? - Page 5

I think it just locks up a bunch of system stuff.

 

I'd try it myself for kicks but I really don't feel like running a batch file made by an amateur programmer that messes with system permissions and what-not. Pretty sure it just allows for RAM locking but I'd rather just stay away from it rather than look into all the safety concerns of the stuff the script is doing.

Some people believe that transferring data from HDD to RAM and other PCI transfers in general temporarily block audio "flow" to soundcard and cause jitter. They call it "software induced jitter".

This would even make some sense twenty years ago, when soundcards used the primitive ISA DMA engine to fetch samples from RAM one by one when they were needed. But I don't think that PCI soundcards also fetch single samples instead of loading a dozen of samples ahead of time.

I've seen few articles on "software induced jitter" linked somewhere on HF, but none of them shown any measurements indicating that this jitter indeed exists and depends on activity of software and non-audio hardware.

stv014 did measurements of the xonar d1 with and without system load (CPU, HDD, GPU) and the results are pretty much identical. Some things actually measured a fraction of a dB better with load ..

I also don't know of any evidence for "software induced jitter".

 

The bat file indeed does some creepy stuff. For example it disables data execution prevention (a set of hardware and software technologies designed to prevent harmful code from running in protected memory locations), tells the boot loader to ignore all errors, overwrites some registry values ...

OK, that's what I expected. Soundcard designers aren't that stupid

It makes sense for noise to measure better under load, because unloaded CPUs and GPUs switch themselves on/off rapidly to conserve power, sending voltage spikes through ground and power supply cables.

But I hope than nothing else measured better because this would seriously undermine my faith in science

Actually, no matter how crazy it sounds, this may even be non-malicious. I've seen people claiming to hear cache misses and pipeline stalls so I'm pretty sure that DEP is also audible to them.


In case somebody wonders what a cache miss or pipeline stall is - it's an event in the CPU which causes much less electric noise than changing load patterns.
Edited by mich41 - 2/14/13 at 1:44pm

No, not quite.

 

the audio flow is not blocked it is slown down... how:

 

what used to happen was the samples sent to RAM were bigger than the space that could be held and played simultaniously and the extra effects on top of that would bog down the computer trying to play the sound.

 

the technical limits of the RAM somewhat played a part with speed of fetch from CPU registers but overall it is mostly a problem of doing too much at the same time and the computer would not be able to do both efficiently.

 

consider it like this:

 

the so called 'jitter' was a technical issue with the rotational speed of the machine head trying to get to the music and the fact that all the data was going to and from the drive and from RAM simultaniously as music was trying to be played from the drive and ram too.

 

so if you say defrag the hard disk and tried to play a came like Crysis 2 using that same hard disk as an example at the same time as defrag even on a Core i7 there is likely lag/slowness etc.

And nowadays even a $25 computer can play audio perfectly..

Edited by xnor - 2/14/13 at 3:13pm

It could be very well within the margin of error or tolerance interval. Plus or minus a tenth of a dB at over a hundred dBs down..

Most things happening "simultaneously" in computers are a lie. RAM cannot read and write at the same time, even in different places*. What happens is that soundcard and media player take turns reading and writing blocks of several samples.

Soundcard always has one block loaded to its internal memory and plays from this block at its own pace. A the same time, it fetches next block from RAM as fast as possible. Once this block is fetched, it notifies the CPU so that media player can prepare yet another block.

Media player can prepare next block very quickly because it maintains its own buffer of several milliseconds of predecoded audio, another buffer of undecoded data already read from the HDD, and yet another buffer of data being (slowly, since HDDs are slow) read from HDD.

The HDD send data in packets of few hundred to few thousand bytes. Other devices may also perform similar transfers at the time. All these transfers are interleaved with reads performed by soundcard, because RAM cannot perform multiple operations at the same time. Hence they do delay soundcard reads, but soundcard doesn't care because it plays an old block from its internal memory and waiting for some few kilobyte transfer to finish before fetching next block takes less time than playing this old block.


* Concurrent operations can only be performed on different RAM sticks.

 

???? What does this bizarre scenario have to do with anything that matters ????

 

In reality, when you play audio: enormous blocks are sucked up from the drive and put in RAM and this happens well in advance of the music in RAM running out. Not just this, but the audio hardware and drives will probably have their own buffering. And jitter isn't the same as a one-off delay - it's by definition recurrent, surely?

He might have been somewhat off topic, but this response was uncalled-for. 

Shhhhh! The admins are sleeping. Don't wake them up.

 

BOOYAH!

 

... I'm the guy(Cheuk Long Cheng)... Sorry for misleading cuz I just followed what MacRumors written about the license of Applelossless. By no means to be hating Apple, I personally use an iPod for my lossless music. Anyways just replying to tell that I'm sorry and thank you for letting me know more. Really shocked that you guys were talking about my comments 0.0"