DMAS Design [SPDIF-Optical]

[nicegirl05]

so what are we useing? i assumed we were useing those legacy codecs but again our apo drivers do translate to ieee float and pcm depending on the codec so that dose make more sense i even got 6.1 codecs working on my system matrixed but it dosent sound bad at all i wonder if we could use dts or digital plus as a backend for a new codec maybe? weve got the hardware down in and out just need a betta way to transmit the audio then pcm i like it it sounds amazing however most just use dolbys tech so if a mix is dolby digital 16bit it sounds god aweful

 

[Ferather]

It would seem, TOTX1701(F) [Transmitter] and TORX1701(F) [Receiver], else there should not be enough available bandwidth for BMC to do: 2 x 192k 24b (9.216 Mbps).
If the transmission was NRZ, then the older modules at 15 Mbps NRZ would work fine, but its BMC which is 7.5 Mbps, less than 9.2 Mbps.

Its possible to do: 2 x 96k 24b, which is 4.6 Mbps, with the older modules in BMC form, but not 192k.

----

I am using Windows 10, so no 'DTS:X Home Theatre' support, on Windows 11, I would see the extra DTS:X HT option in the format dropdown list with optical.
Regardless of that, you can see (image below) S1220A supports 192k (without downsample), Z906 digital input is up to 96k.

My older ALC 889 used to downsample 192k to 96k, whereas the newer ALC 1220 does actual 192k.
The 889 also shows a black digital jack, whereas the 1220 its optical orange.

----

You will also find information about certain cables not doing 192k, but another does (when both units support it), probably bandwidth, or legacy cables.

====

An expansion on my 7z post, each container-packet can be any size, each one contains a clock and audio data (sorry for the unintended 3D style).



See also (indirect): Packet compression (mentions 7zip).

----

There are other ways to increase bandwidth and convert a 125 Mbps system to 250 Mbps, with advantages and disadvantages.
Also so you know NRZ is also known as PAM2, you can read more information from the link below.

What is PAMx (x=2,3,4…) Signaling Technology? | I-PEX - Note: 125 Mbps, true rate, is more than enough for audio.

----

 

[nicegirl05]

i wonder would this be uncompressed even tho its being sent over optical? with how much these apo drivers are updated i get sound from true hd dtsx any codec dosent matter i even get dolby digital plus over optical i know this due to netflix showing atmos when im not useing hdmi so its piggybacking off of dolby digital plus then being sent to pcm or ieee float

 

[Ferather]

A reiteration of my MDT image above, illustrating a reduced data rate without reduced transmission speed.

 

[Ferather]

I also wonder if a fixed data rate and the time its measured in can be used to determine a 1 bit clock (1x 1 or 0), I was going to show an example but it will probably go into nanoseconds or lower.
Essentially calculate the total bits per second from total Mbps, then keep dividing until there is a 1, for 1 Mbps (1,000,000 bits ps) that should be 1 bit per microsecond.

----

Bit clock:   1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
Data:        1 0 0 0 0 1 0 0 1 1 1 1 1 0 0 1 0 0 0 1 0 1 0 0 0 0 0 1 0 0 1 1 1 1 1 0 0 1 0 0 0 1 0 1 0 0 0 0 0 1 0 0 1 1 1 1 1 0 0 1 0 0 0 1 0 1

The packet clock dictionary code recognition and its interval should be able to be used to correct bit clock variation, if any, ideally fixed rate no variation.

What Is Jitter? - Focusrite

----

I am guessing most of you can imagine a full quality Blu-ray uploaded to a network accessible drive (or fast internet), which is played live.
You will be using network and packet form data, I am thinking along similar lines with the above ideas.


I know streaming services reduce quality in order to reduce bandwidth.

 

[nicegirl05]

some dont reduce quality check out tidal or netflix they use dolby digital plus to compress the audio because of this u dont loose any meta data from the audio however i dont see why we couldnt use truehd with a backup track of plus just in case

 

[Ferather]

Dolby Digital Plus is [lossy], Dolby TrueHD is [lossless], but they are different formats. They use it to compress PCM in the stream to a smaller size.
This is done to reduce the bandwidth needed in terms of internet and streaming, and also storage size for the provider.

Same reason you would store PCM from CD's as MP3 [lossy] or nowadays FLAC (lossless).

 

[nicegirl05]

Dolby Digital Plus is [lossy], Dolby TrueHD is [lossless], but they are different formats. They use it to compress PCM in the stream to a smaller size.
This is done to reduce the bandwidth needed in terms of internet and streaming, and also storage size for the provider.

Same reason you would store PCM from CD's as MP3 [lossy] or nowadays FLAC (lossless).

right so we could use what dolby uses to compress pcm without loss in metadata clockspeed or smaplerate with ddp+ or truehd with a seccond audio track for ddp+ just in case someone dosent have truehd support or do u think we could compress pcm in another way?

 

[Ferather]

They pretty much do that already on Blu-ray (multiple audio tracks), DTS use a DTS Audio core to playback on older systems.
When I mentioned data compression previously, it had nothing to do with compressed audio formats.

 

[nicegirl05]

right but audio formats can help you compress and still achive a decent sound due to volume leveling and audio enhancements those codecs come with not to mention these codecs were made for blueray but in 2024 can be streamed over wifi without a loss in quality or metadata so quality almost onpar with bluerays the only key difference is if the mix artist uses dolby digital plus atmos or truehd atmos due to sample rates a bitrates

right but audio formats can help you compress and still achive a decent sound due to volume leveling and audio enhancements those codecs come with not to mention these codecs were made for blueray but in 2024 can be streamed over wifi without a loss in quality or metadata so quality almost onpar with bluerays the only key difference is if the mix artist uses dolby digital plus atmos or truehd atmos due to sample rates a bitrates

dts u can just use dts-ma and itll sound truely amazing dts is a wild case we could really use any of thare codecs and not get a loss in quality when streaming or bitstreaming cause i see your trying to compress 16 or more channles into optical useing these formats with a live encoder or apo it would be easier to achive with alot of hardware

thats how i have my system running now for full dts/dolby support my media player is useing my custom apo drivers which are a live encoder my media player sees my drivers and my drivers take over due to theme useing live encodeing no matter the codec my drivers well bitstream over optical to my seakers dts dolby flac aac it dosent matter i get the uncompressed signle ieee float or pcm

right but audio formats can help you compress and still achive a decent sound due to volume leveling and audio enhancements those codecs come with not to mention these codecs were made for blueray but in 2024 can be streamed over wifi without a loss in quality or metadata so quality almost onpar with bluerays the only key difference is if the mix artist uses dolby digital plus atmos or truehd atmos due to sample rates a bitrates


dts u can just use dts-ma and itll sound truely amazing dts is a wild case we could really use any of thare codecs and not get a loss in quality when streaming or bitstreaming cause i see your trying to compress 16 or more channles into optical useing these formats with a live encoder or apo it would be easier to achive with alot of hardware

thats how i have my system running now for full dts/dolby support my media player is useing my custom apo drivers which are a live encoder my media player sees my drivers and my drivers take over due to theme useing live encodeing no matter the codec my drivers well bitstream over optical to my seakers dts dolby flac aac it dosent matter i get the uncompressed signle ieee float or pcm

so we could use formats like dolby digital plus or dolby true hd to transcode to a live encoder then pass that to the speaker system

thats what im getting at or we could use a hdmi matrix to send atmos or dtsx thru hdmi to optical again due to how these formats have enhacements built into theme

aswell truehd just uses mlp as its core then adds channels and thangs of that nature so we could use codecs to possibly help with some wild thangs

 

[Ferather]

An expansion of post #55, by adding a bit length dictionary code to the data, it should be possible to define how many bits per code (following).

Bit clock:   1 1 1 1     1 1 1 1 1 1 1 1 1 1      1 1 1 1 1 1 1     1 1     1 1 1 1 1 1 1 1     1     1 1 1 1 1
Length:      - - - -  4  - - - - - - - - - -  10  - - - - - - -  7  - -  2  - - - - - - - -  8  -  1  - - - - -  5
Data:        1 0 0 0     0 1 0 0 1 1 1 1 1 0      0 1 0 0 0 1 0     1 0     0 0 0 0 1 0 0 1     1     1 1 1 0 0

Note that the bit clock is not part of the data signal, its defined based on total transmission rate (bit per x time).
Also note, since the bit length is coded, the stream will look like that in post #55, same rate.


Alternative view: 1 0 0 0 [4] 0 1 0 0 1 1 1 1 1 0 [10] 0 1 0 0 0 1 0 [7] 1 0 [2] 0 0 0 0 1 0 0 1 [8] 1 [1] 1 1 1 0 0 [5]

 

[Ferather]

Bit length dictionary code can its self have a set bit length to match, in addition trailing zeros, possibly nil can be used to fill the remaining bits.
For example, a 16 bit length code could be: 0000000000001010 (trailing zeros), which is simply 1010 (10) in binary.

At the start of each packet, a sync header can be sent in order to calculate the bit clock, again a set size: 0101010101010101.

Bit clock:   1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 - - - - - - - - - - - - - - - -
Data:        0 1 0 0 0 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

Packet data stream: [End][Bits data][Bit length][Bits data][Bit length][Bits data][Bit length][Bits data][Bit length][Sync header]

----

Extra note, optical is immune to RFI-EMI, but there is clock jitter. Copper connections suffer from all three, including crosstalk.

My computer and optical Z906 Class-D, are also isolated in terms of power, aka source immunity.

====

Extra read: https://en.wikipedia.org/wiki/ADAT_Lightpipe

----

 

[Ferather]

Now back to digital compression, in this case digital transmission compression. Bit length code and bits data code can be reduced with encoding (transmission).
Since compression reduces the number of bits used compared to the original, it increases processing at either end (encode-decode).

The expected bit length code size will need to be adjusted, for example now 6 bits down from 16 bits.

----

 

[Ferather]

Return to nil, RTN (3 state transmission):

In cases where nil can be represented, possibly an off state, the nil can be used to define bit length without additional dictionary code.

Bit clock:   1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 - - - - - - S Y N C - - - - - -
Data:        0 0 - 1 0 1 0 - 1 0 - 1 0 1 0 0 0 1 - 1 1 1 - 0 0 1 1 0 0 - 0 0 1 1 1 - 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

Bit clock:   1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 - - - - - - S Y N C - - - - - -
Data:        0 0 - 0 1 1 1 0 1 0 1 1 0 1 0 0 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 1 1 1 - 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

With optical it might be possible to use lumens to define 0 (dim) 1 (bright) and off for nil (state 3).
In terms of copper transmission, volts -, volts +, no voltage, for an equivalent.

----

1 bit code length start/stop (state 3), maximum bit rate (minimum loss to clock), no requirements for bit length dictionary code.
Any code, any length, packet size can also vary if no fixed packet clock measurements are needed.

There should be a reduction in power consumption due to the off state.

 

[Ferather]

Suggested/required: TOTX1701(F) [Transmitter] and TORX1701(F) [Receiver] - 125 Mbps NRZ, 62.5 Mbps BMC.

 

[Ferather]

ADAT Lightpipe:

In order to fit 8 channels within the bandwidth limits of the standard TOSLINK transceiver modules, the bitstream is not biphase mark coded like S/PDIF.
Instead, NRZI coding is used, where a 0 bit indicates no transition and a 1 bit is a transition.
8 audio samples at 24 bits per sample plus 4 user bits (196 bits total) are sent in groups of 4 data bits followed by a 1 bit to force a transition.
This totals 196x5/4 = 245 bits. 10 consecutive 0 bits followed by a 1 bit provide frame synchronization.

One frame is sent at the desired sample rate, a bit rate of 256x48 kHz = 12.288 Mbit/s.

====

PCM: 8 x 24 bit @ 192k = 36.864 Mbit/s.
PCM: 8 x 24 bit @ 48k = 9.216 Mbit/s.

====

Return to nil:

16 sync bits plus a nil *, an additional nil and 2 bits for packet end. 20 bits per packet code: 0 0 - - 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
8 channels at 24 bits per channel sample, 199 bits including nil's: 24b-24b-24b-24b-24b-24b-24b-24b

One packet 192k: 219x192000 = 42.048 Mbit/s.
One packet 48k: 219x48000 = 10.512 Mbit/s.

----

16 channels at 24 bits per channel sample, 399 bits including nil's: 24b-24b-24b-24b-24b-24b-24b-24b-24b-24b-24b-24b-24b-24b-24b-24b

One packet 192k: 419x192000 = 80.448 Mbit/s.
One packet 48k: 419x48000 = 20.112 Mbit/s.

----

* Sync bit length could be smaller.

====

In order to get higher than HDA ~37 Mbit/s for DMAS Optical, CPU-RAM direct is ideal.



Spare bit rate can be spent on metadata packets, with the same container code.

====

108 channels at 24 bits, 108 x 24 = 2592, + 107 nil's = 2699, + 20 bit packet = 2719. 2719x48000 = 130.51 Mbit/s (some compression needed).
With additional transmission compression the total bitrate needed can be reduced, for example 24 bit samples down to 12.



The PCM channels are separated at the channel router.

 

[Ferather]

I forgot there is memory megabit and transmission megabit, so I have adjusted the post above. For transmission its 1,000,000 bits to a megabit.
Compression example, 108 channels: 108 x 12 (24 compressed), + 107, + 20, x 48000 = 68.304 Mbit/s. Fits in 125 Mbit/s.

32 bit or higher is also available, as long as the number of channels fits within the transmission limit.
Lets say the limit was 10 Gbit/s, using another optical system, that's a lot of channels.

----

It should also be possible to use a single 24 bit length to represent 2 channels at 12 bits compressed, 2 x 12 = 24 bit length, reduced nil.

Uncompressed: 8 channels 24 bit 48k | 8 x 24, +7 nil = 199 bits, +20 packet: 219 x 48000 = 10.512 Mbit/s.
Compressed: 16 channels 24 bit 48k | 8 x 24, +7 nil = 199 bits, +20 packet: 219 x 48000 = 10.512 Mbit/s.

Compressed: 108 channels 24 bit 48k | 54 x 24, + 53 nil, + 20 packet: 1369 x 48000 = 65.712 Mbit/s.

----

Metadata packets (if used) would precede audio data, they can specify data is compressed, if compression is not the default for transmission.
An advantage to the additional metadata packet (given the bitrate is free to use), is additional syncing (packet header).

>> [Audio][Metadata] >>

----

Additional note, RTN can be translated to NRZ (PAM2), as long as the stream structure remains the same, and nil is represented (bit ignore).
Given bit interval is constantly being analysed, then any 010 or 101 can be used to update the bit clock or make corrections.

 

[Ferather]

DMAS speakers will have different listed specifications, in comparison to current listed speaker specifications, ohm stats should not be required (internal to speaker unit).
The power supply in the DMAS main unit, is not an audio amplifier, its a power source for the converter (power stage) in the speaker unit its self.

Amplifier-Converter: Class-D Digital, PowerDAC, Other.
Sample Rate: 44.1, 48 | 88.2, 96, 176.4, 192.
Bit Depth: 16-32 Bit, 32 Bit Float.
Frequency Response: X - Y kHz.
Max Power Consumption: X w.
Max Decibels Output: X dB.
THD, THD-N: X %.

If the DMAS supply is not enough with a certain model, an external supply per speaker can be used (digital audio signal is separate).
The main unit could be rated to, for example, 120w per channel, but limit it to 100w per channel, max output.

The speaker unit can attenuate the digital audio signal instead of clip due to power restrictions.

====



Uncompressed RTN transmission, optical input, optical output (speaker out).

====



Optional analogue input support (analogue to digital), digital processing.

 

[Ferather]

I was looking at the DSR series earlier, while they are portable I found the design and implementation interesting.
Analogue to digital, 48 bit processing, digital to analogue. Not sure why no digital input.



Official DSR series specs sheet is here.

 

[Ferather]

Here is a way to allow for stream changes on the fly, for example: sample rate change, by adding an additional metadata packet, which contains the audio specifications.

Transmitter >> [Audio][Audio][Audio][Audio][Audio][Audio][Metadata][Audio][Audio][Audio][Audio][Audio][Audio][Metadata] >> Receiver.

The bit clock will automatically be adjusted by the packet sync bits, in terms of bitrate changes.

====

Example metadata:

Format: PCM
Sample rate: 48K
Bit depth: 24B
Channels: 102
Compressed: No
Compression: 0

Format: PCM
Sample rate: 48K
Bit depth: 24B
Channels: 204
Compressed: Yes
Compression: 12

----

Required bitrate (NRZ, PAM2): 123.312 Mbit/s + Metadata (RTN). Metadata is once per stream.

----

102 (C) x 24 (B) = 2,448, + 101 (nil) = 2,549, + 20 packet bits = 2,569, x 48000 (S) = 123.312 Mbit/s.
204 x 12 (2x12=24) = 2,448, + 101 = 2,549, + 20 packet bits = 2,569, x 48000 = 123.312 Mbit/s.

====

Fun thing to imagine, someone with a 3 state torch, attached to a CPU, which pulses dim, bright or off, and a phone with camera detecting all 3 states, producing 01-.
In theory, the timings would need to be perfect in terms of camera and so on, regardless you could transmit-receive digital code.

 

[Ferather]

In cases where HDMI and-or SPDIF are using a HDA bus (released 2004), maximum available audio bitrate is ~37 Mbit/s due to the bus its self (not HDMI or SPDIF).
Now that USB audio has become a standard, I believe the USB 2.0 audio bitrate is 480 Mbit/s, allowing for full rate, high speed TOSLink.

I am not 100% sure how much transmission bitrate 37 Mbit/s is for HDMI, due to data island periods (it will be more than 37 Mbit/s overall).

====

RTN (raw, uncompressed), 32 channel consumer (based on HDMI):

32 (C) x 24 (B) = 768, + 31 (nil) = 799, + 20 packet bits = 819, x 48000 (S) = 39.312 Mbit/s.
32 (C) x 24 (B) = 768, + 31 (nil) = 799, + 20 packet bits = 819, x 96000 (S) = 78.624 Mbit/s.
32 (C) x 24 (B) = 768, + 31 (nil) = 799, + 20 packet bits = 819, x 192000 (S) = 157.248 Mbit/s.
32 (C) x 32 (B) = 1024, + 31 (nil) = 1055, + 20 packet bits = 1075, x 48000 (S) = 51.600 Mbit/s.
32 (C) x 32 (B) = 1024, + 31 (nil) = 1055, + 20 packet bits = 1075, x 96000 (S) = 103.200 Mbit/s.
32 (C) x 32 (B) = 1024, + 31 (nil) = 1055, + 20 packet bits = 1075, x 192000 (S) = 206.400 Mbit/s.
32 (C) x 48 (B) = 1536, + 31 (nil) = 1567, + 20 packet bits = 1587, x 48000 (S) = 76.176 Mbit/s.
32 (C) x 48 (B) = 1536, + 31 (nil) = 1567, + 20 packet bits = 1587, x 96000 (S) = 152.352 Mbit/s.
32 (C) x 48 (B) = 1536, + 31 (nil) = 1567, + 20 packet bits = 1587, x 192000 (S) = 304.704 Mbit/s.

The ones coloured with orange can be used with high speed TOSLink (125 Mbit/s, NRZ).

----

25 (C) x 24 (B) = 600, + 24 (nil) = 624, + 20 packet bits = 644, x 192000 (S) = 123.648 Mbit/s.

----

48 bits compressed to 24 bits would require the same bitrate as 24 bit (1st example).

Format: PCM
Sample rate: 48K
Bit depth: 48B
Channels: 32
Compressed: Yes
Compression: 24

====

Also note, due to the metadata packet, all formats can be transmitted (bitstream) via RTN.

====

48 Fixed vs 32 Float (sonicstudio.com)

 

[Ferather]

Here is a full duplex multifiber optical cable design, either end connected (no A-B ends). RGB can produce 16.7 million colours based on monitors (Google search).
If we then use lumen level as a multiplier, for example, 2 lumen states: dim-bright, that would be 33.4 million levels (PAM 33.4M ??).

The video lane could easily be 100 or more Gbit/s, audio 1 Gbits/s, and data 10 Gbits/s. Higher at a later stage.

----

Basic examples:

>> [Data Block 3, NRZ-RTN][Data Block 2, NRZ-RTN][Data Block 1, NRZ-RTN] >>

Bit clock:   1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 - - - - - - S Y N C - - - - - -
Colour:      R B - R B G R - G R - G R B G R B G - B G R - G R B G R B - R B G R B - R B G R B G R B G R B G R B G R
Data:        0 0 - 1 0 1 0 - 1 0 - 1 0 1 0 0 0 1 - 1 1 1 - 0 0 1 1 0 0 - 0 0 1 1 1 - 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

Bit clock:   1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 - - - - - - S Y N C - - - - - -
Colour:      R B - R B G R B G R B G R B G R B G R B G R B G R B G R B G R B G R B - R B G R B G R B G R B G R B G R
Data:        0 0 - 0 1 1 1 0 1 0 1 1 0 1 0 0 0 1 0 1 1 1 0 0 0 1 1 0 0 1 0 0 1 1 1 - 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

----

Currently in the UK via BT (and possibly others using BT such as TalkTalk), I would need to upgrade from 1 Gbits/s ethernet to get full speed.
Home consumer BT is now ~1.6 Gbits/s, so to make full use of that, hardware (including switches) need to be upgraded.

Note: 400 Terabit/s = 400,000 Gigabit/s.

----

Now I am thinking about an optical compute unit and optical memory, given the 63 Thz bandwidth available to a single fiber.
1 Thz = 1,000 Ghz, so 63,000 Ghz. How that could be implemented I am not sure, would need optical traces.

Optical computing - Wikipedia

en.wikipedia.org

Digital age (era) > Light age (era).

----

 

[Ferather]

It's also possible to use colour and lumen multiplier to do encoded transmission, which is separate from base data compression.
There is also enough colours (with multiplier) to represent all characters on a keyboard in a single bit (each).

Ultimately in terms of power, the maximum wattage would be all 3 RGB emitters at full.
Probably somewhere around the watts needed to power one pixel.

----

Additional note, GaN instead of MOSFET, even with a Class-D digital amp, which I would prefer to see PAM instead of PWM.
Eventually the GaN and PAM method can be expanded into a PowerDAC using PAM, ideal for the DMAS.

----

Interesting topic to research is the invention of blue LED's and the materials used.

GaNFET vs MOSFET | The Invention of Blue LED's

 

[Ferather]

To expand on the basic optical keyboard concept, lets say we needed 110 keys (including some extra) with a specific keyboard, that would need either 110 colours or 55 colours + 2 lumen states.
At this point its not really ideal to call it digital, since each colour represents a key and not binary code (0,1). A bitrate specification can still be used for comprehension.

I really doubt anyone could press 1000 keys in a second (1000 ms), so, 1000 changes per second (bits) is more than enough for a optical keyboard.

Multikeys should merge into another unique colour, given each key has its own base colour.

----

If we then expanded into 16.7 million colours and various lumen states, a single bit time can express a very large binary sequence in the digital sense.

An auto clocking sequence could be as follows: O-L-L-E-H, this includes the off state (-) to define the bit time.

 

[Ferather]

125 Mbits/s (based on TOSLink): 125,000,000 / 1000 = 125,000 bits per 1ms | 125,000 / 1000 = 125 bits per 1us | 125 / 1000 = 0.125 per 1ns, x 8 = 1 bit per 8ns.
If we then used RGB, the 8ns bit time can represent more than just 0,1 as mentioned above. At 125Mbits/s the bit clock should be 8ns.