An iDiot's Guide To Lilu and its Plug-ins

[MikeHoward]

@jaymonkey ,

Thank you for the detail in this thread and explanation of AppleALC / Lilu for sound. Wish I got hold of this thread when Mojave was released ! Finally sorted audio LineOut 1 and 2 !

 

[jaymonkey]

Thank you for the detail in this thread and explanation of AppleALC / Lilu for sound. Wish I got hold of this thread when Mojave was released ! Finally sorted audio LineOut 1 and 2 !

Glad you found the guide useful, thanks for the feedback.

Cheers
Jay

 

[pistacio]

Thank you for mentioning HibernationFixup. This may solve the issue I've had since Sierra.

 

[DanZi]

Jay,

This article is awesome, I learned a lot from it Big thanks. Just noticed one thing:

Note-2: The value for AAPL, ig-platform-id is entered (and displayed) in Reverse Byte Order so for the above example of "0x59160000" the correct value is "00001659".

Is there a typeo here with the value? 6159 or 1659?

 

[jaymonkey]

Jay, This article is awesome, I learned a lot from it Big thanks. Just noticed one thing: Is there a typeo here with the value? 6159 or 1659?

@DanZi,

Glad you found the guide useful, thanks for the feedback.

When entering the value for AAPL, ig-platform-id using Clover Configurator we only reverse the byte order, not the bytes themselves so 59160000 becomes 00001659 ...

Cheers
Jay

 

[DanZi]

Always learning something new, haha

 

[Henties]

@DanZi,

When entering the ig-platform-id using Clover Configurator we only reverse the byte order, not the bytes themselves so 59160000 becomes 00001659 ...

Cheers
Jay

Hi @jaymonkey Strictly speaking should it not be reversing the "word" order with the byte order of each word remaining unchanged ? The bytes 5 an 9 of the word 59 as well as the bytes 1 and 6 of the word 16 remain unchanged in their order when one converts from little to big endian and or visa versa.
Please correct me if I am wrong, studied this too many decades ago
Greetings

 

[jaymonkey]

Hi @jaymonkey Strictly speaking should it not be reversing the "word" order with the byte order of each word remaining unchanged ? The bytes 5 an 9 of the word 59 as well as the bytes 1 and 6 of the word 16 remain unchanged in their order when one converts from little to big endian and or visa versa.
Please correct me if I am wrong, studied this too many decades ago
Greetings

@Henties,

I think your getting your bits, bytes and words mixed up ....

On x86 architecture one byte = 8 bits, therefore one byte can have a value between 0 to 255 which in hexadecimal is 00 - FF.
Word size depends upon architecture being used ....

Cheers
Jay

 

[Henties]

Since ig-platform-id is defined as a 64 bit word it's made up of 8 bytes, therefore we reverse the byte order.
On x86 architecture one byte = 8 bits, therefore one byte can have a value between 0 to 255 which in hexadecimal is 00 - FF.

Hi @jaymonkey thanks for your clarification which I greatly appreciate. Eight bits in hexadecimal is indeed 00 -FF but usually represented as 0x00FF. To me however, breaking down the data "representation" of 0x59160000 for the ig-platform-id of a Kabylake based mobile computer reveals the following to me:

0x preceding 59160000 tells me we are dealing with the hexadecimal number system.

With my understanding a hexadecimal number comprises 4 nybbles, each 4 bits long therefore totaling 16 bits or 2 bytes. From a programming perspective 16 bits is called a word therefore the number 59160000 comprises a total of 4 x 16 bit words or 2 x double words. The above applies when viewed from a programmer's perspective and is sometimes also called the "legacy" definition of a word. When this kind of hexadecimal word was "invented" and the computer architecture evolved from 4, 8,16,32 and 64 bit addressable space, the meaning of "word" changed quite drastically and is nowadays also depicting the size of addressable space, as you pointed out quite correctly. Therefore the meaning of "word" depends on whether one is looking at it from a programing point of view or the OS number (computer architecture) point of view.

Below a snippet from "stackoverflow" by Chris Becke.
"WORD is always 16bits, on Win16, Win32 and Win64 platforms."
End snippet.
Confusion rules, but differentiating between an OS view of "word" and a programming point of view, has always helped me to somehow stay sane among this mess.

Greetings
Henties

 

[jaymonkey]

@Henties,

Yes, strictly speaking a WORD is 16 bits, a DWORD is 32 bits (or sometimes known as a long word) and a QWORD is 64 bits.
However this is drifting off topic and in to the world of programming which is unnecessary as we are not treating the value from a programming perspective, we simply need to enter the value in the Data type format used by Clover.

I think the statement "In Reverse Byte order" is perfectly fine, in the given example we treat 59160000 as being made up of 4 bytes and we reverse the order of them, meaning that we take each byte of 59,16,00,00 and reverse the order of them to 00,00,16,59.

I simply wanted to use the most basic statement to cater for all users.

Cheers
Jay