-
All of the above has been replaced by Pipewire on top of part of ALSA. Pipewire is lower abstraction than PulseAudio, thus faster, and it has better handling of streams.
Not in 20.04. It is available, but not installed by default, nor officially supported (that came about in 21.04). -
All of the above has been replaced by Pipewire on top of part of ALSA. Pipewire is lower abstraction than PulseAudio, thus faster, and it has better handling of streams.
Not in 20.04. It is available, but not installed by default, nor officially supported (that came about in 21.04).
Not even close the mature state of JACK.
PipeWire is one of those magic wands which will solve all things..
So far JACK works flawless with more than 16 tracks a dozen DSP filters and analyzers...
Fully threaded .. no fancy things like beeps ding dongs.
If you want to setup a proper system is simple:
- ditch systemd and UDEV - they both are on the way
- craft a proper device node on the system yourself
- use one of the good examples from ALSA to setup DMIX plugins (/etc/alsa/ ) like on the fly rate cvrts
- stress your sound card to check if it will be functional with ALSA drivers.Code: [Select]pcm.samplerate {
@args [ SLAVE RATE CONVERTER ]
@args.SLAVE {
type string
default "plug:hw"
}
@args.RATE {
type integer
default 48000
}
@args.CONVERTER {
type string
default "samplerate"
}
type rate
converter $CONVERTER
slave {
pcm $SLAVE
rate $RATE
}
hint {
show {
@func refer
name defaults.namehint.basic
}
description "Rate Converter Plugin Using Samplerate Library"
}
}
JACK works 100% perfectly fine. TODAY.
BTW - i am not guessing this.. I made measures of it myself (above)
Paul
-
I just dnf installed pipewire on another computer (Fedora32)
core error no such file
media session error no such file
No entries in shortcut menus, not in session apps
No instruction manual on gitlab, lots of issues just reported
I can't be bothered with all that again.
I think I'll just stay with jack for a long while -
I just dnf installed pipewire on another computer (Fedora32)
core error no such file
media session error no such file
No entries in shortcut menus, not in session apps
No instruction manual on gitlab, lots of issues just reported
I can't be bothered with all that again.
I think I'll just stay with jack for a long while
Wise decision.
If you note.. my shots... I let JACK running a rolling session for quite some time...
absolute ZERO xruns.. not even a bit missing while i was taking shots and fussing things..
take JACK as your north star and just go...
Paul
-
Your system is already broken if those things make any difference to it.
You don't think deleting /usr/lib/systemd and /usr/bin/pulseaudio is going to break the system?
Chances are pretty decent it won't even boot properly anymore.But that's the one way I know of. You are welcome to understand my intent and attempt it differently. A good habit to have in general.
I already had in my previous post, I didn't think it needed to be reiterated.Code: [Select]systemctl --user stop pulseaudio.socket && systemctl --user stop pulseaudio.serviceQuoteI just dnf installed pipewire on another computer (Fedora32)
And this is why it's generally not recommended to try replacing core system services like the audio server with things that are not well supported by the distribution.
I dislike and don't use RedHat-style distributions, but I would guess you need a session manager like wireplumber installed, but other things might also be broken, like trying to run it in parallel with PA. JACK, ALSA, and PA support might also all be separate packages. You probably want a patch bay like qpwgraph or Helvum installed to do manual routing too.
If you have a working JACK setup though, there's not too much reason to do this. The main advantage is that it makes it easier to integrate with the rest of the system audio, but if you're doing ham stuff, you probably have dedicated audio interfaces that you can manage with JACK and that doesn't really matter. -
I posted the way of making pulseaudio ignore some card so you don't even have to stop it. And I guarantee you that it works on all systems I've tried it with.
Getting rid of udev? Uh, yeah? Nice advice, especially if you're dealing with someone that may not be a Linux guru.
-
yes .. udev is bundled in systemd...
and pulseaudio forced by everyb. throats by the distro/desktop stuff.
In real terms? You need none of them.
Start with a distro without systemd. and do not install udev (EUDEV aka)
configure your device nodes just like a busybox system static mknods
You need a decent level of experience.
MIXING these JACK/PA/SYSTEMD/UDEV is a sack full of whinny cats..
ALSA and JACK can work out of the box clean and lean.. (see my shots..)
A BUSYBOX distro is enough to do that... (and no busybox uses udev or even systemd)
Paul
PS BTW my hidden tip is starting with a busybox distro to see yourself how ...
then you can just shift to another say... LFS or BLFS of yours
btw for anyone grounded in busybox.. start https://busybox.net/ acquiring how you put a fully functional running system in memory without UDEV.. and not even a bit of sytemdFd.... fully functional
-
Devuan is systemd-free, and uses eudev for device management. It also has the latest (0.3.54) PipeWire available, if one wants to use that. And of course also ALSA (libasound2-1.2.7.1-1), Jack Audio (jackd2 1.9.21), and so on; all the newest stuff, letting you choose instead of forcing one on you.
Do note that if you use Qt5 and Python3, QtMultimedia will handle the interface layer regardless of which one it is. ALSA, PulseAudio, Jack, PipeWire, a combination of them, all should just work.
Because of this, I will stick with my recommendation, unless RoGeorge wishes to amend their preferences already stated (KDE and Python 3).
Whatever sound system is used on the Linux installation, does not matter in this respect. (And while I might have an opinion, I don't think it matters here at this point.)
Because currently the Python 3 interpreter only runs Python code in one thread at a time in a given process, you'll want to use process-based parallelism if you want to do any heavy processing, to utilize a different core (from UI stuff). The best approach then, in my opinion, is to actually combine the record-and-process to a separate command-line helper that outputs binary results. (In the Python code, you could use e.g. a thread worker reading the data, parsing it, and emitting it to the UI via Queue or a Qt signal.)
If you do use PulseAudio, I already have C code that is quite suitable; and it would be very easy to add say FFTW3 Fourier transform or similar on top, and just emit the resulting data for the Python code to display. I could probably write one for ALSA as well in C (depending only on libasound2; libasound2-dev at build time). But, you can of course use Python for this too, although Python isn't that efficient in processing data streams. -
There's something weird with my hardware or with the drivers.
Saying this because even after stopping the PulseAudio, the signal from line-in is seen in Audacium as Mic2 (hw:1,2).
Audacium uses ALSA (it's an Audacity recompiled without telemetry) and Mic2 in the motherboard manual is an internal connector, with 0.1'' pins for the audio frontpanel, which I never had.
Now, if I try to start Jaaa with 'jaaa -A -d hw:1,2' it finally works, shows the spectrum with either input 1 or 2 (Jaaa shows 8 input buttons from 1 to 8 whatever that would mean). Though, I don't see how to display the THD, I think it can not do that.
Well, at least I can finally see something from the line-in cable.
I'll try tomorrow to boot from a live Kubuntu pendrive, just to be sure it's not some configuration that I might have messed in my previous attempts, also will try in FreeBSD to see if the channels are messed like they are now in my Kubuntu 20.04 LTS. -
Devuan is systemd-free, and uses eudev for device management. It also has the latest (0.3.54) PipeWire available, if one wants to use that. And of course also ALSA (libasound2-1.2.7.1-1), Jack Audio (jackd2 1.9.21), and so on; all the newest stuff, letting you choose instead of forcing one on you.
()
That is a nice setup.. you have much fat to strip but doable..
I HAVE JUST EXACTLY NOW UPGRADED MY JACK SETUP TO LATEST.
Awesome new cool looking.. i am sharing you guys... just keep trying
Works out the box nicely clean... very happy seeing the cool gizmos...
Paul
all the usual typos in a 2 second dirt shot...
-
There's something weird with my hardware or with the drivers.
(..)
I'll try tomorrow to boot from a live Kubuntu pendrive, just to be sure it's not some configuration that I might have messed in my previous attempts, also will try in FreeBSD to see if the channels are messed like they are now in my Kubuntu 20.04 LTS.
I put more faith in NOMINAL ANIMAL tip..
A DEVUAN flat setup probably has more chances to succeed easily
Time is limited you may put a decent Devuan ready to start
Paul -
RoGeorge, consider compiling the following program (list.c) via
gcc -Wall -O2 `pkg-config --cflags alsa` list.c `pkg-config --libs alsa` -o list
and run it (./list). It reports all ALSA PCM devices. For me, the key entry is "hw:CARD=PCH,DEV=0": HDA Intel PCH, CX8200 Analog Direct hardware device without any conversions. You do need to make sure you have libasound2-dev package installed.Code: [Select]// SPDX-License-Identifier: CC0-1.0I also see things like "jack": JACK Audio Connection Kit, because at least on ALSA 1.9.4 on Mint 20.04 (closest thing I have that should more or less match what you have), ALSA does support access to JACK and all those others. So, even though you'd use plain ol' ALSA, you could still use any audio subsystem you want.
#define _POSIX_C_SOURCE 200809L
#include <stdlib.h>
#include <alsa/asoundlib.h>
#include <stdio.h>
#include <errno.h>
int main(void)
{
void **hints;
int err;
err = snd_device_name_hint(-1, "pcm", &hints);
if (err) {
fprintf(stderr, "snd_device_name_hint(): %s.\n", snd_strerror(err));
return EXIT_FAILURE;
}
for (size_t i = 0; hints[i] != NULL; i++) {
char *name = snd_device_name_get_hint(hints[i], "NAME");
if (!name)
continue;
char *desc = snd_device_name_get_hint(hints[i], "DESC");
if (desc) {
char *p;
while ((p = strchr(desc, '\n'))) *p = ' ';
while ((p = strchr(desc, '\r'))) *p = ' ';
}
printf("\"%s\": %s\n", name, desc ? desc : "");
free(desc);
free(name);
}
snd_device_name_free_hint(hints);
hints = NULL;
return EXIT_SUCCESS;
}
Because it has explicit direct hardware access without any conversions (hw:CARD=card,DEV=device), and it has the least dependencies (libasound2 at runtime on Debian/Devuan derivatives, libasound2-dev at build time), it would be easiest to do the capture in C.
Of course, if you want, you can still make a Python 3 GUI, just use something like the above (but perhaps better formatted) to list the sources for the user to choose, and another program to read from a source. Then, use Python Subprocess to run them, and read their output in a pipe. This way, if you have multiple cores (available), then the Python code runs independently from the C code. (Typically, you'll use a separate Python thread, to read from the pipe in normal blocking manner, and pass each suitable block to your UI thread; perhaps using Queue, or Qt in KDE.)
If the Python code exists suddenly, the C code will detect that by EPIPE error, and also close gracefully; just handle the EPIPE error when writing to the pipe. For Fourier transforms and such, I'd use FFTW3 (with optional wisdom generated to optimize the chosen FFT window size) in the C code. It is fast and known-good implementation.
The above program really should be expanded to open each PCM device listed, and see if it can be recorded, and filter out those that are output-only. But I'm lazy, and I think it is useful to see all the ALSA pcm devices at this point, for verification. -
Wow! That is absolutely great and very helpful, thank you!
It compiled without any problem on both Kubuntu and FreeBSD.
When run on FreeBSD, there is no ALSA and no PulseAudio, only OSS. It returns:Code: [Select]list_FreeBSD
"null": Discard all samples (playback) or generate zero samples (capture)
"oss": Open Sound System
On Kubuntu, with either PulseAudio started or stopped, it returns the same ALSA list:Code: [Select]"surround21": 2.1 Surround output to Front and Subwoofer speakers
"surround40": 4.0 Surround output to Front and Rear speakers
"surround41": 4.1 Surround output to Front, Rear and Subwoofer speakers
"surround50": 5.0 Surround output to Front, Center and Rear speakers
"surround51": 5.1 Surround output to Front, Center, Rear and Subwoofer speakers
"surround71": 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
"null": Discard all samples (playback) or generate zero samples (capture)
"samplerate": Rate Converter Plugin Using Samplerate Library
"speexrate": Rate Converter Plugin Using Speex Resampler
"jack": JACK Audio Connection Kit
"oss": Open Sound System
"pulse": PulseAudio Sound Server
"upmix": Plugin for channel upmix (4,6,8)
"vdownmix": Plugin for channel downmix (stereo) with a simple spacialization
"hdmi:CARD=HDMI,DEV=0": HDA Intel HDMI, HDMI 0 HDMI Audio Output
"hdmi:CARD=HDMI,DEV=1": HDA Intel HDMI, HDMI 1 HDMI Audio Output
"hdmi:CARD=HDMI,DEV=2": HDA Intel HDMI, HDMI 2 HDMI Audio Output
"hdmi:CARD=HDMI,DEV=3": HDA Intel HDMI, HDMI 3 HDMI Audio Output
"hdmi:CARD=HDMI,DEV=4": HDA Intel HDMI, HDMI 4 HDMI Audio Output
"dmix:CARD=HDMI,DEV=3": HDA Intel HDMI, HDMI 0 Direct sample mixing device
"dmix:CARD=HDMI,DEV=7": HDA Intel HDMI, HDMI 1 Direct sample mixing device
"dmix:CARD=HDMI,DEV=8": HDA Intel HDMI, HDMI 2 Direct sample mixing device
"dmix:CARD=HDMI,DEV=9": HDA Intel HDMI, HDMI 3 Direct sample mixing device
"dmix:CARD=HDMI,DEV=10": HDA Intel HDMI, HDMI 4 Direct sample mixing device
"dsnoop:CARD=HDMI,DEV=3": HDA Intel HDMI, HDMI 0 Direct sample snooping device
"dsnoop:CARD=HDMI,DEV=7": HDA Intel HDMI, HDMI 1 Direct sample snooping device
"dsnoop:CARD=HDMI,DEV=8": HDA Intel HDMI, HDMI 2 Direct sample snooping device
"dsnoop:CARD=HDMI,DEV=9": HDA Intel HDMI, HDMI 3 Direct sample snooping device
"dsnoop:CARD=HDMI,DEV=10": HDA Intel HDMI, HDMI 4 Direct sample snooping device
"hw:CARD=HDMI,DEV=3": HDA Intel HDMI, HDMI 0 Direct hardware device without any conversions
"hw:CARD=HDMI,DEV=7": HDA Intel HDMI, HDMI 1 Direct hardware device without any conversions
"hw:CARD=HDMI,DEV=8": HDA Intel HDMI, HDMI 2 Direct hardware device without any conversions
"hw:CARD=HDMI,DEV=9": HDA Intel HDMI, HDMI 3 Direct hardware device without any conversions
"hw:CARD=HDMI,DEV=10": HDA Intel HDMI, HDMI 4 Direct hardware device without any conversions
"plughw:CARD=HDMI,DEV=3": HDA Intel HDMI, HDMI 0 Hardware device with all software conversions
"plughw:CARD=HDMI,DEV=7": HDA Intel HDMI, HDMI 1 Hardware device with all software conversions
"plughw:CARD=HDMI,DEV=8": HDA Intel HDMI, HDMI 2 Hardware device with all software conversions
"plughw:CARD=HDMI,DEV=9": HDA Intel HDMI, HDMI 3 Hardware device with all software conversions
"plughw:CARD=HDMI,DEV=10": HDA Intel HDMI, HDMI 4 Hardware device with all software conversions
"usbstream:CARD=HDMI": HDA Intel HDMI USB Stream Output
"default:CARD=PCH": HDA Intel PCH, CA0132 Analog Default Audio Device
"sysdefault:CARD=PCH": HDA Intel PCH, CA0132 Analog Default Audio Device
"front:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog Front speakers
"surround21:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog 2.1 Surround output to Front and Subwoofer speakers
"surround40:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog 4.0 Surround output to Front and Rear speakers
"surround41:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog 4.1 Surround output to Front, Rear and Subwoofer speakers
"surround50:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog 5.0 Surround output to Front, Center and Rear speakers
"surround51:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers
"surround71:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers
"iec958:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Digital IEC958 (S/PDIF) Digital Audio Output
"dmix:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog Direct sample mixing device
"dmix:CARD=PCH,DEV=1": HDA Intel PCH, CA0132 Digital Direct sample mixing device
"dmix:CARD=PCH,DEV=2": HDA Intel PCH, CA0132 Analog Mic-In2 Direct sample mixing device
"dmix:CARD=PCH,DEV=4": HDA Intel PCH, CA0132 What U Hear Direct sample mixing device
"dsnoop:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog Direct sample snooping device
"dsnoop:CARD=PCH,DEV=1": HDA Intel PCH, CA0132 Digital Direct sample snooping device
"dsnoop:CARD=PCH,DEV=2": HDA Intel PCH, CA0132 Analog Mic-In2 Direct sample snooping device
"dsnoop:CARD=PCH,DEV=4": HDA Intel PCH, CA0132 What U Hear Direct sample snooping device
"hw:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog Direct hardware device without any conversions
"hw:CARD=PCH,DEV=1": HDA Intel PCH, CA0132 Digital Direct hardware device without any conversions
"hw:CARD=PCH,DEV=2": HDA Intel PCH, CA0132 Analog Mic-In2 Direct hardware device without any conversions
"hw:CARD=PCH,DEV=4": HDA Intel PCH, CA0132 What U Hear Direct hardware device without any conversions
"plughw:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog Hardware device with all software conversions
"plughw:CARD=PCH,DEV=1": HDA Intel PCH, CA0132 Digital Hardware device with all software conversions
"plughw:CARD=PCH,DEV=2": HDA Intel PCH, CA0132 Analog Mic-In2 Hardware device with all software conversions
"plughw:CARD=PCH,DEV=4": HDA Intel PCH, CA0132 What U Hear Hardware device with all software conversions
"usbstream:CARD=PCH": HDA Intel PCH USB Stream Output
"hdmi:CARD=NVidia,DEV=0": HDA NVidia, HDMI 0 HDMI Audio Output
"hdmi:CARD=NVidia,DEV=1": HDA NVidia, HDMI 1 HDMI Audio Output
"hdmi:CARD=NVidia,DEV=2": HDA NVidia, HDMI 2 HDMI Audio Output
"hdmi:CARD=NVidia,DEV=3": HDA NVidia, HDMI 3 HDMI Audio Output
"hdmi:CARD=NVidia,DEV=4": HDA NVidia, HDMI 4 HDMI Audio Output
"hdmi:CARD=NVidia,DEV=5": HDA NVidia, HDMI 5 HDMI Audio Output
"hdmi:CARD=NVidia,DEV=6": HDA NVidia, HDMI 6 HDMI Audio Output
"dmix:CARD=NVidia,DEV=3": HDA NVidia, HDMI 0 Direct sample mixing device
"dmix:CARD=NVidia,DEV=7": HDA NVidia, HDMI 1 Direct sample mixing device
"dmix:CARD=NVidia,DEV=8": HDA NVidia, HDMI 2 Direct sample mixing device
"dmix:CARD=NVidia,DEV=9": HDA NVidia, HDMI 3 Direct sample mixing device
"dmix:CARD=NVidia,DEV=10": HDA NVidia, HDMI 4 Direct sample mixing device
"dmix:CARD=NVidia,DEV=11": HDA NVidia, HDMI 5 Direct sample mixing device
"dmix:CARD=NVidia,DEV=12": HDA NVidia, HDMI 6 Direct sample mixing device
"dsnoop:CARD=NVidia,DEV=3": HDA NVidia, HDMI 0 Direct sample snooping device
"dsnoop:CARD=NVidia,DEV=7": HDA NVidia, HDMI 1 Direct sample snooping device
"dsnoop:CARD=NVidia,DEV=8": HDA NVidia, HDMI 2 Direct sample snooping device
"dsnoop:CARD=NVidia,DEV=9": HDA NVidia, HDMI 3 Direct sample snooping device
"dsnoop:CARD=NVidia,DEV=10": HDA NVidia, HDMI 4 Direct sample snooping device
"dsnoop:CARD=NVidia,DEV=11": HDA NVidia, HDMI 5 Direct sample snooping device
"dsnoop:CARD=NVidia,DEV=12": HDA NVidia, HDMI 6 Direct sample snooping device
"hw:CARD=NVidia,DEV=3": HDA NVidia, HDMI 0 Direct hardware device without any conversions
"hw:CARD=NVidia,DEV=7": HDA NVidia, HDMI 1 Direct hardware device without any conversions
"hw:CARD=NVidia,DEV=8": HDA NVidia, HDMI 2 Direct hardware device without any conversions
"hw:CARD=NVidia,DEV=9": HDA NVidia, HDMI 3 Direct hardware device without any conversions
"hw:CARD=NVidia,DEV=10": HDA NVidia, HDMI 4 Direct hardware device without any conversions
"hw:CARD=NVidia,DEV=11": HDA NVidia, HDMI 5 Direct hardware device without any conversions
"hw:CARD=NVidia,DEV=12": HDA NVidia, HDMI 6 Direct hardware device without any conversions
"plughw:CARD=NVidia,DEV=3": HDA NVidia, HDMI 0 Hardware device with all software conversions
"plughw:CARD=NVidia,DEV=7": HDA NVidia, HDMI 1 Hardware device with all software conversions
"plughw:CARD=NVidia,DEV=8": HDA NVidia, HDMI 2 Hardware device with all software conversions
"plughw:CARD=NVidia,DEV=9": HDA NVidia, HDMI 3 Hardware device with all software conversions
"plughw:CARD=NVidia,DEV=10": HDA NVidia, HDMI 4 Hardware device with all software conversions
"plughw:CARD=NVidia,DEV=11": HDA NVidia, HDMI 5 Hardware device with all software conversions
"plughw:CARD=NVidia,DEV=12": HDA NVidia, HDMI 6 Hardware device with all software conversions
"usbstream:CARD=NVidia": HDA NVidia USB Stream Output
In all runs, the eZdsp USB devboard/soundcard was unplugged from the USB port.
The physical soundcards in the desketop are:
- HDA nVidia - digital soundcard because the nVidia graphic card can send digital sound to monitors
- HDA Intel HDMI - digital soundcard because the Intel graphic card can send digital sound to monitors
- HDA Intel PCH (which is the analog soundcard with CA0132 chipset, AFAIK that is a Creative Sound3D chip, no idea why the Creative CA0132 souncard is called Intel PCH
). This is the soundcard that I want to use, plugged to an external stereo amplifier.
As a side note, in FreeBSD 'baudline' works just fine (with OSS and no PulseAudio), but I suspect the sampling rate is always 48kHz, and when I set 196kHz from 'baudline', it's in fact just a software resample. Saying this because of the symmetry seen in the FFT spectrum.
The attached captures are for the same signal coming from a physical Peltz oscillator connected at the line-in. Only the sample rate was changed, from inside 'baudline'. At 44100 the spectrum looks dirty, at 48kHz looks OK (the harmonic are real distortions from the oscillator), but at 96kHz the spectrum looks mirrored, and at 192kHz is mirrored one more time.
-
The attached captures are for the same signal coming from a physical Peltz oscillator connected at the line-in. Only the sample rate was changed, from inside 'baudline'. At 44100 the spectrum looks dirty, at 48kHz looks OK (the harmonic are real distortions from the oscillator), but at 96kHz the spectrum looks mirrored, and at 192kHz is mirrored one more time.
I wrote a simple FFT (butterfly, C89) for my HPPA workstation and had a similar problem with my custom audio kernel driver. In my case: I forgot -1- to disable the line-in filter and, even worse, -2- to set the bit that manages the sampling mod. This way it wasn't on a regular basis but on "when the data is ready, you can trigger an interrupt".
Combined, these two defects introduce *false harmonics* in the spectrum and a very annoying "low pass" frequency.
Also, with digital sampling, you have to be careful with the "sampling window". There are many, you ave to choose the right one for your application, and be prepared to accept that none of them is perfect, they all always introduces a little distortion and phase shift. -
It's these you want to use (with the built-in stuff). It is called Intel PCH, because that's the driver name, snd_hda_intel. The name is composed partially by ALSA (based on stuff in /etc/alsa/ and /usr/share/alsa/), and partially by the kernel driver (see e.g. /proc/asound/pcm in Linux).Code: [Select]"hw:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog Direct hardware device without any conversions
"hw:CARD=PCH,DEV=1": HDA Intel PCH, CA0132 Digital Direct hardware device without any conversions
"hw:CARD=PCH,DEV=2": HDA Intel PCH, CA0132 Analog Mic-In2 Direct hardware device without any conversions
"hw:CARD=PCH,DEV=4": HDA Intel PCH, CA0132 What U Hear Direct hardware device without any conversions
If the capture program or thread gets that device name, "hw:CARD=PCH,DEV=0" or "hw:CARD=PCH,DEV=2", then it is very simple to check the natively supported sample rates and capture data. Just let me know if you want example code.Also, with digital sampling, you have to be careful with the "sampling window". There are many, you have to choose the right one for your application, and be prepared to accept that none of them is perfect, they all always introduces a little distortion and phase shift.
Yup. Wikipedia has more on this. Rectangular –– applying no window function, just putting chunks through FFT –– is itself one window function. (To apply a window function, you just multiply the samples by the window function; it is simple scaling of the samples.)
Typically, one advances the data by one half FFT block; this is called the Welch method.
When displaying the FFT data interactively (noting that there are around 20-25 blocks of 2000 samples per second at 44.1kHz and 48kHz sample rates per channel; twice that if you use the Welch method, which I do recommend you do), you can show both the most recent FFTs in a persistence kind of way (most recent brightest), but also show the weighted averaged FFT (which is a more realistic description of the spectral content if the waveform doesn't change). Note that you'll want to do the averaging in the complex domain (real and imaginary parts separately averaged), not in the magnitude-phase domain. -
(..)Code: [Select]"hw:CARD=PCH,DEV=0": HDA Intel PCH, CA0132 Analog Direct hardware device without any conversions
"hw:CARD=PCH,DEV=1": HDA Intel PCH, CA0132 Digital Direct hardware device without any conversions
"hw:CARD=PCH,DEV=2": HDA Intel PCH, CA0132 Analog Mic-In2 Direct hardware device without any conversions
"hw:CARD=PCH,DEV=4": HDA Intel PCH, CA0132 What U Hear Direct hardware device without any conversions
apps which have no access to such code can use ALSA native player as:
aplay -l ( L lowcase stands LIST )
it reports what such apps can see at the surface of ALSA.
the OP can try and report it back... to complete the figure
Paul -
- HDA Intel PCH (which is the analog soundcard with CA0132 chipset, AFAIK that is a Creative Sound3D chip, no idea why the Creative CA0132 souncard is called Intel PCH
).
It's the Intel "High Definition Audio" thing. It consists of a low cost "codec" (DACs, ADCs and analog bits) talking a simple serial link to a special PCI controller. Your codec is supplied by Creative and your PCI module is supplied by Intel, part of the PCH chip. This architecture is used for onboard audio everywhere since ~2000; before HDA a similar standard known as AC97 existed. -
aplay -l ( L lowcase stands LIST )
Absolutely; and
arecord -L
lists all PCM devices one can read from.
(And why didn't I suggest that first, and instead jumped to code)
Furthermore,
arecord -D name --dump-hw-params
lists the actual hardware capabilities for the PCM device (in recording mode). Which for me, tells the following:Code: [Select]HW Params of device "hw:CARD=PCH,DEV=0":and so for best results, I'd use
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S16_LE S32_LE
SUBFORMAT: STD
SAMPLE_BITS: [16 32]
FRAME_BITS: [32 64]
CHANNELS: 2
RATE: [48000 96000]
PERIOD_TIME: (166 170667)
PERIOD_SIZE: [16 8192]
PERIOD_BYTES: [128 65536]
PERIODS: [2 32]
BUFFER_TIME: (333 341334)
BUFFER_SIZE: [32 16384]
BUFFER_BYTES: [128 65536]
TICK_TIME: ALL
--------------------
arecord -D hw:PCH,0 --disable-format --disable-softvol --disable-resample -t raw -c 2 -f S32_LE -r 96000 -B 20875
to output raw 32-bit little endian samples in two channels, interleaved (left right left right ...), at 96 kHz sample rate to standard output, in blocks of roughly 2004 samples per channel (1,000,000µs × 2004 / 96,000 = 20875).
The above samples the hardware channel, but you may have to use amixer to set the hardware channel configuration.
In particular, amixer -D hw:PCH contents gives (omitting the uninteresting ones)Code: [Select]numid=19,iface=CARD,name='Internal Mic Phantom Jack'This tells me that I don't have anything connected to Line, but if I had, I'd need to set "numid=7,iface=MIXER,name='Capture Source'" to 2 to capture Line In, "numid=8,iface=MIXER,name='Capture Volume'" to set the hardware capture volume (right now it is set to zero), choose between 0 or 3 for "numid=12,iface=MIXER,name='Line Boost Volume'", and "numid=9,iface=MIXER,name='Capture Switch'" to True.
; type=BOOLEAN,access=r-------,values=1
: values=on
numid=20,iface=CARD,name='Line Jack'
; type=BOOLEAN,access=r-------,values=1
: values=off
numid=18,iface=CARD,name='Mic Jack'
; type=BOOLEAN,access=r-------,values=1
: values=off
numid=23,iface=CARD,name='Speaker Phantom Jack'
; type=BOOLEAN,access=r-------,values=1
: values=on
numid=16,iface=MIXER,name='Master Playback Switch'
; type=BOOLEAN,access=rw------,values=1
: values=on
numid=15,iface=MIXER,name='Master Playback Volume'
; type=INTEGER,access=rw---R--,values=1,min=0,max=74,step=0
: values=47
| dBscale-min=-74.00dB,step=1.00dB,mute=0
numid=5,iface=MIXER,name='Headphone Playback Switch'
; type=BOOLEAN,access=rw------,values=2
: values=off,off
numid=4,iface=MIXER,name='Headphone Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=74,step=0
: values=0,0
| dBscale-min=-74.00dB,step=1.00dB,mute=0
numid=61,iface=MIXER,name='PCM Playback Volume'
; type=INTEGER,access=rw---RW-,values=2,min=0,max=255,step=0
: values=253,253
| dBscale-min=-51.00dB,step=0.20dB,mute=0
numid=12,iface=MIXER,name='Line Boost Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=3,step=0
: values=0,0
| dBscale-min=0.00dB,step=12.00dB,mute=0
numid=10,iface=MIXER,name='Mic Boost Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=3,step=0
: values=0,0
| dBscale-min=0.00dB,step=12.00dB,mute=0
numid=1,iface=MIXER,name='Mic Mute-LED Mode'
; type=ENUMERATED,access=rw------,values=1,items=4
; Item #0 'On'
; Item #1 'Off'
; Item #2 'Follow Capture'
; Item #3 'Follow Mute'
: values=3
numid=7,iface=MIXER,name='Capture Source'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Mic'
; Item #1 'Internal Mic'
; Item #2 'Line'
: values=1
numid=9,iface=MIXER,name='Capture Switch'
; type=BOOLEAN,access=rw------,values=2
: values=off,off
numid=8,iface=MIXER,name='Capture Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=80,step=0
: values=0,0
| dBscale-min=-74.00dB,step=1.00dB,mute=0
numid=6,iface=MIXER,name='Auto-Mute Mode'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'Disabled'
; Item #1 'Speaker Only'
; Item #2 'Line Out+Speaker'
: values=2
numid=14,iface=MIXER,name='Beep Playback Switch'
; type=BOOLEAN,access=rw------,values=1
: values=on
numid=13,iface=MIXER,name='Beep Playback Volume'
; type=INTEGER,access=rw---R--,values=1,min=0,max=7,step=0
: values=3
| dBscale-min=-28.00dB,step=4.00dB,mute=0
numid=11,iface=MIXER,name='Internal Mic Boost Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=3,step=0
: values=0,0
| dBscale-min=0.00dB,step=12.00dB,mute=0
numid=17,iface=MIXER,name='Mute-LED Mode'
; type=ENUMERATED,access=rw------,values=1,items=3
; Item #0 'On'
; Item #1 'Off'
; Item #2 'Follow Master'
: values=2
numid=3,iface=MIXER,name='Speaker+LO Playback Switch'
; type=BOOLEAN,access=rw------,values=2
: values=on,on
numid=2,iface=MIXER,name='Speaker+LO Playback Volume'
; type=INTEGER,access=rw---R--,values=2,min=0,max=74,step=0
: values=74,74
| dBscale-min=-74.00dB,step=1.00dB,mute=0
numid=25,iface=PCM,name='Capture Channel Map'
; type=INTEGER,access=r----R--,values=2,min=0,max=36,step=0
: values=0,0
| container
| chmap-fixed=FL,FR
So, as you can see, you use the mixer to select the exact capture input jack, and the PCM device to read or write samples.This architecture is used for onboard audio everywhere [on x86 and x86-64 architectures] since ~2000; before HDA a similar standard known as AC97 existed.
Fixed that for you
-
Just found out the funniest place to get info about ALSA cards in Kubuntu: /proc/asaund/
There are text files with status and capabilities:Code: [Select]$ cat /proc/asound/cards
0 [HDMI ]: HDA-Intel - HDA Intel HDMI
HDA Intel HDMI at 0xefa34000 irq 41
1 [PCH ]: HDA-Intel - HDA Intel PCH
HDA Intel PCH at 0xefa30000 irq 42
2 [NVidia ]: HDA-Intel - HDA NVidia
HDA NVidia at 0xef080000 irq 17
3 [U0x4510x9010 ]: USB-Audio - USB Device 0x451:0x9010
USB Device 0x451:0x9010 at usb-0000:00:14.0-1.2, full speed
Each card has its own directory with text files about various info, for example the eZdsp USB devboard/souncard:Code: [Select]$ cat /proc/asound/card3/usbmixer
USB Mixer: usb_id=0x04519010, ctrlif=0, ctlerr=0
Card: USB Device 0x451:0x9010 at usb-0000:00:14.0-1.2, full speed
Unit: 2
Control: name="PCM Playback Volume", index=0
Info: id=2, control=2, cmask=0x3, channels=2, type="S16"
Volume: min=-1536, max=7424, dBmin=-600, dBmax=2900
Unit: 2
Control: name="PCM Playback Switch", index=0
Info: id=2, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
Volume: min=0, max=1, dBmin=0, dBmax=0
Unit: 5
Control: name="Mic Capture Switch", index=0
Info: id=5, control=1, cmask=0x0, channels=1, type="INV_BOOLEAN"
Volume: min=0, max=1, dBmin=0, dBmax=0Code: [Select]$ cat /proc/asound/card3/stream0
USB Device 0x451:0x9010 at usb-0000:00:14.0-1.2, full speed : USB Audio
Playback:
Status: Stop
Interface 2
Altset 1
Format: S16_LE
Channels: 2
Endpoint: 0x02 (2 OUT) (ADAPTIVE)
Rates: 48000, 16000
Bits: 16
Channel map: FL FR
Capture:
Status: Stop
Interface 1
Altset 1
Format: S16_LE
Channels: 1
Endpoint: 0x81 (1 IN) (ASYNC)
Rates: 16000
Bits: 16
Channel map: MONO
And for the analog chipset on the motherboard:Code: [Select]$ cat /proc/asound/card1/codec#0
Codec: Creative CA0132
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x11020011
Subsystem Id: 0x18491020
Revision Id: 0x100918
No Modem Function Group found
Default PCM:
rates [0x0]:
bits [0x0]:
formats [0x0]:
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
State of AFG node 0x01:
Power states: D0 D3 D3cold S3D3cold CLKSTOP EPSS
Power: setting=D0, actual=D0
GPIO: io=0, o=0, i=0, unsolicited=1, wake=1
Node 0x02 [Audio Output] wcaps 0x49d: Stereo Amp-Out
Device: name="CA0132 Analog", type="Audio", device=0
Amp-Out caps: ofs=0x5a, nsteps=0x63, stepsize=0x03, mute=1
Amp-Out vals: [0x44 0x44]
Converter: stream=0, channel=0
PCM:
rates [0x5ec]: 16000 22050 44100 48000 88200 96000 192000
bits [0x1f]: 8 16 20 24 32
formats [0x1]: PCM
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x03 [Audio Output] wcaps 0x49d: Stereo Amp-Out
Amp-Out caps: ofs=0x5a, nsteps=0x63, stepsize=0x03, mute=1
Amp-Out vals: [0x5a 0x5a]
Converter: stream=0, channel=0
PCM:
rates [0x5ec]: 16000 22050 44100 48000 88200 96000 192000
bits [0x1f]: 8 16 20 24 32
formats [0x1]: PCM
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x04 [Audio Output] wcaps 0x49d: Stereo Amp-Out
Amp-Out caps: ofs=0x5a, nsteps=0x63, stepsize=0x03, mute=1
Amp-Out vals: [0x5a 0x5a]
Converter: stream=0, channel=0
PCM:
rates [0x5ec]: 16000 22050 44100 48000 88200 96000 192000
bits [0x1f]: 8 16 20 24 32
formats [0x1]: PCM
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x05 [Audio Output] wcaps 0x691: Stereo Digital
Control: name="IEC958 Playback Con Mask", index=0, device=0
Control: name="IEC958 Playback Pro Mask", index=0, device=0
Control: name="IEC958 Playback Default", index=0, device=0
Control: name="IEC958 Playback Switch", index=0, device=0
Control: name="IEC958 Default PCM Playback Switch", index=0, device=0
Device: name="CA0132 Digital", type="SPDIF", device=1
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
IEC Coding Type: 0x0
PCM:
rates [0x5e0]: 44100 48000 88200 96000 192000
bits [0x1e]: 16 20 24 32
formats [0x5]: PCM AC3
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x06 [Audio Output] wcaps 0x691: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
IEC Coding Type: 0x0
PCM:
rates [0x5e0]: 44100 48000 88200 96000 192000
bits [0x1e]: 16 20 24 32
formats [0x5]: PCM AC3
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x07 [Audio Input] wcaps 0x10059b: Stereo Amp-In
Device: name="CA0132 Analog", type="Audio", device=0
Amp-In caps: ofs=0x5a, nsteps=0x63, stepsize=0x03, mute=1
Amp-In vals: [0x5a 0x5a]
Converter: stream=0, channel=0
SDI-Select: 0
PCM:
rates [0x1ec]: 16000 22050 44100 48000 88200 96000
bits [0x1f]: 8 16 20 24 32
formats [0x1]: PCM
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x12
Node 0x08 [Audio Input] wcaps 0x10059b: Stereo Amp-In
Control: name="Analog-Mic2 Capture Volume", index=0, device=0
ControlAmp: chs=3, dir=In, idx=0, ofs=0
Control: name="Analog-Mic2 Capture Switch", index=0, device=0
ControlAmp: chs=3, dir=In, idx=0, ofs=0
Device: name="CA0132 Analog Mic-In2", type="Audio", device=2
Amp-In caps: ofs=0x5a, nsteps=0x63, stepsize=0x03, mute=1
Amp-In vals: [0x5a 0x5a]
Converter: stream=0, channel=0
SDI-Select: 0
PCM:
rates [0x1ec]: 16000 22050 44100 48000 88200 96000
bits [0x1f]: 8 16 20 24 32
formats [0x1]: PCM
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x11
Node 0x09 [Audio Input] wcaps 0x100791: Stereo Digital
Control: name="IEC958 Capture Switch", index=0, device=0
Control: name="IEC958 Capture Default", index=0, device=0
Device: name="CA0132 Digital", type="SPDIF", device=1
Converter: stream=0, channel=0
SDI-Select: 0
Digital: Enabled
Digital category: 0x0
IEC Coding Type: 0x0
PCM:
rates [0x5f0]: 32000 44100 48000 88200 96000 192000
bits [0x1a]: 16 24 32
formats [0x1]: PCM
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x0e
Node 0x0a [Audio Input] wcaps 0x10079b: Stereo Digital Amp-In
Control: name="What U Hear Capture Volume", index=0, device=0
ControlAmp: chs=3, dir=In, idx=0, ofs=0
Control: name="What U Hear Capture Switch", index=0, device=0
ControlAmp: chs=3, dir=In, idx=0, ofs=0
Device: name="CA0132 What U Hear", type="Audio", device=4
Amp-In caps: ofs=0x5a, nsteps=0x63, stepsize=0x03, mute=1
Amp-In vals: [0x5a 0x5a]
Converter: stream=0, channel=0
SDI-Select: 0
Digital:
Digital category: 0x0
IEC Coding Type: 0x0
PCM:
rates [0x1ec]: 16000 22050 44100 48000 88200 96000
bits [0x1b]: 8 16 24 32
formats [0x1]: PCM
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x13
Node 0x0b [Pin Complex] wcaps 0x400581: Stereo
Pincap 0x00010014: OUT EAPD Detect
EAPD 0x2: EAPD
Pin Default 0x01014010: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Green
DefAssociation = 0x1, Sequence = 0x0
Pin-ctls: 0x40: OUT
Unsolicited: tag=05, enabled=1
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x02
Node 0x0c [Pin Complex] wcaps 0x400701: Stereo Digital
Pincap 0x00000010: OUT
Pin Default 0x014580f0: [Jack] SPDIF Out at Ext Rear
Conn = Optical, Color = Purple
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x40: OUT
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x05
Node 0x0d [Pin Complex] wcaps 0x400701: Stereo Digital
Pincap 0x00000010: OUT
Pin Default 0x014570f0: [Jack] SPDIF Out at Ext Rear
Conn = Optical, Color = Yellow
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x06
Node 0x0e [Pin Complex] wcaps 0x400681: Stereo Digital
Pincap 0x00000020: IN
Pin Default 0x01c530f0: [Jack] SPDIF In at Ext Rear
Conn = Optical, Color = Blue
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x0f [Pin Complex] wcaps 0x400581: Stereo
Pincap 0x0000001c: OUT HP Detect
Pin Default 0x0221401f: [Jack] HP Out at Ext Front
Conn = 1/8, Color = Green
DefAssociation = 0x1, Sequence = 0xf
Pin-ctls: 0x00:
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x02
Node 0x10 [Pin Complex] wcaps 0x400581: Stereo
Pincap 0x0000001c: OUT HP Detect
Pin Default 0x02216011: [Jack] HP Out at Ext Front
Conn = 1/8, Color = Orange
DefAssociation = 0x1, Sequence = 0x1
Pin-ctls: 0x00:
Unsolicited: tag=01, enabled=1
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x03
Node 0x11 [Pin Complex] wcaps 0x40058b: Stereo Amp-In
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00]
Pincap 0x00003734: IN OUT Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x02012014: [Jack] Line Out at Ext Front
Conn = 1/8, Color = Grey
DefAssociation = 0x1, Sequence = 0x4
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=04, enabled=1
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x04
Node 0x12 [Pin Complex] wcaps 0x40048b: Stereo Amp-In
Control: name="Mic1-Boost (30dB) Capture Switch", index=0, device=0
ControlAmp: chs=1, dir=In, idx=0, ofs=0
Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0
Amp-In vals: [0x00 0x00]
Pincap 0x00003724: IN Detect
Vref caps: HIZ 50 GRD 80 100
Pin Default 0x37a791f0: [Jack] Mic at Oth Mobile-In
Conn = Analog, Color = Pink
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=02, enabled=1
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x13 [Pin Complex] wcaps 0x400681: Stereo Digital
Pincap 0x00000020: IN
Pin Default 0x908700f0: [Fixed] Line In at Int N/A
Conn = Analog, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x20: IN
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x14 [Beep Generator Widget] wcaps 0x70040c: Mono Amp-Out
Amp-Out caps: ofs=0x1f, nsteps=0x1f, stepsize=0x05, mute=1
Amp-Out vals: [0x1f]
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x15 [Vendor Defined Widget] wcaps 0xf00600: Mono Digital
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x16 [Vendor Defined Widget] wcaps 0xf00680: Mono Digital
Unsolicited: tag=03, enabled=1
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x17 [Audio Output] wcaps 0x49d: Stereo Amp-Out
Amp-Out caps: ofs=0x5a, nsteps=0x63, stepsize=0x03, mute=1
Amp-Out vals: [0x5a 0x5a]
Converter: stream=0, channel=0
PCM:
rates [0x5ec]: 16000 22050 44100 48000 88200 96000 192000
bits [0x1f]: 8 16 20 24 32
formats [0x1]: PCM
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Node 0x18 [Pin Complex] wcaps 0x400581: Stereo
Pincap 0x00000010: OUT
Pin Default 0x500000f0: [N/A] Line Out at Int N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Pin-ctls: 0x00:
Unsolicited: tag=00, enabled=0
Power states: D0 D3 EPSS
Power: setting=D0, actual=D0
Connection: 1
0x17
From the last one it seems the Creative CA0132 chipset can only sample here (in Kubuntu/ALSA) at 96kHz, while 192kHz sampling is available only for playback.
(The previously attached spectrum pics were captured with 'baudline' in FreeBSD/OSS. Considering Kubuntu/ALSA only has 96kHz recording, I think the 192kHz at recording in 'baudline' FreeBSD/OSS was fake.) -
aplay -l ( L lowcase stands LIST )
Absolutely; and
arecord -L
lists all PCM devices one can read from.
(And why didn't I suggest that first, and instead jumped to code)
Furthermore,
arecord -D name --dump-hw-params
lists the actual hardware capabilities for the PCM device (in recording mode).
nah.. your code is supreme correct stuff...
you can NOT expect to use that call under C with some exec and parse results...
so your code does the correct query
But on console with dumb interpreters you can config and query DCONF setupsCode: [Select]TRY
aplay -vv -D plug:monitor
and
arecord -D plug:capture
to check defined setups for monitor and capture
at last try aplay -L (L capital)
Paul
-
I just dnf installed pipewire on another computer (Fedora32)
Fedora 32 is more than two years old and has been End-of-life since 2021‑05‑25. Pipewire was shipped first in Fedora 34. Current Fedora (36) comes with Pipewire as default. -
At this point the sound architecture in Linux seems clear enough to me, and I have no more problems understanding how OSS or ALSA interacts with JACK or with PulseAudio, thank you all for helping me with that.
This doesn't mean my onboard CA0132 works as expected.
I've started to suspect the driver, and searched for Linux driver problems with CA0132 (Creative Sound Core3D). CA0132 is a chip embedded in many motherboards and gaming laptops, and yes, all the weird behavior I've seen so far happens to others, too.
It seems that's because of the drivers having either incomplete support, or bugs, and not because of ALSA or PulseAudio.
https://bugzilla.kernel.org/buglist.cgi?quicksearch=ca0132
Not sure if I want to go deeper in this rabbit hole.
Most of those bugs specific for CA0132 do happen in my desktop, too, and some of the bugs have experimental patches (e.g. https://bugzilla.kernel.org/show_bug.cgi?id=67071 reply #7). I'm familiar with the idea of compiling, but don't know anything about kernel dev workflow.
1. - How difficult is to apply a patch?
2. - Do I need to recompile the whole kernel, or the driver is just a separated module to be compiled then loaded?
3. - Do I need to manually re-apply the patch and recompile forever, at each new kernel version upgrade pushed by Ubuntu updates?
4. - I've seen this: https://help.ubuntu.com/community/Kernel/Compile Is this a good start, do I need other link to read for a brief intro about how this is usually done (applying a custom patch, then dealing with it at each future kernel version upgrade)?
These are too broad questions to google, and I'm only trying to evaluate how difficult would be, not trying to become a kernel dev. From (4.) it seems that I shouldn't compile the whole kernel (the Ubuntu kernel compile page sais at reasons to NOT recompile the kernel "You merely need to compile a special driver. For this, you only need to install the linux-headers packages." ), but I still don't know how to apply the patch to sources and what exactly to recompile to get a patched CA0132 driver.
-
The driver for CA0132 seems to be a loaded kernel module:Code: [Select]
$ lsmod | grep ca0132
Module Size Used by
snd_hda_codec_ca0132 139264 1
snd_hda_codec 155648 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec_ca0132
snd_hda_core 106496 4 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_codec_ca0132
snd_pcm 135168 9 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_soc_rt5640,snd_compress,snd_soc_core,snd_hda_core,snd_hda_codec_ca0132,snd_pcm_dmaengine
snd 102400 24 snd_seq,snd_seq_device,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_compress,snd_soc_core,snd_pcm,snd_hda_codec_ca0132,snd_rawmidiCode: [Select]$ find /lib/modules/$(uname -r) -type f -iname '*ca0132*.ko*'
/lib/modules/5.15.0-41-generic/kernel/sound/pci/hda/snd-hda-codec-ca0132.ko
So I should patch and recompile only the "snd-hda-codec-ca0132.ko" for the given kernel version, but without recompiling the whole Linux kernel, then load the patched module instead of the official "snd-hda-codec-ca0132.ko", did I get it right? -
This doesn't mean my onboard CA0132 works as expected.
pretty like the onboard sound chip on my HPPA workstation, and if it's soldered onboard ... you cannot change it.
That's why I suggested you to buy an USB-sound card, choosing from one of the most Linux-friendly available.weird behavior I've seen so far happens to others, too.
In my case, the sound chip is basically a couple of ADC with a FIFO and a weird ASIC circuit to control it, and there is a weird (crazy?) mode that allows the software to take samples only when the FIFO is full, this means that you are not sampling at the regular sample rate (let's say at 100Khz) because the filling of the FIFO depends on the speed with which the kernel reads the data to empty it, which must be considered "random behavior" since it depends on random factors.
To me, it makes no sense, but ... some engineers must have thought otherwise, and when some hobbyists like me tried to write a driver for Linux ... they came up with a mess (I don't blame them, it's really a very bad sound chip)... worse still for an experimental abandoned platform so you have ZERO interest from the Linux Devs
I wrote a kernel module assigning a timer to the ADC so the kernel reads the FIFO on regular frequency base and assign a timestamp to the samples. This solved my problem in a very simple way, but then ... it's not OSS compliant and it doesn't make the driver a "sound driver" (actually it's an ADC driver) therefore you have to deal with other parts of the kernel and with other parts of the userspace.
If you follow the rabbit down its hole ... well, it really goes deeper and faster than you ever imagined.1. - How difficult is to apply a patch?
2. - Do I need to recompile the whole kernel, or the driver is just a separated module to be compiled then loaded?
3. - Do I need to manually re-apply the patch and recompile forever, at each new kernel version upgrade pushed by Ubuntu updates?
4. - I've seen this: https://help.ubuntu.com/community/Kernel/Compile Is this a good start, do I need other link to read for a brief intro about how this is usually done (applying a custom patch, then dealing with it at each future kernel version upgrade)?
1: you have to use the program "patch". Not complex, but you have to consider how patches are generated and handled. If a patch comes from a mailing list and it's "text malformed" you have to fix it before you can apply. That's not complex, it's simply annoying, but that's it.
2: it depends. If the kernel module has some dependency with the whole kernel tree, you have to recompile everything, otherwise you can create a special Makefile that only re-compiles your kernel module, it just needs to "point" the kernel source (especially for headers) and it will compile nothing but local files.
3: yes, unless the patch is integrated into the Vanilla source, if someone sends it to Linus Torvalds and * he * approves the code, in this case you will find it already applied into the latest binary kernel you will get from Ubuntu
4: dunno, here it's a personal path, mine started many many years ago with kernel 2.0.* , too years ago to remember how how I learned thingsCode: [Select]# mybuild
kernel-5.14.1(arm.32/nanopi-neo)
tc) show toolchain version
up) script_update
0) clean
1) configure
2) compile app
3) app module
4) tftp [email protected]:
5) tools
app_name = kernel-5.14.1-32bit-nanopi-neo
machine_note = experimental
qualified_host = macmini-intelCode: [Select]# mybuild 5
[step5] tools
1 - list actually used source
2 - archive actually_used_source
3 - backup files
4 - list all files to be patched
5 - apply patches
6 - make patches
7 - revert patchesCode: [Select]# mybuild 5 6
[step5] tools
[step5.6] make patches
~ Makefile ... success
~ lib/dump_stack.c ... success
~ mm/page_alloc.c ... success
~ scripts/setlocalversion ... success
~ arch/arm/Kconfig ... success
~ init/main.c ... success
~ arch/arm/kernel/setup.c ... success
~ arch/arm/kernel/smp.c ... success
~ lib/dump_stack.c ... success
~ init/version.c ... success
~ mm/page_alloc.c ... success
~ kernel/printk/printk.c ... success
~ kernel/panic.c ... success
~ scripts/mkuboot.sh ... success
~ scripts/Makefile.lib ... successCode: [Select]# mybuild 2
[step2] compiling
kernel-5.14.1(arm/nanopi-neo)
toolchain(armv7a-unknown-linux-gnueabihf:2.34/9.3.0)
app_name = kernel-5.14.1-32bit-nanopi-neo
machine_note = experimental
qualified_host = macmini-intel
-----------------------------------------------
gadget_to_do(build) ... kernel/build
gadget_to_do(clean) ... kernel/clean
building kernel ... success
building dtb ... success
-----------------------------------------------
gadget_to_do(binary) ... overlay/binary
gadget_to_do(sweep) ... kernel/sweep
ram_size=32768
slice loading ... done, 22378 byte
slice saving ... done, 32768 byte
gadget_to_do(binary_report) ... kernel/binary_report
It uses a global recipe that can be overridden by a local recipeCode: [Select]# mybuild recipeIt tells you how it was compiled, on which machines (qualified hosts, can be virtual machines), with which toolchain, options, and it also reports things that are mandatory. So I can easily forget and don't care about details, this is useful when you have to deal with sources that can age faster than how you can remember or manage.
- version
- platform
- machine_arch_32
- machine_arch_64
- machine_loadaddr
- machine_image
- machine_note
- machine_bits
- platform
- chosen
- product
- tftp_server_ip
- toolchain_32
- toolchain_64
- binutils_ver_min
- binutils_ver_max
- gcc_ver_max
- gcc_ver_min
- gcc_opt
- qualified_host
- tftp_file_name
- overlay { check_tools.list, binary, binary_report, build, clean, sweep, uImage, dtb, tftp } -
So I should patch and recompile only the "snd-hda-codec-ca0132.ko" for the given kernel version, but without recompiling the whole Linux kernel, then load the patched module instead of the official "snd-hda-codec-ca0132.ko", did I get it right?
yup. If the patch doesn't touch nothing but the kernel audio module of you card, you can recompile only it.
I suggest you to create a local folder, copy the kernel module there, apply the patch locally, and to create a Makefile to force the local module to be compiled.
Inside the Makefile you only have to "point" the path of the kernel source of reference.