Windows based Media Server: Experiences & Insights

[cpt_paranoia]

Packet-based interfaces, such as Ethernet & USB, separate the packet timing from the DAC sample timing; the DAC FIFO buffer does this.

Most PC audio subsystems will also be packet-based, often using two levels of FIFO buffering (one in hardware, one in the software driver).

Software is not used to control individual sample timing to a DAC. You will note that the LatencyMon software warns about stuttering and skips; this is caused by the software failing to service those FIFO buffer service requests, resulting in buffer underflow. How the FIFO deals with that varies; some will repeat samples, some will output zero samples.

Network renderers take this packet-based operation even further, by receiving CODEC files (rather than raw PCM) under some streaming protocol (e.g. DLNA, Airplay, Chromecast, RAAT, etc). They reconstruct the encoded file, decode it to PCM, and then send it to the DAC via a FIFO buffer.

 

[SimplySound]

Network renderers take this packet-based operation even further, by receiving CODEC files (rather than raw PCM) under some streaming protocol (e.g. DLNA, Airplay, Chromecast, RAAT, etc). They reconstruct the encoded file, decode it to PCM, and then send it to the DAC via a FIFO buffer.

That makes a lot of sense, I haven't played around with anything like DLNA. I guess PlayFi weaned me off of any type of network distribution approach. But I get it, if there is a built-in CODEC for conversion to a PCM Stream then that fixes any timing issues!

Packet-based interfaces, such as Ethernet & USB, separate the packet timing from the DAC sample timing; the DAC FIFO buffer does this.
Most PC audio subsystems will also be packet-based, often using two levels of FIFO buffering (one in hardware, one in the software driver).

However, many folks think buffers cure everything, when in reality they can present their own issues. Timing in the packet build itself is critical, and I guess that is what I'm getting at. This guy does a really good job of describing what's going on in a PC (Note: the Audio Processor is where ever your DAC resides).

https://pixeleuphoria.com/blog/index.php/2021/02/04/the-basics-of-streaming-audio/

So this brings up buffer under-runs (aka: micro-stuttering). Do we hear micro-stuttering? Is micro-stuttering even a thing? Thoughts?

 

[cpt_paranoia]

Timing in the packet build itself is

There's no timing in the packet build; it is just a collection of samples, a block of data in memory. Timing is only applied when the packet is delivered, sample by sample, to the DAC. The rate at which samples are to be extracted from the packet should be included as part of the packet protocol.

The only timing problems are the sampling jitter when the original recording was made, and the sampling jitter in the DAC. Everything else in between is purely logical data transport, provided packets arrive in sequence, and when they are needed; if not, you get stuttering, and that is a gross failure of your data transport.

Yes: underflow can happen if you don't service the FIFO packet request in time, but the result is fairly obvious stuttering. Funnily enough, my little laptop stuttered when I was running LatencyMon with MusicBee running. Turned off LatencyMon, and all was well again... The only other time I have had stuttering is when streaming Tidal, as their awful UI consumed huge amounts of processor to draw a progress bar on the screen; minimising the UI reduced the CPU to something sensible. To be fair, their technical team responded quickly, and sent me fix builds to try out.

 

[SimplySound]

I think I'm getting ya... I'm thinking quantization is done via the player, when in fact it is part of the DAC (Unless the player is doing some sort of re-sampling, but we'll assume bit perfect transmission).
So you are saying there is no such thing as a micro-stutter that could cause a distortion so small it sounds like temporal blurring?

 

[cpt_paranoia]

I'm thinking quantization is done via the player, when in fact it is part of the DAC

When it comes to PCM samples, or CODEC stream, if there is no upsampling being done, then there is no quantization performed; the quantization to PCM occurs at the source. Thereafter, it is just data shuffled around as data packets, until it gets to the interface between FIFO & DAC (i.e. the DAC data interface).

I can only think that your diagram refers to a serial data interface to a DAC, such as SPDIF, where the clock must be recovered from the biphase encoded signal.

All digital signals involve some degree of 'quantisation', but this is generally logic threshold detection, or symbol extraction from more complex, multi-bit symbol eye patterns. Again, this involves clock recovery using phase-locked loops; operating with narrow loop filters (or dynamic loop filters that widen to lock, and then narrow to track) that can achieve very good results, and a clean clock. But never as good as a pure crystal oscillator.

As for 'microstutters', well, if you've got latency issues that prevent the FIFO being serviced, the most likely result is that there will be a broad spread of service response times. This will give clearly audible pops and glitches. It is possible that services only just fail to be performed timely, that might cause very short stutters, but the probability is rather low, given the variability in ISR times normally found in non real-time software (as can be seen by LatencyMon). It would very much be an edge case between 'working well' and 'broken' (which stuttering must be considered).

 

[cpt_paranoia]

BTW, that description you have posted above bears little resemblance to a digital audio chain; there really aren't any 'regenerative repeaters' in a home audio chain; just simple logic decoding. The mention of 'channel' and 'regenerative repeaters' suggests someone is conflating long-distance transmission, such as trans-continental links.

But digital transmission applies multiple levels of encoding to separate the physical layer of the channel & regeneration from the logical information; provided bits can be recovered from the physical layer (within the bounds of the error protection layer), the logical information is received perfectly. That's the whole point of digital systems. Long-distance comms systems like that don't use the channel to carry timing at the logical information layer; that is done by the protocol (e.g. encoding the sample rate in some file or packet header at the logical level). The receiving end then provides the timing to be used with the logical information (like the extraction from FIFO to DAC that I discussed above). This concept can also be applied for local network comms (e.g. between devices over USB, or Ethernet, etc), and is used in network streaming audio interfaces, and USB.

Now, real-time audio or video digital communication over such a link has to cope with imperfectly matched clocks at transmit and receive ends. VoIP achieves this by allowing repeat or drop of audio packets (since VoIP is a relatively low quality service, this is acceptable). This situation is called plesiochronous clocking:

Plesiochronous system - Wikipedia

en.wikipedia.org

 

[cpt_paranoia]

I tried to search for some basic primers on the use of FIFO buffers to separate processor timing from ADC/DAC timing, but my Google-fu is weak. I've been implementing such interfaces many times in my career, so it all seems obvious. This TI primer, although discussing much higher sample rates, describes the basic principle:

https://www.ti.com/lit/an/sdma003/sdma003.pdf

The FIFO becomes a temporal isolation barrier, decoupling the processor response timing from the DAC timing. The CPU writes a block of data to the FIFO, in response to a service request. The DAC side reads data from the FIFO (aka an 'elastic buffer') at a regular rate. The FIFO content rises and fall between writes and reads. The FIFO monitors the level, and issues a service request when it hits some threshold. In a simple case, the write block size is half the size of the FIFO, and the request threshold is 'half full'. This allows the CPU sufficient time to service the request; it can respond at any point between the FIFO reaching half full, and empty. If it fails to respond by this time, underflow occurs; a failure.

For digital audio, underflow is an annoyance, and the system can be allowed to recover automatically, and carry on (though care must be taken to write enough data to the FIFO to ensure the threshold mechanism restarts. For a system using such a FIFO to generate an RF channel, in some multiplexed access RF protocol (e.g. TDMA), the loss of FIFO coherence will disturb the RF slot timing, potentially causing splatter in adjacent timeslot channel. Thus, underflow will often trigger a channel restart, re-acquiring synchronisation with the RF channel timing.

 

[SimplySound]

Hey CPT, thanks for your insight, you have a much deeper understanding of DSP than I do, no doubt! And I want to thank you for helping me understand Digital Audio presentation much better and specifically the aspect of interface between a renderer (player) and a DAC. Hopefully others are learning as we go.

However, something has me a bit confounded and this is my conundrum; maybe I'm conflating things, but you seem to be of the opinion that the PCM Data stream, packet, feed, whatever we want to call it, is logically separated from any type of timing interference as it makes its way to the DAC buffer. Be it from the player unloading the file container to present PCM or over the interface itself.

There's no timing in the packet build; it is just a collection of samples, a block of data in memory. Timing is only applied when the packet is delivered, sample by sample, to the DAC. The rate at which samples are to be extracted from the packet should be included as part of the packet protocol.

So, help me understand this; why when Amir did a 'Deep Dive' into HDMI interfaces back in 2016 he found that jitter (noise, phase distortion?) was significant enough with HDMI to provide this advise?

If you have an AVR, using a high quality asynchronous USB to S/PDIF adapter may be one of the best “tweaks” you can use to improve its performance (for music applications). My advice is that if you are using your system for critical music listening, use S/PDIF instead of HDMI. If you are using a PC or Mac as the source, invest in a high-quality USB to S/PDIF converter.​

This seems to indicate that something within the interface can indeed impact the PCM data. Again, maybe I'm conflating some technical elements of digital noise with phase (timing) distortion. But if the signal can be impacted on the interface, why wouldn't it make sense that it might also be impacted during the render to PCM within the player itself (via switching noise within the PC or by interrupts during processing within the CPU)?

Again, thanks for your time helping me with my discovery. I do appreciate it!

 

[SimplySound]

Maybe this answers my own question? Does switching to an asynchronous interface like USB have the DAC driving the PCM source (PC timing)? I always thought that was considered synchronous, but I'm beginning to realize that may not be the case.

Interface jitter​

Most of the time the DAC is slaved to the sender.
It must read the data at the same rate the source is feeding it.
In case of a non-buffered input, it is almost directly coupled to the clock of the sender.
In case of a buffered input, speed adjustments are necessary to avoid buffer over/under flow.​

​

Techniques to cope with input jitter (ranked from low to higher effectivity):​

​

There are a few main techniques for dealing with interface jitter:​

• Ignoring it altogether.
• Using a PLL to filter the interface jitter, providing a cleaner version of the clock reconstructed from the interface to the DAC.
• Using an Asynchronous Rate Converter ( ASRC ) to manipulate the data such that it "fits" in the two clock domains
• Using the DAC clock to drive the clock in the source ( "asycnchronous" modes - async USB, async firewire, most ethernet solutions, some kind of link from DAC to source )

Asynchronous USB​

USB or Firewire in asynchronous mode let the DAC times the data out of the PC.​

​

If the DAC uses a high quality XO, low jitter will be the result.​

​

The emphasizes is on the word ‘if’
Asynchronous USB with a simple frequency synthesizer will probably sound worse than a good adaptive mode implementation.
Asynchronous mode sec says nothing about sound quality, it is the way it is implemented which counts.​

​

This comes from the Well Tempered Computer: https://www.thewelltemperedcomputer.com/KB/BitPerfectJitter.htm

 

[cpt_paranoia]

So, help me understand this;

You are now talking about something completely different; that has nothing to do with 'packet build timing' (provided I have understood what you meant by that).

As for Amir's article, the first thing that stands out to me is this statement:

"There is an unwritten rule about the design of consumer electronics equipment that says the source is the master."

That is not universally true; in a CD players, the DAC is the timing master, and the CD mechanism is a slave to that, with the servo mechanism locked into the CIRC FIFO content monitor. Sony and Philips engineers knew what they were doing. For systems connected via SPDIF, yes, the source is timing master, because the clock is embedded in the data stream. That's why I consider SPDIF to be technical backwater that really should never have happened, but it was convenient... Maybe marketing got involved, and convinced the engineers to come up with a 'well, if you really must, do it like this' solution...

HDMI is source-clocked, because HDMI was developed in the days of broadcast video; the destination can't tell the broadcast source to speed up or slow down. The destination has to slave to the source.

The rest of the article, having only skim-read it, looks fine, with reasonable discussion of source/destination clocking and associated jitter, and the noise tests.

As for why HDMI performed so poorly in his tests, I would suggest that it is down to the fact that HDMI receivers are more concerned with video (which has its own timing mechanism of the screen refresh rate, which humans really don't care much about, and 'jitter' on frame refresh is imperceptible. Hell, beyond about 16fps, we don't notice it's a series of still images), and the audio processing is rather neglected, compared to a pure audio device.

The fact that an HDMI signal, simply connected to an HDMI-input DAC, increases the noise, is a testament to the poor digital interface design, since the multiple digital signals carried over HDMI (rather than single signal of SPDIF) are allowed to pollute the audio output. That, to me, is a fundamental design failure, since the DAC digital input circuitry should not allow interference, or digital noise (due to the actual wanted digital signal) to get to the output.

It would be instructive to repeat those tests with one of the DACs using the HDMI physical connectors (rather than the HDMI protocol) to carry I2S. My guess is they won't have the same problem with interface noise coupling to the output.

So, given a choice between a poor HDMI implementation, and a good SPDIF implementation, the better choice is SPDIF.

But that is down to poor implementation, and not to do with the fundamentals of digital design.

As for "If you are using a PC or Mac as the source, invest in a high-quality USB to S/PDIF converter.", I would say 'invest in a DAC with a native, asynchronous USB interface, and use a protocol that allows the DAC to be timing master, and the source a slave. Converting to SPDIF is a degraded timing solution.

 

[cpt_paranoia]

Does switching to an asynchronous interface like USB have the DAC driving the PCM source (PC timing)?

I've been banging on about this for ages, including in my many replies to you...

And in my mini-article about digital streamers & audio quality:

Digital Streamers & Audio Quality

The following are some thoughts on the factors that might affect the audio quality of a digital-only streaming system. Firstly, we need to be clear of the functions that a digital streamer performs: network interface to receive the stream using one of a number of protocols (e.g. DLNA, CCA...

audiokarma.org

Eliminating Timing Noise with a Destination-Clocked Digital Interface
Timing noise on the DAC interface can be eliminated by separating the data interface transfer mechanism from the DAC sample clocking. This is done in destination-clocked interfaces, such as 'asynchronous USB', or destination-clocked I2S. In both of those cases, the streamer is a slave to the DAC clock, sending data when requested (exactly as it is in an integrated CD player). Some form of FIFO buffer separates the two clock domains (digital interface domain and DAC clock domain). This method provides a causal barrier between timing noise on the digital interface, and timing noise on the DAC clock; the level of DAC clock jitter is determined entirely by the DAC implementation, although electrical noise coupled to the DAC from the streamer can have an influence on this aspect of DAC performance.

 

[cpt_paranoia]

The fact that an HDMI signal, simply connected to an HDMI-input DAC, increases the noise, is a testament to the poor digital interface design, since the multiple digital signals carried over HDMI (rather than single signal of SPDIF) are allowed to pollute the audio output. That, to me, is a fundamental design failure, since the DAC digital input circuitry should not allow interference, or digital noise (due to the actual wanted digital signal) to get to the output.

I also identified the digital interface of a DAC as being critical to quality:

Noise on DAC Digital Interface
However, transmission of the digital sample stream to the DAC requires a physical interface to the DAC. This physical interface can carry noise from the streamer to the DAC. This noise is generated by, or externally coupled into, the electronics within the streamer. This noise may make its way to the analogue output of the DAC. Thus, there is potential for variation between performance for streamers using different hardware for the entire streamer.

Role of the DAC
Part of the role of a DAC is to ensure that noise on its digital interface does not make its way to its analogue output. How well it achieves this will depend on the quality of the design of the DAC, and the level of noise it has to deal with. Think of the DAC as a noise filter, able to attenuate noise by x dB.

 

[SimplySound]

WOW! look what I just stumbled upon, maybe THIS is what is going on! From: https://www.thewelltemperedcomputer.com/KB/USB.html

The perfect solution​

Asynchronous USB looks to be the perfect solution.​

You configure your PC for bit-perfect output and the DAC takes care of the timing totally independent of the timing of the PC.​

But there are posts on the Internet claiming that even in the case of an async USB DAC what is happening upstream is still affecting sound quality.​

​

One issue with USB is that it sends regular bursts of info like the start of frame packet - "The SOF packet consisting of an 11-bit frame number is sent by the host every 1ms ± 500ns on a full speed bus or every 125 µs ± 0.0625 µs on a high speed bus". If the timing of this shifts or is variable, this could elicit a different & variable reaction from the USB receiver & translate into a different & varying jitter or noise spectrum. Making the PC end as solid & stable as possible without undue processing could be one factor in ameliorating this variation. It might not be the low level of jitter that we notice but the variation in jitter - that's one reason why I say that the measurements we currently run seem not to be capable of picking up these issues or we are not directing them to the correct target for measuring.​

 

[cpt_paranoia]

maybe THIS is what is going on!

If it is, then is is a failure of the USB electrical interface to isolate digital noise from the analogue circuitry (including the DAC clock).

Asynchronous USB protocols should not rely on packet timing (that's what the 'asynchronous' bit means). The protocol uses the USB data bursts to carry FIFO packets, and write them to the FIFO. The DAC takes data from the FIFO, as I explained above. The FIFO completely isolates the USB clock domain (packet timing) from the DAC clock domain (DAC sample timing).

 

[SimplySound]

It would be instructive to repeat those tests with one of the DACs using the HDMI physical connectors (rather than the HDMI protocol) to carry I2S. My guess is they won't have the same problem with interface noise coupling to the output.

Yeah, I get ya, seems like establishing an I2S standard could be a solution, but that isn't there yet.

As for "If you are using a PC or Mac as the source, invest in a high-quality USB to S/PDIF converter.", I would say 'invest in a DAC with a native, asynchronous USB interface, and use a protocol that allows the DAC to be timing master, and the source a slave. Converting to SPDIF is a degraded timing solution.

And this also sounds relevant, but given the SOF buffering element identified above, even a direct asynchronous USB interface may have some issues even if S/PDIF isn't the solution.

Great times to be into Digital Audio, isn't it!

 

[SimplySound]

If it is, then is is a failure of the USB electrical interface to isolate digital noise from the analogue circuitry (including the DAC clock).

Well, this gets back to, in your parlance, is it 'broken' or is it a feature?

 

[cpt_paranoia]

Well, this gets back to, in your parlance, is it 'broken' or is it a feature?

It's an implementation limitation. In reality, the degree by which a digital interface isolates its noise from the analogue section is always going to be an engineering compromise; a matter of how many dB rejection is achieved, and how, and how much that costs to achieve; that's why I identified it as an area that a digital server could spend money on to achieve genuine improvements.

Failing to respond to a service request before the FIFO goes empty falls into 'broken', though.

 

[cpt_paranoia]

Yeah, I get ya, seems like establishing an I2S standard could be a solution, but that isn't there yet.

The standard doesn't matter; it is the mere fact of using an interface with multiple high speed digital signals on it (like a genuine HDMI protocol interface). That allows a reasonable comparison between two interfaces, using similar physical bearers, but different implementations.

 

[SimplySound]

This is interesting...

Isochronous transfer mode uses error-checking but includes no re-transmission in case of Cyclic Redundancy Check (CRC) errors. Electrical noise on USB signals causes CRC errors and thus data loss, as does poor signal integrity. In mild cases, this leads to audio signal distortions. In the worst cases, clicks and dropouts. It means that a USB audio device can work correctly only if USB signal quality is excellent and no CRC errors occur. ​

Note: Do not confuse ‘asynchronous USB’ with ‘Isochronous,’ an asynchronous USB system still uses Isochronous mode to transfer audio.​

​

They bring up 'Electrical noise', but it makes me wonder about system interrupts. And I guess I wonder if a requirement might be to get average process latency below 125micro-sec to make sure the Frame Buffer can be serviced in a timely manner. But who knows?

 

[SimplySound]

At this point I seem to be running pretty efficiently. LatencyMon after about 30 mins playing music. Consider this a benchmark for the tweaks listed.