Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Data path: CD vs. computer (Read 2625 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Data path: CD vs. computer

I want to get a somewhat of a BLOCK DIAGRAM mental picture of, say, an " audio bit's point of view", as it moves from a source (file or disc) to the dac chip.

For CD:
disc, laser PU, decoder chip [ancillary RAM chip, as needed], oversampler chip (as needed), dac chip, analog out

For PC, iPhone, DAP, etc:
? --> dac chip, analog out

Please try to fill in as many things as possible -- minus the PCB traces, of course --  for that the music/audio bit "drives" thru on its way home from work (say, SDHC card to earphone).
Linux Mint 64-bit. Intel Core i7-9700K CPU @ 3.60GHz × 8 . Kernel Linux 5.4.0-136-generic x86_64. Memory: 16GB. Mesa Intel UHD Graphics 630 (CFL GT2). Various external USB DACs. Schiit, Topping, etc

Re: Data path: CD vs. computer

Reply #1
Bascally
- any audio file on any storage
- mediaplayer invokes codec
-codec decodes to LPCM
- audio is spooled from memory to audio device e.g. USB DAC
- audio is packed in the UAC1/2 protocol and send over the bus to the USB receiver of the DAC.
The receiver converts back to a protocol the DAC chip does understand (SPDIF, I2S)
TheWellTemperedComputer.com


Re: Data path: CD vs. computer

Reply #3
Bascally
- any audio file on any storage
- mediaplayer invokes codec
-codec decodes to LPCM
- audio is spooled from memory to audio device e.g. USB DAC
- audio is packed in the UAC1/2 protocol and send over the bus to the USB receiver of the DAC.
The receiver converts back to a protocol the DAC chip does understand (SPDIF, I2S)
That's quite a path.
I'm assuming it's a bit different based on OS. E.g. I use Linux and Win and whatever is on my HiBy  RS2 DAP.
I think there are 3rd party options to tweak Win for more "direct" paths, yes?
Linux Mint 64-bit. Intel Core i7-9700K CPU @ 3.60GHz × 8 . Kernel Linux 5.4.0-136-generic x86_64. Memory: 16GB. Mesa Intel UHD Graphics 630 (CFL GT2). Various external USB DACs. Schiit, Topping, etc

Re: Data path: CD vs. computer

Reply #4
A lot of the complexity in a PC comes from its operating system having to cope with potentially multiple sound sources.  Take that bit away, and there's little difference between retrieving data from mass storage and decoding it to then output through a DAC vs. reading data off an optical disc, decoding/dejittering it and outputting it through a DAC.

The big difference in a PC is potentially having to re-sample the audio stream in order to mix it with another audio stream.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Data path: CD vs. computer

Reply #5
The big difference in a PC is potentially having to re-sample the audio stream in order to mix it with another audio stream.

Almost all operating systems are able to handle multiple audio streams. Hence they all have a default sample rate and bit depth. So they all run a mixer and a resampler if needed.

There are ways to bypass this default by getting an exclusive lock on the audio device.
WASAPI/Exclusive in Win
Hogmode in OSX
HW in Linux
Android 14 offers methods to bypass its 48 kHz default
etc, etc.
These tricks do allow for automatic sample rate change at the expense of hearing multiple streams.
TheWellTemperedComputer.com

Re: Data path: CD vs. computer

Reply #6
Almost all operating systems are able to handle multiple audio streams. Hence they all have a default sample rate and bit depth. So they all run a mixer and a resampler if needed.
By "PC" I was not singling out Windows in particular, merely illustrating that it is a process which is missing from a dedicated playback device and probably the most significant difference in the processing chain.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Data path: CD vs. computer

Reply #7
The 48 kHz sampling rate is not the problem, unlike 44.1 kHz the clock is an exact multiple and if you don't want to invest in expensive DACs to contain jitter it is better to resample your audio library to 48 kHz once and for all, like Opus does.

Re: Data path: CD vs. computer

Reply #8
Who said anything about a problem?  The OP wanted to know the differences.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Data path: CD vs. computer

Reply #9
Sorry, it was my deduction, I read "SDHC card to earphone" in the question and "Android 14 offers methods to bypass its 48 kHz default" in Roseval's answer. The block diagram varies according to the type of DAC and the possible decoupling of the signals (oversampling 64x or more is needed for cheap decoupling).

CD have more block due to nature of the ancient DAC, inside a cell phone it's used I2S (or IIS, directly from the SoC, not from the USB bus) and for the integrated speaker (low impedance is required) a mono class D amplifier receive from Delta Sigma converter a PWM signal.

In the case of very cheap products with ARM processors, there isn't even a DAC before the analog output. For headphones there is a different path with more blocks.

In input to the Delta Sigma converter we found always a 1 bit bitstream. I have often read that the signal is recompressed to allow the mixer to add a further input. That's almost never true, I'll use the case of the internal speaker to show what happens.

A now disused way of adding the two channels into a monophonic one (the same applies when you need to mix the stereo audio output with the system sounds) is to take the bitstreams (has no LSBits) from different I2S and send them to a Digital LPF / Decimator, you will get two output PCM signals that will go to a DSP (a Cadence Hi-Fi 4 of couse), will be added to go to a Digital modulator and return to being a Bitstream for the Delta Sigma converter. This way is not smart and I have almost never seen it.

Now you need to know that a First order digital Delta Sigma modulator have always 2 input, the second is the clock (Digital in -> difference with Bitstream out -> adder with Register out -> Register + clock -> Comparator -> Bitstream out).

A more clever way to do it consists of adding the two bitstreams with 1 bit adder, at the output you will obtain a 2 bit signal whose average level still represents the sum of the original input signals. Follow a Digital modulator with Bitstream signal out.

From the SD card, load, decode and output to one or more I2S. The memory involved will not only be the RAM with Ln cache (L1, L2, L3), but also the SRAM present in the ARM SoCs and used for exchanges on the internal bus. There are so many blocks, no one draws them, enormous simplifications are always made (see data book from SoC manufacturer).

In the case of the Raspberry Pi 4, for example, the oscillator is 1.125x48 kHz (54MHz) and the founder boasts of never having spent even 1 cent to put a ADC in it. It has a 40 pin connector from which you can obtain I2S or a SPDIF signal type compatible with the addition of a few components. Raspberry hardware is similar to cell phone hardware and is also used by many digital audio players. PC it's different.

I advise you to shift your attention to how music it's created today, you will no longer want to think about hardware blocks.