-
How do I route the audio signal from the 'line-in' of the sound card (Creative CA0132)?
You pick the correct source. Line-outs and speakers are sinks. Some list them separately, others in a single list. In either case, you pick the one you want from a list.Where can I learn about sound in KDE Plasma (Kubuntu 20.04), so to understand what to do?
KDE (as a desktop environment) is based on Qt, and Qt does have a QtMultimedia module which provides a QAudioInput class for processing input audio. If it is not installed, install it for Python (python3-{pyside2|pyqt5}.qtmultimedia, depending on which flavour of Python Qt5 support you prefer).How can I read the raw/unaltered ADC data from the line-in, preferably in Python for easier postprocessing?
First, use the QAudioDeviceInfo class to obtain the list of available sources, and pick the one that corresponds to your audio card line input. The names should be more or less obvious to us humans. The mode you want is QtMultimedia.QAudio.Mode.AudioInput.
Note that you'll want to use pydoc3 PySide2.QtMultimedia... or pydoc3.PyQt5.QtMultimedia... for the exact signatures, as the online documentation is a bit poor, containing lots of C++ code.
Next, create an instance of QtMultimedia.QAudioInput class, specifying the QAudioDeviceInfo (for the input you want), as well as the format you want. Set the volume to 1.0f to avoid samples being modified. You'll then get regular stateChanged signals, where your handler will check the reason, and if in the ActiveState, handle the bunch of input samples.
It should be quite straightforward, and you'll have an easy way to GUI'ify it too, at least the source selection and target file, unless you do the processing in the Python. Audio data is only something like 44100 or 48000 samples per channel per second, and Python can easily handle that; you might wish to use numpy/scipy arrays if you do more processing, though. -
I'll try to be really short
Imperative to understand and decide
Or you want that POTTERIX mediocre clone of so called desktop...
Or you want to setup a quality grade DAW
you will not have both
Potterix crap diverted and compromised all system resources with a spectacular monolithic glue of bad practices
Unix keep things simple by the book
Devices are meant to be administered by you and not put as some idiotic gui
That said you need to get rid of what is in the way
..
A DMIX plugin can do all you need .. by hand ... using ALSA CONFIG
Both pulse and systemd are useless then
And... they prevent you to control your hardware
Paul -
Pulseaudio and Jack has been replaced by Pipewire in modern Linux distros. It is real-time with low latency. Pipewire still uses ALSA kernel interface, but comes with its own better API.
See https://pipewire.org/ -
... you'll want to use pydoc3 ...
Wow, thanks for mentioning pydoc3! Always missed heaving such a tool (didn't know about it before).
With pydoc3 -b it even opens a webpage with all the local docs, and has a search, beautiful.
From man pydoc3Quotepydoc3 <name> ...
Show text documentation on something. <name> may be the name of a
Python keyword, topic, function, module, or package, or a dotted
reference to a class or function within a module or module in a
package. If <name> contains a '/', it is used as the path to a
Python source file to document. If name is 'keywords', 'topics',
or 'modules', a listing of these things is displayed.
...
pydoc3 -b
Start an HTTP server on an arbitrary unused port and open a Web browser
to interactively browse documentation.
At first I've searched online for pro and cons between PySide2 and PyQt5, and chose PySide2, but I'm a code-monkey and most of the examples seems to be for PyQt5, so I've just installed both:Code: [Select]sudo apt update
sudo apt install python3-pyqt5.qtmultimedia
sudo apt install python3-pyside2.qtmultimedia
sudo apt install qtmultimedia5*Code: [Select]apt list *qtmultimedia*
Listing... Done
python3-pyqt5.qtmultimedia-dbg/focal 5.14.1+dfsg-3build1 amd64
python3-pyqt5.qtmultimedia-dbg/focal 5.14.1+dfsg-3build1 i386
python3-pyqt5.qtmultimedia/focal,now 5.14.1+dfsg-3build1 amd64 [installed]
python3-pyqt5.qtmultimedia/focal 5.14.1+dfsg-3build1 i386
python3-pyside2.qtmultimedia/focal,now 5.14.0-1~exp1ubuntu5 amd64 [installed]
python3-pyside2.qtmultimediawidgets/focal 5.14.0-1~exp1ubuntu5 amd64
qml-module-qtmultimedia/focal,now 5.12.8-0ubuntu1 amd64 [installed,automatic]
qml-module-qtmultimedia/focal 5.12.8-0ubuntu1 i386
qtmultimedia5-dev/focal,now 5.12.8-0ubuntu1 amd64 [installed]
qtmultimedia5-dev/focal 5.12.8-0ubuntu1 i386
qtmultimedia5-doc-html/focal,focal,now 5.12.8-0ubuntu1 all [installed]
qtmultimedia5-doc/focal,focal,now 5.12.8-0ubuntu1 all [installed]
qtmultimedia5-examples/focal,now 5.12.8-0ubuntu1 amd64 [installed]
qtmultimedia5-examples/focal 5.12.8-0ubuntu1 i386
pydoc3 -b
About audio in Linux, for now my understanding is like this:
- there are (kernel) hardware drivers for each chipset
- on top of the drivers sits another sound component ALSA (Advanced Linux Sound Architecture)
- ALSA replaced the former, now discontinued, OSS (Open Sound System)
- side info, ALSA can have an OSS compatibility mode (as a compilation switch) to trick old OSS applications into working with ALSA, but usually the switch is not set at compilation time, therefore nowadays there is no /dev/audio and alike, as it used to be in OSS
- on top of ALSA sits PulseAudio (and/or JACK), which mostly is in charge with handling and routing audio data streams between applications, or between ALSA and applications
- PulseAudio is a higher abstraction layer, therefore PulseAudio is not aware of all the audio features available in the hardware of each soundcard
- usually, JACK inhibits PulseAudio, but there are tools to make them work together (I didn't try)
About the existing hardware, inside the desktop there are 3 sound cards + an external USB soundcard
- one from the i7 CPU, i7 has an embedded video card which supports HDMI audio
- one from the nVidia GPU, nVidia video cards also support HDMI audio streams
- motherboard audio chip Creative3D (CA0132)
- an external USB audio card (which in fact is a DSP devboard, eZdsp C5535 with a firmware that turns the devboard into a generic USB soundcard)
There is a catch, the physical audio panel (5 x 3.5 mm Jacks) is common to all the 3 internal sound cards, has detector switches for plugged/unplugged jacks, and even worst, each of these 5 jacks can be reconfigured as an input/output/mic/headphone
('hdajackretask' can show/change the physical jacks assignment - if not present, install it with 'sudo apt install alsa-tools-gui').
Learning to handle audio from Python, but this post already got too long. Will shoot more software questions over the weekend. Thank you all for the help so far. -
- on top of ALSA sits PulseAudio (and/or JACK), which mostly is in charge with handling and routing audio data streams between applications, or between ALSA and applications
- PulseAudio is a higher abstraction layer, therefore PulseAudio is not aware of all the audio features available in the hardware of each soundcard
- usually, JACK inhibits PulseAudio, but there are tools to make them work together (I didn't try)
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. -
- on top of ALSA sits PulseAudio (and/or JACK), which mostly is in charge with handling and routing audio data streams between applications, or between ALSA and applications
- PulseAudio is a higher abstraction layer, therefore PulseAudio is not aware of all the audio features available in the hardware of each soundcard
- usually, JACK inhibits PulseAudio, but there are tools to make them work together (I didn't try)
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.
I have no idea, but for the OP's assistance, is Pipewire supported when using Qt or is it at a lower independent level that doesn't affect Qt sound ops? -
If pulseaudio is giving you trouble by locking a specific device (which I doubt, because ALSA/pulse is these days configured to share access), then all you have to do is to call your program using the pasuspender utility:
$ pasuspender -h
pasuspender [options] -- PROGRAM [ARGUMENTS ...]
Temporarily suspend PulseAudio while PROGRAM runs.
-h, --help Show this help
--version Show version
-s, --server=SERVER The name of the server to connect to
No need to kill anything, no need for any irrelevant systemd whinging. PKTKS, I know you want to wage your holy war everywhere and every time you get the chance, but for f..k sake, whether it is mknod/udev or systemd creating the device files and starting the services makes literally zero difference here.
Also, the multiple recommendations of pipewire are irrelevant to the OP's question. And until pipewire is actually shipped by distributions, you don't want to start replacing PulseAudio and what not with that, especially if you don't know what you are doing. It is a good way to break one's system.
Finally, nobody seems to have actually read what the OP posted - there is no problem whatsoever with his setup, Pulse or anything else!
The messages from his program are completely normal - PyAudio is a Python library that is able to work with different audio systems, so the "errors" it outputs are because it is probing for the presence of the various backends.
Could we, please, stop these nonsensical rants and giving advice to replace the car's engine because you think Rudolph Diesel was an idiot whenever someone asks how to refill the coolant?
OK, with that out of my system:
OP, you don't need to install anything apart from PyAudio. No need for Jack (please remove it, it will cause conflicts), PulseAudio is installed by default, there is no need to mess with it.
The simplest way to achieve what you want to do is to use a program like Audacity - it allows you to generate the various waveforms in the editor and play them as well, including device selection. Open Audacity, Generate->Tone. Done.
If you want to work using Python, then you can use PyAudio e.g. as described here:
https://people.csail.mit.edu/hubert/pyaudio/docs/
You create the samples for your sine wave in Python and use PyAudio to play them. PyAudio abstracts all the low level audio complexity for you already, so no need to mess with PulseAudio, Jack, ALSA whatever!. As long as your machine has sane defaults for sound (all modern distros do, certainly Ubuntu!) and your sound is working e.g. with Youtube, it will work out of the box.
Then you use the mixer tool to send the sound to the right device while the sound is playing. E.g. in KDE (since you are using Kubuntu), go to the taskbar and the mixer is there. You can move the stream to the right device there. It will also remember it and do it automatically for you next time. The other option is pavucontrol tool that has been mentioned before. It does the same thing.
This device selection can be also done programmatically but it is unnecessarily complex for what you want to achieve.
-
All of the above [ALSA/Pulse] 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.
The desktop is Kubuntu 20.04 LTS (Focal Fossa), which does not have PipeWire yet.
I've read that it's not trivial to backport pipewire, so I didn't try to install it, also, since PipeWire has become the default audio in Ubuntu only starting with this year, it means less examples and tools available.
To learn, I'll prefer something with more tools, docs and examples. In terms of speed, the desktop is an i7-4790K/4.4GHz/32GB, it shouldn't be a problem to measure live distortions of a single channel, and latency on a constant sinusoidal signal doesn't matter. PipeWire seems too new, and with no particular advantage for this application (live FFT + live display of THD and THD+noise).
Does PipeWire has any advantage for which it might worth the effort of installing it? -
The desktop is Kubuntu 20.04 LTS (Focal Fossa), which does not have PipeWire yet.
I've read that it's not trivial to backport pipewire, so I didn't try to install it, also, since PipeWire has become the default audio in Ubuntu only starting with this year, it means less examples and tools available.
To learn, I'll prefer something with more tools, docs and examples. In terms of speed, the desktop is an i7-4790K/4.4GHz/32GB, it shouldn't be a problem to measure live distortions of a single channel, and latency on a constant sinusoidal signal doesn't matter. PipeWire seems too new, and with no particular advantage for this application (live FFT + live display of THD and THD+noise).
Does PipeWire has any advantage for which it might worth the effort of installing it?
No, don't do that. It is completely irrelevant to your problem.
PipeWire is a future replacement for the PulseAudio audio server, but you both don't need it and if you don't know what you are doing, you are likely to hose your system up completely.
Either way, there is no point, the default sound server will work just fine for what you need.
If you are interested how the various Linux audio layers fit together, there is a good explanation here:
https://www.techradar.com/news/audio/linux-audio-explained-685419
It doesn't cover PipeWire because it is an older article, but PipeWire fills the same role as PulseAudio/Jack.
-
3. - How can I read the raw/unaltered ADC data from the line-in, preferably in Python for easier postprocessing?
This is the specific point I had in mind when recommending bypassing all the sound server and multimedia framework turd and talking to ALSA directly.
ALSA is all the kernel drivers for soundcards plus a library (libasound) for talking to them though their device files in /dev/snd/ which also includes a framework of "plugins" for sample rate conversion, mixing from many applications etc, but you don't need to use them. Open the hw:N device and you have your bit-perfect playback/recording, provided that nothing else is conflicting with your use of the soundcard at the time. -
Got it, thank you.
About generating and playing samples, this won't be needed. The signal is generated outside of the computer by a physical circuit, an LC oscillator (I named it Peltz-Wyatt oscillator because it's a Peltz oscillator combined with a Wyatt current source in the hope of lowering the distortions existing in the sinusoidal signal).
- at first, I've evaluated the distortions with an oscilloscope, by eyeballing at the waveform, then display it as a FFT on the oscilloscope, but the oscilloscope ADC is only 8 bits, so I wanted a more precise measurement
- then, I've used an USB sound card, but that card seemed very noisy, so I wanted to use the line-in from the onboard sound card instead
- so far I've managed to use 'ARTA' and 'baudline' (programs that can display live audio spectrum and THD) but only with the USB soundcard, couldn't make them use the line-in instead
- apart from this, each measures the THD in its own way, I would like more control, and thus the idea of writing my own tool, as a Python exercise in audio.
This is the generator I want to measure its distortions, the jack connector on the left is the audio out to go into line-in of the onboard soundcard.
-
You can always record a WAV file and analyze it later with whatever tools.
For a real time analyzer, I tend to use JAAA, it is reasonably well thought out and accurate, but also has annoying warts like no horizontal log display and it's a bit of work to compile if not provided by the distribution.
http://kokkinizita.linuxaudio.org/linuxaudio/ -
3. - How can I read the raw/unaltered ADC data from the line-in, preferably in Python for easier postprocessing?
This is the specific point I had in mind when recommending bypassing all the sound server and multimedia framework turd and talking to ALSA directly.
ALSA is all the kernel drivers for soundcards plus a library (libasound) for talking to them though their device files in /dev/snd/ which also includes a framework of "plugins" for sample rate conversion, mixing from many applications etc, but you don't need to use them. Open the hw:N device and you have your bit-perfect playback/recording, provided that nothing else is conflicting with your use of the soundcard at the time.
Well, you could do it directly with ALSA but there isn't much/any processing going on normally, so even the default PulseAudio input is most often fine - as long as you are working at the native samplerate of the hardware and no resampling is going on (e.g. trying to record at 44.1kHz but the hw supports only 48kHz -> Pulse will resample it on the fly for you).
So I would really really keep things simple. A cheap computer soundcard isn't the right tool for the job for accurate measurements of low distortions anyway. -
TBH resampling is probably fine in this application, unless a genuinely atrocious algorithm is used, and the distortion is not low
However, if you want to avoid it, it surely depends on what other applications are doing and on system configuration. With ALSA bult-in mixer plugin, the hardware always runs at a fixed sample rate (48kHz by default) and everything is resampled to that. Even if those new sound servers are smarter about it, there is nothing they can do when two applications use different sample rates - at least one will be resampled. -
Got it, thank you.
About generating and playing samples, this won't be needed. The signal is generated outside of the computer by a physical circuit, an LC oscillator (I named it Peltz-Wyatt oscillator because it's a Peltz oscillator combined with a Wyatt current source in the hope of lowering the distortions existing in the sinusoidal signal).
- at first, I've evaluated the distortions with an oscilloscope, by eyeballing at the waveform, then display it as a FFT on the oscilloscope, but the oscilloscope ADC is only 8 bits, so I wanted a more precise measurement
- then, I've used an USB sound card, but that card seemed very noisy, so I wanted to use the line-in from the onboard sound card instead
- so far I've managed to use 'ARTA' and 'baudline' (programs that can display live audio spectrum and THD) but only with the USB soundcard, couldn't make them use the line-in instead
- apart from this, each measures the THD in its own way, I would like more control, and thus the idea of writing my own tool, as a Python exercise in audio.
This is the generator I want to measure its distortions, the jack connector on the left is the audio out to go into line-in of the onboard soundcard.
I am not sure a cheap sound card is a good way to perform such measurements, though. However, feel free to try. What has been said above still applies, just instead of generating and writing samples you will need to read them. PyAudio has examples for that as well, otherwise there are plenty of examples here:
https://www.geeksforgeeks.org/how-to-play-and-record-audio-in-python/
And also, as magic said above, you don't need to write the code to record the audio yourself - use e.g. Audacity to record the signal from a device directly into a file (e.g. wav or raw format) and then use another tool to analyze it.
For data conversions and analysis, such as FFT and similar you should have a look at Numpy:
https://numpy.org/
And specifically its use for audio/video processing:
https://new.pythonforengineers.com/blog/audio-and-digital-signal-processingdsp-in-python/
-
You can always record a WAV file and analyze it later with whatever tools.
For a real time analyzer, I tend to use JAAA...
I need live measurement, not recorded, so I can tweak the physical circuit while live watching at its THD.
Jaaa is in the ubuntu repos (sudo apt install jaaa), tried it some days ago and I couldn't figure how to make it listen to the signal coming from line-in (run it from either its KDE launcher or from terminal 'jaaa -A -d hw:1').
Either way, I want to at least learn more by writing something, than to endlessly google for error messages while fiddling with somebody else's software (i.e. 'baudline' only knows OSS or JACK, JACK freezes any other PulseAudio AV streams, while ALSA in ubuntu was not compiled with the OSS emulation switch, so I had to make 'baudline' read from stdin instead and launch it with 'parec --format=s16le --channels=1 --latency-msec=5 | ./baudline -stdin', and so on, all kinds of workarounds depending on what the existing programs can or can't do). -
jaaa -A -d hw:1
That's exactly how it's done. You can use -C instead of -d to disable signal generation functions, less chance of conflict with other software. With some hardware, capture sample rate must be the same as ongoing playback.Code: [Select]$ jaaa -A -C hw:0
playback : not enabled
capture :
nchan : 2
rate : 48000
frsize : 1024
nfrags : 2
format : S32_LE
Connected to ALSA with 2 inputs and 0 outputs -
About audio in Linux, for now my understanding is like this:
- there are (kernel) hardware drivers for each chipset
- on top of the drivers sits another sound component ALSA (Advanced Linux Sound Architecture)
yup, there are kernel modules (drivers) for each chipset, some driver have both ALSA and OSS-emulation, some only have OSS (very old code, kernel 2.2, 2.4, and early 2.6), some have only ALSA
Then there is also Alsa-OSS emulation, so basically you can have OSS emulation at two levels
- kernel level
- userspace level
it entirely depends on the chipset || on the kernel version || sometimes on specific kernel patches || on how Alsa is compiled (with/out the magic OSS-emulation switch).
-
OSS is irrelevant on Linux. There is no need to worry about it unless you wan to impress your friends with cat sound.wav >/dev/dsp, but if you want then you have no friends anyway, so OSS is irrelevant on Linux.
-
Either way, I want to at least learn more by writing something, than to endlessly google for error messages while fiddling with somebody else's software (i.e. 'baudline' only knows OSS or JACK, JACK freezes any other PulseAudio AV streams, while ALSA in ubuntu was not compiled with the OSS emulation switch, so I had to make 'baudline' read from stdin instead and launch it with 'parec --format=s16le --channels=1 --latency-msec=5 | ./baudline -stdin', and so on, all kinds of workarounds depending on what the existing programs can or can't do).
You should probably avoid anything requiring Jack or OSS. There are more modern/up to date tools available.
Jack is complex, conflicts with PulseAudio, so one has to mess with all sorts of things to get it to run - plus not needed for your application, it is meant for low latency audio e.g. in live recording or performances and very few applications actually use/support it (e.g. Ardour DAW was/is one of its major users).
OSS is a good 20 years or longer obsolete and if some application still requires it it means it hasn't been maintained/updated in ages. I mean, Baudline FAQ talks about Mandrake 7 and Redhat 6.2 - that was released 22 years ago!
If you want a current version that actually supports ALSA or PulseAudio properly, you need to pay for it:QuoteA focus on audio. The subscription baudline 1.09 has the following additions:
Advanced Linux Sound Architecture (ALSA) driver support
Pulse Audio driver support
Ported to Raspberry Pi ARM systems
Works on Mac OS X Catalina (10.15)
Now works with XQuartz 2.7.11
Some JACK and Core Audio bug fixes
Improved audio playback latency
(see http://baudline.com/news.html )
-
OSS is irrelevant on Linux. There is no need to worry about it unless you wan to impress your friends with cat sound.wav >/dev/dsp, but if you want then you have no friends anyway, so OSS is irrelevant on Linux.
meh, so I am out. -
https://app.box.com/s/glmsuoc0f43cipz3hzcxw3bxwb2dfc0z
Above the ham radio desktop with Jack, Calf EQ /Spectrum, Fldigi (BPSK31) and Pulse ( Firefox audio, Pandora etc)
Jack was a drama to get going, mainly by lack of manual. Now it seems to work fairly well so I am reluctant to update
This is Fedora 32 , I will update in about 2 ~3 years.
Latency:
patch system capture to system playback : about 7 ms
via the calf EQ/SA : about 12 ms
Latast jack ver is 0.9.7 dated 2022-04-02
Add: In the end, I think the only items to get jack going
1. >Options> start script : pulseaudio -k
>Options> after start script : pacmd load-module module-jack-source channels=2; pacmd load-module module-jack-sink channels=2;
2. run alsamixer to set 0dB so that 0dB = -20dBFS -
Well I understand that some folks new to DAW grade may be confused...
and may be lost with some complicated things...
However.. as the steps go anyone will understand that INTERPRETED interfaces and GUIs have absolute ZERO place at real-time high quality AUDIO and quality Instrumentation..
Obvious reasons interpreted is just a crap dog slow shit.
Even dedicated C interfaces have issues when hardware clock is not friendly
With REAL MIDI bus you may have external clock synch..
but 99% cases you don't
I have made some cute TOYS (yepo they are just my toys) to interface UNIX with JACK along last years..
Just for fun I have some handy toys to check how good or bad I can use them..
- A FULLY FUNCTIONAL Function Generator s/ spectrum + Modulator LADSPA support plugin bay
- A FULLY FUNCTIONAL JACK ANALYSER with quality HD graphic CUSTOM FILTERS and SPECTRUMs
so far so good all the instruments can work very reliably under JACK (including Ardour recording)
The setup and some shots attached below...
These are TOYS made to push limits and configure my workstations...
All C pure C and GTK based... nothing capable to stress upgrades..
Absolute ZERO systemd and UDEV - all customized device nodes..
One called JACKnerator ... the other JACKAnalyser (JA for short)
Just fun
Paul
PS> I made this today in kinda 15 seconds...
I have seen some funny typos... pl give me a break.. they are just kid keyboard typos..
i am not thatttt ignorant in eng ... .. typos as they are .. i will not fix that ssssh
last shot is an FM (narrow) modulated generated signal... instruments can really go up to 500KHz nicely
-
Well I understand that some folks new to DAW grade may be confused...
and may be lost with some complicated things...
If you want to insult people who were probably editing live audio in Linux before you have even heard about it - well, be my guest.QuoteHowever.. as the steps go anyone will understand that INTERPRETED interfaces and GUIs have absolute ZERO place at real-time high quality AUDIO and quality Instrumentation..
Obvious reasons interpreted is just a crap dog slow shit.
Even dedicated C interfaces have issues when hardware clock is not friendly
With REAL MIDI bus you may have external clock synch..
but 99% cases you don't
I have made some cute TOYS (yepo they are just my toys) to interface UNIX with JACK along last years..
Just for fun I have some handy toys to check how good or bad I can use them..
- A FULLY FUNCTIONAL Function Generator s/ spectrum + Modulator LADSPA support plugin bay
- A FULLY FUNCTIONAL JACK ANALYSER with quality HD graphic CUSTOM FILTERS and SPECTRUMs
...
PS> I made this today in kinda 15 seconds...
last shot is an FM (narrow) modulated generated signal... instruments can really go up to 500KHz nicelyQuoteAll C pure C and GTK based... nothing capable to stress upgrades..
Absolute ZERO systemd and UDEV - all customized device nodes..
And none of that is relevant to the OP's problem in the slightest. As always with your rants.
Please, keep this BS out of every thread. You tend to jump into literally everything that you evidently know little (but still have STRONG opinions) about, rant about unrelated/irrelevant things such as your favorite systemd bugbear or some corporate conspiracy/malfeasance, recommend stuff that is both irrelevant to the original poster in the best case and outright dangerous/detrimental in the worst (such as breaking a perfectly fine and working audio setup for no reason) - and not addressing the issue being asked about at all.
Thank you. -
No my dear... I take no insults.. and issue none.
The OP is confused HOW setting up a proper device node system.
I put some good directives..
I will not tolerate your gratis insults btw. Let us both just keep sane.
If I would insult someone you would already know now...
Not never my point
Paul