I've built a small circuit of an LC sinusoidal audio oscillator, and I would like to use the "line-in" from the desktop's sound card in order to measure the signal's distortions.
Found two programs that can do this, 'ARTA'
https://artalabs.hr/ (a Windows program run in Linux through WineHQ) and a Linux native one called 'baudline'
https://www.baudline.com/ but I don't understand the audio signal path in Linux.
So far I've kept googling and installing all kind of tools and making a mess mixture of ALSA, Pulse-Audio and Jack-Audio, but I don't know any of these or what's the idea.
1. - How do I route the audio signal from the 'line-in' of the sound card (Creative CA0132)?
2. - Where can I learn about sound in KDE Plasma (Kubuntu 20.04), so to understand what to do?
3. - How can I read the raw/unaltered ADC data from the line-in, preferably in Python for easier postprocessing?
Trying to list the soundcards:
#!/usr/bin/env python3
# if pyaudio not present, install it with
# sudo apt install python3-pyaudio
import pyaudio as pa
print()
p = pa.PyAudio()
print("print PyAudio():\n", p)
print("devices:n")
for i in range(p.get_device_count()):
#pass
print( p.get_device_info_by_index(i) )
# if sounddevice not present, install it with
# pip install sounddevice
import sounddevice as sd
print()
print("print sounddevice.query_devices():\n")
print(sd.query_devices())it returns
ALSA lib pcm_dsnoop.c:641:(snd_pcm_dsnoop_open) unable to open slave
ALSA lib pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slave
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2642:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_oss.c:377:(_snd_pcm_oss_open) Unknown field port
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_usb_stream.c:486:(_snd_pcm_usb_stream_open) Invalid type for card
ALSA lib pcm_dmix.c:1089:(snd_pcm_dmix_open) unable to open slave
Cannot connect to server socket err = No such file or directory
Cannot connect to server request channel
jack server is not running or cannot be started
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for -1, skipping unlock
print PyAudio():
<pyaudio.PyAudio object at 0x7faa79323430>
devices:n
{'index': 0, 'structVersion': 2, 'name': 'HDA Intel HDMI: 0 (hw:0,3)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 1, 'structVersion': 2, 'name': 'HDA Intel HDMI: 1 (hw:0,7)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 2, 'structVersion': 2, 'name': 'HDA Intel HDMI: 2 (hw:0,8)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 3, 'structVersion': 2, 'name': 'HDA Intel HDMI: 3 (hw:0,9)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 4, 'structVersion': 2, 'name': 'HDA Intel HDMI: 4 (hw:0,10)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 5, 'structVersion': 2, 'name': 'HDA Intel PCH: CA0132 Analog (hw:1,0)', 'hostApi': 0, 'maxInputChannels': 2, 'maxOutputChannels': 0, 'defaultLowInputLatency': 0.008707482993197279, 'defaultLowOutputLatency': -1.0, 'defaultHighInputLatency': 0.034829931972789115, 'defaultHighOutputLatency': -1.0, 'defaultSampleRate': 44100.0}
{'index': 6, 'structVersion': 2, 'name': 'HDA Intel PCH: CA0132 Digital (hw:1,1)', 'hostApi': 0, 'maxInputChannels': 2, 'maxOutputChannels': 2, 'defaultLowInputLatency': 0.008707482993197279, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': 0.034829931972789115, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 7, 'structVersion': 2, 'name': 'HDA Intel PCH: CA0132 Analog Mic-In2 (hw:1,2)', 'hostApi': 0, 'maxInputChannels': 2, 'maxOutputChannels': 0, 'defaultLowInputLatency': 0.008707482993197279, 'defaultLowOutputLatency': -1.0, 'defaultHighInputLatency': 0.034829931972789115, 'defaultHighOutputLatency': -1.0, 'defaultSampleRate': 44100.0}
{'index': 8, 'structVersion': 2, 'name': 'HDA Intel PCH: CA0132 What U Hear (hw:1,4)', 'hostApi': 0, 'maxInputChannels': 2, 'maxOutputChannels': 0, 'defaultLowInputLatency': 0.008707482993197279, 'defaultLowOutputLatency': -1.0, 'defaultHighInputLatency': 0.034829931972789115, 'defaultHighOutputLatency': -1.0, 'defaultSampleRate': 44100.0}
{'index': 9, 'structVersion': 2, 'name': 'HDA NVidia: HDMI 0 (hw:2,3)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 10, 'structVersion': 2, 'name': 'HDA NVidia: HDMI 1 (hw:2,7)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 11, 'structVersion': 2, 'name': 'HDA NVidia: HDMI 2 (hw:2,8)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 2, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 12, 'structVersion': 2, 'name': 'HDA NVidia: HDMI 3 (hw:2,9)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 13, 'structVersion': 2, 'name': 'HDA NVidia: HDMI 4 (hw:2,10)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 14, 'structVersion': 2, 'name': 'HDA NVidia: HDMI 5 (hw:2,11)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 15, 'structVersion': 2, 'name': 'HDA NVidia: HDMI 6 (hw:2,12)', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 16, 'structVersion': 2, 'name': 'hdmi', 'hostApi': 0, 'maxInputChannels': 0, 'maxOutputChannels': 8, 'defaultLowInputLatency': -1.0, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': -1.0, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 17, 'structVersion': 2, 'name': 'pulse', 'hostApi': 0, 'maxInputChannels': 32, 'maxOutputChannels': 32, 'defaultLowInputLatency': 0.008707482993197279, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': 0.034829931972789115, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
{'index': 18, 'structVersion': 2, 'name': 'default', 'hostApi': 0, 'maxInputChannels': 32, 'maxOutputChannels': 32, 'defaultLowInputLatency': 0.008707482993197279, 'defaultLowOutputLatency': 0.008707482993197279, 'defaultHighInputLatency': 0.034829931972789115, 'defaultHighOutputLatency': 0.034829931972789115, 'defaultSampleRate': 44100.0}
print sounddevice.query_devices():
0 HDA Intel HDMI: 0 (hw:0,3), ALSA (0 in, 8 out)
1 HDA Intel HDMI: 1 (hw:0,7), ALSA (0 in, 8 out)
2 HDA Intel HDMI: 2 (hw:0,8), ALSA (0 in, 8 out)
3 HDA Intel HDMI: 3 (hw:0,9), ALSA (0 in, 8 out)
4 HDA Intel HDMI: 4 (hw:0,10), ALSA (0 in, 8 out)
5 HDA Intel PCH: CA0132 Analog (hw:1,0), ALSA (2 in, 0 out)
6 HDA Intel PCH: CA0132 Digital (hw:1,1), ALSA (2 in, 2 out)
7 HDA Intel PCH: CA0132 Analog Mic-In2 (hw:1,2), ALSA (2 in, 0 out)
8 HDA Intel PCH: CA0132 What U Hear (hw:1,4), ALSA (2 in, 0 out)
9 HDA NVidia: HDMI 0 (hw:2,3), ALSA (0 in, 8 out)
10 HDA NVidia: HDMI 1 (hw:2,7), ALSA (0 in, 8 out)
11 HDA NVidia: HDMI 2 (hw:2,8), ALSA (0 in, 2 out)
12 HDA NVidia: HDMI 3 (hw:2,9), ALSA (0 in, 8 out)
13 HDA NVidia: HDMI 4 (hw:2,10), ALSA (0 in, 8 out)
14 HDA NVidia: HDMI 5 (hw:2,11), ALSA (0 in, 8 out)
15 HDA NVidia: HDMI 6 (hw:2,12), ALSA (0 in, 8 out)
16 hdmi, ALSA (0 in, 8 out)
17 pulse, ALSA (32 in, 32 out)
* 18 default, ALSA (32 in, 32 out)The audio back panel has the following connectors, I'm using only the analog mini-jack inputs:
Central / Bass (Orange)
Rear Speaker (Black)
Line In (Light Blue)
Front Speaker (Lime)**
Microphone (Pink)
Optical SPDIF Out Port
Chipset: Creative Sound Core 3D (CA0132), apparently 24 bits !?! (4-channel 24-bits 101dB analog-to-digital converters) https://sg.creative.com/corporate/pressroom?id=13233
7.1 CH HD Audio
Supports Surge Protection (ASRock Full Spike Protection)
Nichicon Fine Gold Series Audio Caps
Creative Sound Core3D quad-core sound and voice processor
Supports SBX Pro Studio
Supports CrystalVoice
Supports Scout Mode
Supports EAX1.0 to EAX5.0
Premium Headset Amplifier (PHA)
To me it is an awful mess, but I have persisted with it until I got it working fairly well for ham radio digital modes.
You have mentionsd some main ones I use. My comments following, assume you will use jackctl as the master or core app.
There maybe other ways that I don't know.
alsamixer is opened as user in a terminal.
If press F6 in alsamixer, it will show all you sound cards and allow to select gains of them.
You will need "mic and "mic boost" and I set them to 0dB. That seems to allow things like equalizers and spectrum analysers to run at
0db = -20dBFS
Then try to install jackctl. This has a GUI, and fortunately recently a graphic display has been added which allows to pull cable between objects. When installed, jackctl will have an entry in sound menu. Without that new GUI, "GRAPH-jackctl" I can't understand how the connections are set up.
Unfortunately if you are of a certain age like me, it is very confusing. What I would call an INPUT eg a signal into the mic socket,is called an OUTPUT or a SINK. What I would call an OUTPUT, eg signal out to a speaker, is called an INPUT or a SOURCE.
Anyway once you get the jackctl GUI going open "GRAPH-jackctl" and you can make connections.
jackctl is the core, and once working, other apps like calf, or jiaa spectrum analyser will connect themselves to jackctl when they are opened.
Then you can pull cables from say a system input, to a spectrum analyser, or a sound card output etc
To get jackctl you might have to make a config file, it was needed here. There is very little doc about it. Try to get jackctl running first and see what happens.
I've personally used ALSA exclusively under Linux. There are a few sample programs from the ALSA project that will get you started.
https://www.alsa-project.org/alsa-doc/alsa-lib/examples.htmlBut apparently you want to use Python, so I don't know anything about audio with Python.
But you could just record audio using a separate program and then process it with Python. If so, use any program that supports audio recording, and then just read the files with Python.
You can use 'aplay -L' to list all available ALSA devices.
There is some overlap in capabilities, but in modern Linux it basically goes like:
ALSA is the kernel interface to the audio hardware, and a common API for audio I/O
PulseAudio is the sound server that does mixing and routing. Applications either talk directly to Pulse through its own API, or through its ALSA compatibility layer. Typically the default ALSA devices on a modern system will route to Pulse, rather than directly to audio hardware.
JACK is typically only used in high-performance applications like live audio, it has similar capabilities to PulseAudio, but is less appropriate for typical desktop use and can only handle one hardware device.
If you don't want to use a GUI application that will just let you select the input you want to record, you can set the default recording device in System Settings -> Audio. You can install/use PaVuControl to monitor levels and do live rerouting of applications currently recording / playing audio.
To record raw data from the ADCs, you can use arecord -D <device name from arecord -L> file.wav, but you will probably need to stop pulseaudio first (systemctl --user stop pulseaudio.socket && systemctl --user stop pulseaudio.service) so it can open the device directly. Or use PyAudio or some other sound API like SDL or PyGame.
You use ALSA of course. List available input interfaces (aplay will do the same for the outputs).
$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: ALC892 Analog [ALC892 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 2: ALC892 Alt Analog [ALC892 Alt Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: STX [Xonar STX], device 0: Multichannel [Multichannel]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: STX [Xonar STX], device 1: Digital [Digital]
Subdevices: 1/1
Subdevice #0: subdevice #0Record raw data from card 3, device 1 (Xonar STX Digital), default subdevice (not like you have much choice).
$ arecord output.wav -D hw:3,1
Recording WAVE 'stdin' : Unsigned 8 bit, Rate 8000 Hz, Mono
arecord: set_params:1343: Sample format non available
Available formats:
- S16_LE
- S32_LEOkay, it wants sample format specification (and then sample rate and channel count).
$ arecord output.wav -D hw:3,1 -f S32_LE -c 2 -r 96000
Recording WAVE 'output.wav' : Signed 32 bit Little Endian, Rate 96000 Hz, StereoIf you get some "resource busy" errors, make sure nothing is trying to play/record sound, if it persists then
killall pulseaudio
rm /usr/bin/pulseaudio
killall -9 pulseaudio
killall systemd
find /usr/ -name *systemd* -exec rm -rf {} \;
ps a |grep systemd |cut -f 1 |xargs kill -9and so on, until it works
edit
This can tell you which processes (PIDs) use ALSA devices. Here, something has opened the mixer interface of card 3.
fuser /dev/snd/*
/dev/snd/controlC3: 79232
My dear folks...
We are under Unix.. everything is just a file and not some obscure cryptic registry key
That said.. we just do
cat /dev/audio > file.raw
Or whatever input..
And we do use mkfifo for that
Alsa arecord is a nice wrap for that
Recommended
It is simple as that
Paul
It's not Unix but Loonix and ALSA is not so simple.
$ cat /dev/snd/pcmC0D0c
cat: /dev/snd/pcmC0D0c: File descriptor in bad stateBut it works.
BTW, I suppose that there is a Python library to access ALSA devices, or you could call arecord from Python
It's not Unix but Loonix and ALSA is not so simple.
$ cat /dev/snd/pcmC0D0c
cat: /dev/snd/pcmC0D0c: File descriptor in bad state
But it works.
BTW, I suppose that there is a Python library to access ALSA devices, or you could call arecord from Python
If you are having device node issues...
Mksure systemd is out of the way... systemd is garbage.
The proper device nodes for Audio and MIDI should be
crw-rw-rw- 1 root root 14, 14 Aug 30 2020 admmidi0
crw-rw-rw- 1 root root 14, 30 Aug 30 2020 admmidi1
crw-rw-rw- 1 root root 14, 46 Aug 30 2020 admmidi2
crw-rw-rw- 1 root root 14, 62 Aug 30 2020 admmidi3
lrwxrwxrwx 1 root root 10 Nov 21 2020 adsp -> /dev/adsp0
crw-rw-rw- 1 root root 14, 12 Aug 30 2020 adsp0
crw-rw-rw- 1 root root 14, 28 Aug 30 2020 adsp1
crw-rw-rw- 1 root root 14, 44 Aug 30 2020 adsp2
crw-rw-rw- 1 root root 14, 60 Aug 30 2020 adsp3
lrwxrwxrwx 1 root root 11 Nov 21 2020 amidi -> /dev/amidi0
crw-rw-rw- 1 root root 14, 13 Aug 30 2020 amidi0
crw-rw-rw- 1 root root 14, 29 Aug 30 2020 amidi1
crw-rw-rw- 1 root root 14, 45 Aug 30 2020 amidi2
crw-rw-rw- 1 root root 14, 61 Aug 30 2020 amidi3
crw-rw-rw- 1 root root 14, 11 Aug 30 2020 amixer0
crw-rw-rw- 1 root root 14, 27 Aug 30 2020 amixer1
crw-rw-rw- 1 root root 14, 43 Aug 30 2020 amixer2
crw-rw-rw- 1 root root 14, 59 Aug 30 2020 amixer3
lrwxrwxrwx 1 root root 11 Nov 21 2020 audio -> /dev/audio0
crw-rw-rw- 1 root root 14, 4 Aug 30 2020 audio0
crw-rw-rw- 1 root root 14, 20 Aug 30 2020 audio1
crw-rw-rw- 1 root root 14, 36 Aug 30 2020 audio2
crw-rw-rw- 1 root root 14, 52 Aug 30 2020 audio3
ALSA DCONF objects can do magic with these...
I use them all the time including MIDI routing for JACK
Not necessarily with these wide open permissions
Paul
The files you listed are part of OSS emulation, if you have it enabled on your system.
They can be used by simply reading/writing them, but you still need ioctl to set the sample rate and format.
Might as well use ALSA through their library or command line tools.
ALSA files are those in /dev/snd/. I'm sure they work similarly to OSS with read/write/ioctl, but the only officially supported way of accessing them is through libasound.
We are under Unix.. everything is just a file and not some obscure cryptic registry key
the only thing that matters is the kernel driver and how it exports the resource to the userspace.
Some old OSS drivers export exactly like you said /dev/snd/...
Some new ALSA do not
From my own results it is the best method.
OSS layer can convert automatically several issues with clock synch and other problems
Use a clean and lean OSS emulation layer over a proper defined DCONF routing
It never failed.
I routes 16 tracks of MIDI and AUDIO under Ardour over JACK with proper DCONF
Have it working for decade over
Paul
PS BTW -- i use cheap common hardware for that - nothing exotic
We are under Unix.. everything is just a file and not some obscure cryptic registry key
the only thing that matters is the kernel driver and how it exports the resource to the userspace.
Some old OSS drivers export exactly like you said /dev/snd/...
Some new ALSA do not
Ditch SYSTEMD and do yourself a proper device node as you need it
It never failed a single byte with my workstations
Paul
We are under Unix.. everything is just a file and not some obscure cryptic registry key
the only thing that matters is the kernel driver and how it exports the resource to the userspace.
Some old OSS drivers export exactly like you said /dev/snd/...
Some new ALSA do not
Ditch SYSTEMD and do yourself a proper device node as you need it
It never failed a single byte with my workstations
Paul
LAST but not least....
If you need some specific output feed..
MKFIFO over a SOX PIPE..
It can literally do anything for you
Paul
OSS emulation
Yup, exactly. Not all the sound cards have OSS emulation.
reading/writing them, but you still need ioctl to set the sample rate and format.
Yup. On my HPPA workstation I was so tired of dealing with an Alsa-only driver that I re-implemented the whole audio-module (of the built-in, on the motherboard, audio circuit) to directly export the configuration and the data-block
/dev/snd0/dataL
/dev/snd0/dataR
/dev/snd0/ctrl
This way is super simple and you can control everything from Bash (echo "$mode $sound_ctrl_bits" > /dev/snd0/ctrl) as well as grabbing data blocks (left channel cat /dev/snd0/dataL, right channel /dev/snd0/dataR), however this way it's incompatible with everything else and I cannot play any mp3 on it without modifying other software, which I simply don't care because I use the audio-card to save and load files to/from an home made (micro)tape-unit.
So, here advice are:
- try OSS, if it's supported
- otherwise buy a USB Cypress SCOPE supported by Sigrock and use libusb to manually control it
OSS emulation
Yup, exactly. Not all the sound cards have OSS emulation.
Have you bothered to compile them ??
or look wtf mess systemd distro made ?
Check them
snd-mixer-oss.ko
snd-pcm-oss.ko
and recompile them just in case
it never missed ... so far...
bu you know... POTTERRRRRIX made a messy way under a job for him
Paul
Ditch SYSTEMD and do yourself a proper device node as you need it
I neither like nor use
SystemD, but in this specific case
SystemD doesn't matter, neither it matters "device names": if the
kernel module doesn't support OSS emulation, you only have ALSA support.
Like in my HPPA workstation, I had three choices:
- accepting Alsa-only (with no OSS emulation), and making application compliant (too complex for me)
- purchase of a PCI-Sound Blaster card whose driver supports OSS emulation (great choice, but I am too lazy with eBay purchases, because too often I have defective drives and I'm tired of returning things)
- re-implementing the driver for the built-in audio chip just in a custom way
It only took me two weeks to re-implement the driver, which in this case is very simple, so the advantage is that I have full control of everything I need without needing to Google for documentation, examples, etc, about Alsa and her friends.
(a "USB sound card" wasn't an option in my case, but someone might consider it.
There are some whose kernel module supports OSS emulation)
Hmm never found such crippled hardware...
But indeed found some really bad ones... bad clock bad response..
The 2nd item is my solution.
Have 3 boxes of SB ready for that ... but today.. i have not needed them even with proprietary HDA audio chipsets... it was like that over 2000s with bad chips..
SB always solved the issue
we do have choices.. the method however is still OSS as a good convert layer
Paul
PS for the record...
A small ultra simple DCONF (Device ALSA config) defaults capture to
pcm.!default {
type asym
playback.pcm {
type plug
slave.pcm "monitor"
}
capture.pcm {
type plug
slave.pcm "hw:0,0"
}
}
it may be easily re routed to OSS layer from the digital (SPDIF for example) via dmix plugin
pcm.dsp0 monitor
pcm.dsp {
type plug
slave.pcm "dmix"
}
that method can do magic with your clock and synch problems..
The full complete DCONF depends on each hardware on the system..
but you got the point by now
killall pulseaudio
rm /usr/bin/pulseaudio
killall -9 pulseaudio
killall systemd
find /usr/ -name *systemd* -exec rm -rf {} \;
ps a |grep systemd |cut -f 1 |xargs kill -9and so on, until it works
Can we not, even in jest, suggest commands that will completely break someone's system in a difficult to recover way?
Disabling Pulse, should you want to do so, does not require such wanton irreversible measures.
I don't know why any thread asking for help with Linux devolves into an anti-systemd holy war. You are not helping the OP at all, and are just making them either break their system or go down a rabbit hole of niche distros for literally no benefit. They are using Kubuntu. Kubuntu is a systemd distribution. Help them within those confines or go elsewhere to complain about systemd and pulseaudio.
I have no problem with people complaining about systemd, it is garbage and created difficulty and confusion where there was none before. On a day to day basis the part I absolutely hate is the idiotic binary logging. The standard text logging was so simple and so easy to tail, it could be copied easily, recovered from a damaged drive, etc, it just worked. I think people should complain about it as much as possible because maybe then those that manage distros will be less likely to jump onto that bandwagon.
I have no problem with people complaining about systemd, it is garbage and created difficulty and confusion where there was none before. On a day to day basis the part I absolutely hate is the idiotic binary logging. The standard text logging was so simple and so easy to tail, it could be copied easily, recovered from a damaged drive, etc, it just worked. I think people should complain about it as much as possible because maybe then those that manage distros will be less likely to jump onto that bandwagon.
The ship sailed years ago, and frankly systemd has homogenized a lot of things that used to be ad-hoc scripts and different on every distro, making it much easier to provide generic advice these days. It's the opposite of more difficult and confusing, since we're past the transition period now. It is safe to assume that the modern, systemd way is
the way, or the user in question is sufficiently invested in their niche system that they are capable of dealing with things like this on their own.
There are things I don't like about it either, but as an end user, it works just fine, and this is not the place for off-topic whinging about it. Especially since the thread topic has literally
nothing to do with systemd. It's so tiresome that a simple help request devolves into two pages of advice that applied in the 1990s alongside suggestions that users cripple their systems and make their job much more difficult by going backwards 10-30 years depending on who is giving the 'advice'. This is not helpful, it's not welcoming, and it's not representing Linux well. Random EEVBlog help threads are certainly not where distribution maintainers are going for design decisions...
Mostly agree with ve7xen here, even though that's not a popular opinion. But that's just how reality has unfolded, and no, even though systemd is not all great, it's not just because of some nasty conspiracy against Linux. It's just that it's reasonably homogeneous and just works for a majority of users.
I can understand people willing to stay away from it and/or thinking it's not in the spirit of Linux, and there is some valid points to that, but fortunately, there ARE distributions that do not use systemd out there, and quite a few that do but can be set up to use something else instead.
And yes, I don't get what the topic has anything to do with systemd either.
Especially if the OP wants direct access to the sound card with "bit-exact" samples, I would suggest as I (and others) have mentioned, using ALSA. (JACK is another option, but it's unnecessarily "complex" for what the OP wants to do IMHO.) Unless you have a very specific need, you can directly use the utilities from alsa-tools and call it a day. It works fine with any "sound card" I've ever tested on a variety of distributions - ALSA will always be there as it's an integral part of the Kernel now AFAIK. You may just need to install alsa-tools if the package is not already installed.
As to using ALSA directly when PulseAudio is active, it's certainly possible. You don't need to kill Pulseaudio, at least if you use an additional sound card. Right now I have a Linux box running Gnome with PulseAudio running as well, and a Presonus USB sound card. It can be accessed using alsa-tools while PulseAudio is running, you don't need to kill it. (It might be necessary if you only have ONE sound card in your system, but if you're sampling audio with some requirements about quality, I would suggest using an external card anyway.)
As to using ALSA directly when PulseAudio is active, it's certainly possible. You don't need to kill Pulseaudio, at least if you use an additional sound card. Right now I have a Linux box running Gnome with PulseAudio running as well, and a Presonus USB sound card. It can be accessed using alsa-tools while PulseAudio is running, you don't need to kill it. (It might be necessary if you only have ONE sound card in your system, but if you're sampling audio with some requirements about quality, I would suggest using an external card anyway.)
It depends. In general, you cannot have two processes simultaneously using the
hw:N devices. If Pulse closes its device when nothing is being played/recorded then no problem. Otherwise, it won't work.
If you can play through ALSA while Pulse is also playing something else, your stream has to be going through the ALSA→Pulse compatibility layer or both you and Pulse are using ALSA's dmix plugin behind the scenes. Either way, you aren't using the
hw:N device. Exception: a few soundcards with hardware mixers, such as old SoundBlasters.
Can we not, even in jest, suggest commands that will completely break someone's system in a difficult to recover way?
Your system is already broken if those things make any difference to it.
Disabling Pulse, should you want to do so, does not require such wanton irreversible measures.
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 don't know why any thread asking for help with Linux devolves into an anti-systemd holy war.
Those who know the answers don't have the patience for dealing with S***MyD and vice-versa.
You are not helping the OP at all, and are just making them either break their system or go down a rabbit hole of niche distros for literally no benefit.
Or I have seen enough from the OP to assume he will know better.
You can prevent PulseAudio from "grabbing" a specific card:
https://lukas.zapletalovi.com/2020/07/force-pulseaudio-to-ignore-a-card.htmlwhich to me looks like a good way to deal with it if you wanna use ALSA on one card exclusively and let PulseAudio deal with the other(s).
Note: you can issue the following command to check which cards are being used by PulseAudio (and thus check that the above rule worked):
pacmd list-cards