Imac 18,1

[carrelebo]

squeaking, long beep or other sometimes when launching an application,

I think on Ubuntu the snaps cause a problem with the driver, when it gives a long beep, you have to change the socket, for example from internal to external to stop the snapping, see if such sound is produced for several seconds the took of; twitches on gnome terminal when deleting while there is nothing in input etc...(noise), best solution would be to take another desktop environment, or fix tics at times, otherwise it usually works fine

[davidjo]

Are you using headphones? There are known problems with headphones which Im in final stages of testing and will be updating primary repo in a few days.

[carrelebo]

yes, i'm using it, thanks for the answer

[davidjo]

Repo updated with fixes (also includes 18,1 subsystem id so no patching needed) for headphones - should be no squealing, glitches.

[carrelebo]

Thanks, I'm going to try it now !

[carrelebo]

i am currently trying it out on arch linux, sound on headphone works perfectly, no more deafening beeps or sound when sound initializes, perfect, thanks :)

[carrelebo]

@davidjo now that I am very well installed on a distribution that I appreciate, I can resume application development, and it intrigues me enormously to know how to develop a driver for a microphone; even if it is almost unrelated, do you have any documentation or guide that helped you develop the driver for the sound ?

[carrelebo]

there are less often, but the driver encounters the same problem, deafening noise, or beep for initialization noise with the headphones, I think the non-LTS kernel is the cause, I will try with the 5.15 kernel; otherwise no problem with the speakers, it still works as well :)

my kernel and distro : Garuda Linux 5.17.9-zen1-1-zen

[carrelebo]

@davidjo when I try to install the driver to lts kernel install with this command :

sudo pacman -Syu linux-lts linux-lts linux-headers

error :

make -C /lib/modules/5.15.41-1-lts/build CFLAGS_MODULE="-DAPPLE_PINSENSE_FIXUP -DAPPLE_CODECS -DCONFIG_SND_HDA_RECONFIG=1 -Wno-unused-variable -Wno-unused-function" M=/home/carre/snd_hda_macbookpro/build/hda-5.15.41 modules
make[1]: *** /lib/modules/5.15.41-1-lts/build : Aucun fichier ou dossier de ce type. Arrêt.
make: *** [Makefile:22 : all] Erreur 2
cp snd-hda-codec-cs8409.ko /lib/modules/5.15.41-1-lts/updates
cp: impossible d'évaluer 'snd-hda-codec-cs8409.ko': Aucun fichier ou dossier de ce type
make: *** [Makefile:30 : install] Erreur 1

contents of /lib/modules/5.15.41-1-lts/updates
total 0

my kernel verison (lts) : Linux carre-linux-fr 5.15.41-1-lts #1 SMP Wed, 18 May 2022 13:37:06 +0000 x86_64 GNU/Linux

[davidjo]

Ill leave discussion of driver development till later - lots of issues to discuss.

Arch seems to have some issues - and I think I need to update the install script.

As I understand it Arch actually uses /usr/lib/modules/.... and /lib is a symbolic link to /usr/lib - but the install script and Makefile doesnt change its idea of install location and still uses /lib for Arch (which should work if /lib is the symbolic link).

The first error is that it appears /lib/modules/5.15.41-1-lts/build doesnt exist - which Ive had issues with before. On Ubuntu this build entry is a symbolic link to the linux headers directory (which on Ubuntu is a separate package under /usr/src as linux-headers-...kernel version... If this is not found then no module building will occur hence there is no module to install and the final cp command fails. The Makefile explicitly defines this as the build directory because thats what seemed to be needed but maybe the kernel build scripts for external module building have changed. But that means external module building should always fail on Arch yet it appears to work sometimes. I had problems on Ubuntu because it has something called HWE kernels and these kernels dont have a header package so dont have the build link which means the install script will fail to build for HWE kernels without some extra fixups eg creating the build link to the HWE kernel source install (which needs to be installed by a totally different mechanism to the main Ubuntu kernel source code).

[davidjo]

So /lib/modules/`uname -r`/build is still the official linux kernel path from kernel.org for external module building.

[davidjo]

As to driver development:

The reality is I didnt find any good documentation or guide - all of the following is mainly from looking at the existing code. There are multiple examples of very simple driver development but the sound driver(s) and in particular the HDA driver is a very special case.

First, there is no separate driver for the mike - it needs to be a component of this driver.

An HDA chip (designed by Intel) has 2 functions, take a digital stream from the computer convert it to analog (DAC) to send to speakers or headphones plus take an analog input (mike or line), convert to digital (ADC) and send to the computer. There is an Intel HDA specification document online which any HDA chip needs to follow. However I couldnt find any good documentation of the current linux HDA driver and its principles - mostly I just looked at the existing HDA chip drivers.

HDA chips have what are called widgets to perform the above functions plus you can have eg mixer widgets, DSP widgets and vendor widgets which are widgets of functionality decided by the vendor and generally undocumented. The number and type of widgets is not defined so each chip has a different setup. So the driver coders decided to make a "generic" driver which can handle any HDA chip using various data tables which can be configured per chip. This driver is configured by something called the auto parser (hda_auto_parser.c) which reads data from the chips to determine what functions to setup and call (hda_generic.c) which can also be specifically coded by the data tables. These were used in most machines including apple and could be relatively easily configured.

Then Apple/Cirrus came out with the 8409 chip. This chips purpose seems to be to convert the digital computer signal into a digitial audio TDM (Time Division Multiplex) signal for driving external amp chips and chips like the CS42L83 or CS42L42 for headphones plus using the CS42L83/CS42L42 chip to convert an analog input (headset mike/SPDIF) to a digital input signal and then into a digital computer signal. (The internal mike seems to be a direct digital input signal). So this doesnt really fit into the whole generic function system. Plus a lot of the setup of these conversions is done by a vendor widget which is undocumented.

This was a big problem - all the old tricks for getting HDA drivers to work failed (there were a lot of attempts that you can find googling) and theres no documentation. So I decided to try and log the HDA commands (called verbs) OSX was sending to the chip and then replay them under Linux (which involved updating the OSX kernel driver to do the logging). This is what lead to the first sound output. Since then just interative updating as get a better idea of what each group of HDA commands is doing.

This is not driver development as normally understood which should be using the chip documentation to create the driver.

Now as of kernel version 5.13 it appears Dell laptops are using the same chip 8409 plus the documented CS42L42 chip (the CS42L83 seems to be a vendor (Apple) specific version of the CS42L42) which lead to the separate 8409 kernel module.

The mike functionality already exists in this driver (see intmike and headset_mike variables/functions) its just not properly wired into the linux kernel way yet. For me this was something that didnt seem a big priority - and still doesnt.

[carrelebo]

@davidjo "o I decided to try and log the HDA commands (called verbs) OSX was sending to the chip and then replay them under Linux (which involved updating the OSX kernel driver to do the logging). This is what lead to the first sound output. Since then just interative updating as get a better idea of what each group of HDA commands is doing."

What commands did you enter, how do I get them back, and if I also want to produce a sound, how do I do that?

And for archlinux, if I remove the symlink 'lib', the installation will proceed correctly?

[davidjo]

Sorry - dont understand the question about What commands did you enter?. If you are asking about how I got the OSX kernel logs that required creating a modified module in the AppleHDA.kext using dissassembly followed by updating the assembler code. My audio test was just a random sound file but converted to a format the OSX driver can handle directly - in this case has to be .wav and S24_LE - I always used the aplay command when testing.

No - removing the /lib symlink wont work currently as the install script is not modified to use the actual arch path of /usr/lib - if anything you need to make the symlink if it doesnt exist. Your other option is to change the -C path to the full /usr/lib path.

[carrelebo]

for the question is there a way to make a simple "beep" or sound with just a command in Linux ? (without the driver)

[davidjo]

I dont think so - at least for Apple laptop hardware - the only sound devices are the speakers which have to be driven by the HDA chip (my understanding is the speaker amps are connected by a private I2C bus to the HDA chip ie you cant access the amp I2C bus except via the vendor commands of the HDA chip). No teardown I think suggests there is some beep device - but havent really looked at iMacs.