Audio in Linux

[RoGeorge]

Thanks for the details, it looks too complicated.

Even if it were for those patches to fix my problem, which they might not, I don't really need a patch fix.  Given that I only needed that once in many years, to measure some circuit, I could simply boot in FreeBSD and measure from there, or from Kubuntu I could use the Mic2 input (which is in fact line-in) and pipe the datastream to the stdin with arecord, then take it from there and display spectrum and distortions with existing tools like 'baudline', like this:

Code: [Select]

        systemctl --user stop pulseaudio.{socket,service}
        # !!! line-in CA0132 only working after VLC is started with CA0132 as sound device
        #     then it keeps working even when VLC is stopped, some initialization problems ???
        # Others observed CA0132 working only after rebooting from Windows to Linux
        #     i.e. last reply from baxter_stockman https://forum.level1techs.com/t/creative-core3d-audio-linux-support/112295/9

        arecord -D hw:2,2 -B 10000 -r 96000 -f S16_LE -c 2 | ./baudline -stdin -record -channels 2 -format le16
        systemctl --user start pulseaudio.{socket,service}

[magic]

Run alsamixer and try setting volume and unmuting relevant channels and selecting the input source. Press F4 to see the recording controls instead of playback.

[PKTKS]

Thanks for the details, it looks too complicated.

Even if it were for those patches to fix my problem, which they might not, I don't really need a patch fix.  Given that I only needed that once in many years, to measure some circuit, I could simply boot in FreeBSD and measure from there, or from Kubuntu I could use the Mic2 input (which is in fact line-in) and pipe the datastream to the stdin with arecord, then take it from there and display spectrum and distortions with existing tools like 'baudline', like this:

Code: [Select]

        systemctl --user stop pulseaudio.{socket,service}
        # !!! line-in CA0132 only working after VLC is started with CA0132 as sound device
        #     then it keeps working even when VLC is stopped, some initialization problems ???
        # Others observed CA0132 working only after rebooting from Windows to Linux
        #     i.e. last reply from baxter_stockman https://forum.level1techs.com/t/creative-core3d-audio-linux-support/112295/9

        arecord -D hw:2,2 -B 10000 -r 96000 -f S16_LE -c 2 | ./baudline -stdin -record -channels 2 -format le16
        systemctl --user start pulseaudio.{socket,service}

It does not seem from here a patch problem... but a proprietary firmware blob issue

issue a modinfo to see which firmware blob required

Code: [Select]

>modinfo snd-hda-codec-ca0132
description:    Creative Sound Core3D codec
license:        GPL
firmware:       ctefx-r3di.bin
firmware:       ctefx-sbz.bin
firmware:       ctefx.bin
alias:          hdaudio:v11020011r*a01*
depends:        snd-hda-core,snd-hda-codec,snd,snd-pcm
intree:         Y
name:           snd_hda_codec_ca0132
vermagic:       4.19.136 SMP mod_unload K8


fussing my firmware  repos I have none of them
firmware:       ctefx-r3di.bin
firmware:       ctefx-sbz.bin
firmware:       ctefx.bin

Not for my stable 4.xx branch ... and obviously not for the in test 5.xx SMP tree..
Paul

btw... this a typical case why  it works on winzzz (they paid support from oem and have in tree blobs) and does not for other customers which bought their card outside the winxx club...

classic case of defective by design CERTIFIED - only works with...

[DiTBho]

this a typical case why  it works on winzzz (they paid support from oem and have in tree blobs)

that's the same for Android, e.g. what Allwinner does with - at least - blobs for ther Thermal Units and GPUs: affected H3*, H5*, A64* SoCs

[Nominal Animal]

Since I have microcontrollers with native USB (Teensies) that can do 1 Mbyte/s across an USB isolator by default using USB Serial in Arduino/Teensyduino, that's probably what I'd use.  Teensy LC and 3.1/3.2 have 16-bit ADCs with 12-13 bits effective, although I do also have an ADS1256 board that can do 30kSamples/s at 18-23 effective bits per sample.

The local computer store (Verkkokauppa.com) sells Delock 61645 USB 1.1 Audio dongle for 16€.  It supports 48 kHz sample rate at 16 bits per sample, mono input, using CMedia CM119 chipset (one of those all-in USB chipsets).  It implements USB Audio 1.0, so uses the standard USB audio drivers, not anything custom.  That is good.  It would be cheap enough to take apart, IMO, to use as a simple one-channel el-cheapo "DAQ".  (It might have microphone boost – a bias voltage – always on, but since the datasheet is available, it'd be a fun project to mangle it beyond recognition.  It also has I2C one can use to access its internal registers from a separate microcontroller, you see.)

In all cases, I'd run the "data aquisition" over USB, using an el-cheapo USB isolator (ADuM3160/4160), because me being me, I probably will do something stupid or accidentally short some parts that Should Not Be Shorted, so all I'd lose at most was anything dangling off the USB isolator.  For best results, I'd not use the downstream DC-DC 5V, but batteries instead –– maybe 9V, maybe 5-7 AA batteries or accumulators in series, followed by a 5V regulator, to minimize supply noise.

There are some sellers of Analog AD7705 break-out-boards with LM285-2.5 reference voltages in Europe on Ebay, with 4.9152MHz crystal oscillators (therefore very good sample rate stability as well), which should do 76.8kHz sample rate at 16 bits per sample at even unity gain (0 to 2.5V).  (With 8× to 128× gain, 614.4kHz.)
With larger voltage swing, I'd add an op-amp buffer and a voltage divider in front, though; I'm not sure how good its internal buffer op-amp is (it can be disabled).  It has a SPI interface (400 kHz to 2.5 MHz clock frequency), so you obviously need a microcontroller to interface to one.  Teensy LC does have a real 12-bit DAC on it, so if I used that one, I could wire one of the AD7705 inputs directly (via buffer and/or voltage divider and possibly a low-pass filter, maybe) to that, to verify the actual performance characteristics.

Or I could use the Analog Discovery 2 that I have.

Me being me, if I were to use the built-in audio line-in directly, I'd for sure poke something with something conductive and release The Magic Smoke.  That's why I always keep at least one el-cheapo USB isolator at hand: I use them even when just playing in Arduino/Teensyduino with one of my microcontrollers.  You know, like belt and suspenders: it may look silly, but at least my trousers stay up.

[PKTKS]

Apparently ALSA team folks manage to get some blobs

https://forums.opensuse.org/showthread.php/542035-No-sound

I will download the version and check asap...

All folks with similar chipset have the same issue

Paul

PS piece of cake... they hardly miss a thing.. the blobs are on the referred package and should be manually installed

[DiTBho]

Analog Discovery 2

That's a great kit for low frequency projects! I will buy one soon, too! 

[RoGeorge]

Meanwhile:
- tried a live disk with Ubuntu 20.04 LTS to check against possible missconfigurations/leftovers on the native install, sound behavior with the live disk is the same as in the native install
- tried from a live pendrive the latest Pop!-OS 22.04 LTS, which is a distro based on Ubuntu 22.04 LTS, but customized and with a more recent kernel than Ubuntu, nope, same problems
- tried to replace ALSA (from Kubuntu 20.04 LTS) with native OSS4 (nota alsa oss emulation), and I couldn't, got no sound at all and installed back ALSA

- found out that there is some flags called "Quirks" in the driver sources, i.e.:
https://github.com/torvalds/linux/blob/master/sound/pci/hda/patch_ca0132.c

Code: [Select]

            /*
            * CA0132 quirks table
            */
            enum {
                QUIRK_NONE,
                QUIRK_ALIENWARE,
                QUIRK_ALIENWARE_M17XR4,
                QUIRK_SBZ,
                QUIRK_ZXR,
                QUIRK_ZXR_DBPRO,
                QUIRK_R3DI,
                QUIRK_R3D,
                QUIRK_AE5,
                QUIRK_AE7,
            };
Those names are in fact sligtly different models/boards of the same Creative Core3D chipset, and they seem to map the audio connectors and other hardware capabilities to each model.

It seems the proper Quirk is autodetected by looking at the chip ID, but I suspect the Quirk model can be forced from config files, probably from '/etc/modprobe.d/alsa-base.conf'.  There might be possible to add a line there ''options snd-hda-intel model=?my_particular_chipset_config?" but I'm not sure what to write there, the int from the enum, only the commercial name, or full C name from the enum.  I've tried with "model=r3d" and "model=alienware", then rebooted, but I see no changes.


Another aspect that intrigues me is that in the 'patch_ca0132.c' sources the sampling can be up to 384kHz, but in OSS/FreeBSD the rec sampling is 48kHz, and in ALSA/Kubuntu can be max 96kHz. 

Oh, and I still couldn't find how to change between 16/24 bits sampling.  The number representation doesn't affect the sampling depth, even with arecord numbers format u8, the dynamic range seems to be the same, with a noise floor somewhere around -110...-120dB, which suggests the ADC sampling depth might be 24 bits.

... el-cheapo "DAQ"...

That's exactly what the sound card was supposed to be, el-cheapo audio DAQ yet with outstanding specs (lower noise than I would achieve breadboarding my own DAQ, and 24bits/96kHz, plus countless software tools to handle the data).

Well, except that Creative for sound is like nVidia for video, when it comes to Linux, and this desktop have them both. 

[RoGeorge]

Analog Discovery 2

That's a great kit for low frequency projects! I will buy one soon, too! 

At some point I was tempted too, but I found it quite expensive, and I already have similar or better devboards.  From those searches for similar educational boards, I remember the ADALM1000, from Analog Devices.

ADALM1000 was about 5 times cheaper, and it is in fact a dual SMU 5V/100mA that can play and record quite fast, which is a nice tool to have around the lab.

There is a newer model, ADALM2000, has more gimmicks and it's more expensive, but it lost its SMU specs, to me ADALM1000 was more tempting (but didn't buy).  Both versions have plenty of ADI classes and labs examples, just like Analog Discovery eduboards have, too.

[magic]

It seems the proper Quirk is autodetected by looking at the chip ID, but I suspect the Quirk model can be forced from config files, probably from '/etc/modprobe.d/alsa-base.conf'.  There might be possible to add a line there ''options snd-hda-intel model=?my_particular_chipset_config?" but I'm not sure what to write there, the int from the enum, only the commercial name, or full C name from the enum.  I've tried with "model=r3d" and "model=alienware", then rebooted, but I see no changes.

Looking at static int patch_ca0132(struct hda_codec *codec) that doesn't seem to be the case at all.

What is the actual problem you are trying to solve?

If you are absolutely sure you need the quirk, you need to patch the module. Get the patch_ca0132.c file corresponding to your kernel version and save it somewhere. You will need a few other .h files from sound/pci/hda/ too. Add the following Makefile and build the module. You will need linux-headers package installed.

Code: [Select]

obj-m += patch_ca0132.o

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
When ready, as root:

Code: [Select]

rmmod patch_ca0132
insmod ./patch_ca0132.ko

[RoGeorge]

What is the actual problem you are trying to solve?

That's a very good question! 

The goal drifted from using a sound card as an audio spectrum analyzer  -->  audio software and OS tools in Ubuntu and FreeBSD  -->  sound system architectures for the two OSs  -->  various config files for various components  -->  particular bugs in the driver for Creative Sound Core3D chipset CA0132  -->  experimental patches for CA0132 driver  -->  how the "Intel HDA" module interacts with the CA0132 driver  -->  understanding CA0132 chipset architecture (e.g. CA0132 has a DSP blob, apparently an embedded 8051 core too, to control the DSP hardware, etc.)  -->  how to send parameters to a driver module and what parameters are supported  -->  how to recompile the Ubuntu kernel or, in this particular situation just the CA0132 driver module.  To me that was a very interesting learning journey, thank you all for guidance!

While at it, would have been nice to fix some minor inconveniences bugs for the onboard CA0132 like:
- once in a while, only at power on (either cold start or wake from a suspend to RAM), it will be no audio out
- can not switch to headphones, HP output does not work
- can only work in stereo mode, while the chipset is 5.1
- audio connectors are swapped, the 3.5mm jacks does not match the motherboard manual
- weird Mic2 instead of Line-In (didn't check yet if this Mic2-In can also turn on mic phantom power, that would be wrong to do for a line-in)


You are correct about the Quirk values in drivers, vs loading the kernel modules with parameters.  After more reading, it turns out that 'snd-hda-intel' module (common for any HDA compatible card, including for CA0132) can have a parameter 'model=generic', which can be set inside '/etc/modprobe.d/alsa-base.conf' by adding 'options snd-hda-intel model=generic'.  This will tell to the CA0132 module 'snd_hda_codec_ca0132' to load one of the "Quirk" remapings, depending on each CA0132 PCI ID vendor:model.


Just for the docs, the motherboard is Asrock model "Z97 Fatal1ty Professional", and the CA0132 id is 1102:0011, which is different from any of the values currently present in the CA0132 patch.  However, it feels like the work from similar chips with different IDs should be applicable to the one from the AsRock motherboard.  For the docs, this is the most promising thread for patching the CA0132 (especially the Connor McAdams' posts), and I would like to try that as an exercise of compiling patches and fiddling with driver modules in Linux:
https://bugzilla.kernel.org/show_bug.cgi?id=109191#c66
https://kernelnewbies.org/KernelBuild


Back to the global goal, of using the sound card as an audio spectrum analyzer, in order to measure the distortions coming from an external Peltz oscillator, in Linux I've used 'baudline' + 'arecord'.  The 'arecord' is needed because the free version of 'baudline' was made for OSS (but 'baudline' can record from 'stdin', too  ).

To use 'baudline' in Linux (with ALSA), first identify the existing ALSA soundcards/inputs using 'arecord -l'.  Then, start 'arecord' and pipe the audio datastream from 'arecord' to stdin, and then read the stdin datastream with 'baudline', like this:

Code: [Select]

cd baudline_1.08_linux_x86_64
# start the alsamixer, select the soundcard, enable the sound source and set the recording volume
alsamixer
# find hw:<card>,<device> numbers
arecord -l
# mine was
#     card 1: PCH [HDA Intel PCH], device 2: CA0132 Analog Mic-In2 [CA0132 Analog Mic-In2]
#        Subdevices: 1/1
#        Subdevice #0: subdevice #0
# which means "hw:1,2" in the next command, 10000 means 10ms buffer/latency, 96kHz sampling rate, 2 channels
arecord -D hw:1,2 -B 10000 -r 96000 -f S16_LE -c 2 | ./baudline -stdin -record -channels 2 -format le16


The signal from my Peltz-Wyatt oscillator when powered from a single 1.2V battery measures about -29.7dB (3.39%) distortions, so THD > 0.00001%, audiophils:  .




Spectrum and distortions with 'arecord' + 'baudline':


The hill in the backround noise floor for frequencies above 25kHz is internal noise from the soundcard.  I don't know if the displayed THD includes the 50Hz hum and the noise, too, or only the fundamental and its harmonics.

 

[ve7xen]

THD shouldn't include non-harmonic noise (that would be THD+N), and the baudline manual confirms this as well. The measurement will include the power in the harmonics, but not non-harmonic noise.

There's a bit of a 'whitepaper' on the baudline site about making various distortion measurements with a sound card at https://www.baudline.com/solutions/sine_distortion/index.html that might make for good reading. I believe this narrative implies that baudline's measurements are on single FFT bins, and that's not the only way to do things (more normalized measurements should be possible by using filters, but it creates a bit more ambiguity about the measurement), but it's good stuff to know especially if you're planning on using baudline to make this kind of measurement.

You should definitely make a loopback / reference measurement with a clean sine. Some of these motherboard implementations in my experience have quite poor THD performance; make sure you're actually measuring the DUT.