Computer Audio Asylum Music servers and other computer based digital audio technologies.

---

[ Follow Ups ] [ Post Followup ] Thread: [ Display  All  Email ] [ Computer Audio Asylum ]

---

[ Alert Moderator ]

---

Comments

Posted by Old Listener (A) on July 6, 2009 at 15:38:41

In Reply to: RE: Software induced jitter: how long is a piece of string? (Part 2) posted by Ryelands on July 6, 2009 at 09:35:50:

> jitter distortion (i.e. distortion in a DAC's analogue output caused by
> timing errors in the input and that it was not enough simply to take
> measurements at the input:

Making up a new phrase "jitter distortion" doesn't add anything. Measuring the quality of the clock signal going into a DAC chip can be quite useful in understanding what's going on. Taking a single number as a complete description of the quality of the input clock signal may be misleading.

Naturally, measuring the analog output is the test that reflects the final result. Doing such measurements might give a clear picture of how sensitive a particular DAC chip is to jitter or noise at its inputs.

I don't see much measurement of the analog output going on.

> The phrase “operating system jitter” is indeed unfortunate but it was
> IBM that came up with it, not cics and it clearly refers to a separate
> issue, not to “timing uncertainty”. I see no confusion between the
> two concepts.

Let's be clear here. cics cited that article as proof of the effect of software on DAC output. Did he not understand the content of the article? Or did he use it to support his case even though he knew it was not relevant? Neither interpretation reflects well on cics's credibility.

> “[A Memory player] offers a shorter playback chain with fewer devices and
> associated software. This design is most optimal and lends itself to a
> direct 192k I2S DAC chip interface avoiding Firewire/USB, SPDIF or AES.”

cics made an assertion that a shorter chain is better. No proof.

Such an assertion would seem to be improbable as long as the audio bit stream is transferred without change AND the clock the DAC process uses is not tied to input from upstream. A properly implemented Async mode DAC or a squeezebox like device receiving an audio stream over a LAN connection should meet those criteria.

So before we go nuts over yet another improbable assertion, let's see some proof.

> Most optimal headless option (but cumbersome) is to achieve control
> via the printer (or parallel) PC port (using a simple text based
> device or another PC).

I wrote a device driver to receive and transmit audio and video over a parallel port some years ago. The 1284 spec defines some operating modes beyond the simple one-way Centronic output mode. Using them required sensing the exact parallel port and ISA bus DMA hardware. One mode (ECP) used the ancient ISA bus DMA controller and an IRQ for end-of transfer interrupts. ISA bus DMA was dog slow and caused very high overhead on the bus. Other modes didn't provide DMA or an interrupt. I could maage about 23 frames per second in EPP mode with quarter size video; interrupt rates, ISA bus timing and the inherent parallel port data rate were the limitations. It didn't matter how fast the CPU was; the driver had to run a polling loop inside an interrupt routine. Balancing CPU load and frame rate was a delicate, unpleasant task.

I doubt that anyone who knew what's involved in implementing two-way high speed transfers over a parallel port would recommend it over USB or Ethernet for a remote control application. If cics thinks a parallel port is a better medium than a LAN connection, he should explain in detail (and point to some working code.)

> Serial ports and Ethernet should be avoided due to its continuous
> polling nature. Event driven designs are better.”

Both have always been event driven. Serious uses of serial ports have used interrupts since PCs came out at the beginning of the 1980s.

Ethernet hardware has always been buffered and used DMA transfers and End-of-transfer interrupts.

There was a brief period (286 CPUs) when programmed transfer using the CPU was faster than ISA bus DMA transfer. So high speed transfer was often done in a loop inside an interrupt routine or a delayed processing routine or a callback. That era ended a long time ago when the PCI bus arrived.

> It’s a matter of testing a given setup to see if the LAN’s software
> overhead is a worthwhile tradeoff for getting rid of the other crud

That is true of a lot of PC audio tweaks.

> not one of deciding from first principles only.

We aren't talking about first principles here. We just talking about assertions cics makes.

Bill

my blog: http://carsmusicandnature.blogspot.com/

This post is made possible by the generous support of people like you and our sponsors:

The Cable Cooker

---

[ Top of Page ] [ Contact Us ] [ Support/Wish List ] [ Copyright © 2025, Audio Asylum, all rights reserved ]

---

[ General ] [ Speakers ] [ Tubes ] [ Vinyl ] [ Digital ] [ Hi-Rez ] [ Video Asylum ] [ Cables ] [ Tweaks/DIY ] [ Music ] [ Films ]

---