Linux audio may be confusing for the uninitiated. As a system that has evolved and spawned at least two independent branches over time it tends to produce results that surprise or irritate the user. On the other hand it is open source software and thus can be fixed if you know what you do.
Over at reddit [rener2] was annoyed by the fact that listening to music on his laptop was a significantly worse experience under Linux than under Windows. Running Windows the output of the headphone jack covered the whole spectrum while his Linux set up cut off the low end resulting in a tinny sound. The culprit in this is the sound card: it has two different output paths for the internal speakers and the headphone jack. The signal for the internal speakers is routed through a high pass filter to spare them the embarrassment of failure to reproduce low frequencies.
When headphones are plugged in, the sound card driver is supposed to make the sound card bypass the filter and deliver the full spectrum. The authors of the Windows driver knew this and had it taken care of. In his video [rener2] runs us through the process of patching the ALSA driver while referencing the documentation of a sound card that he deems ‘similar enough’ to his Realtek ALC288.
Once you have your audio setup figured out, you should consider trying your hand at signal processing with octave. Or you could ditch poorly supported hardware completely and stick a decent sound card on your Raspberry pi.
i’ve had a Wolfson Audio Card attached to my Pi for over 2 years now. but 24-bit/192kHz lossless audio sounds the same as 16-bit/320kbit/44kHz compressed to me.
..and unrelatedly, whatever happened to the trend of sense via physical switching inside the line-out/headphone jacks? computers used to get a signal in order to know which jack had been penetrated and how to adjust the routing based on that. assignable outputs (profiles?) were also the norm, maybe they still are.
anyhow, it’s probably best to adopt digital audio output and stop tinkering with processing/filtering/levels at the source. however, pulling the digital stream from ports (or tapping hdmi) is probably less fun than fixing open source software.
>” 24-bit/192kHz lossless audio sounds the same as 16-bit/320kbit/44kHz compressed to me.”
Try running a signal generator and slowly sweeping upwards to 20 kHz. While the output will vanish somewhere between 13-16 kHz as you run out of hearing range, there will be occasional artifacts popping up where suddenly at 17-18 odd kHz you start to hear chirps and bleeps because of folding effects against the sampling rate.
This is no problem for compressed audio such as MP3 because it cuts off at 16 kHz anyways, but for things like live recordings and synthesizing sounds you yourself might do, it introduces an additional source of noise that makes the recording sound bad.
Your signal generator must not be generating a sine wave, because with 44 kHz audio there’s no folding until 22 kHz. Yes, you’re right, for producing audio, using a higher sample and bit rate is a big boon, in much the same way that editing photos with high color depth is better. But once you’re done editing, run it through a low-pass filter and export as 16-bit 48kHz or whatever, and it’ll sound perfect.
Higher sample rates can actually hurt in playback if your DAC has some distortion that creates audible sound from all the ultrasound. Higher sample depth doesn’t really hurt in playback at least, but it doesn’t help much if any either. For a much more eloquent and thorough explanation than I can give, check out this explanation from one of the fine folks at xiph.org.
Higher resolution (ENOB) is very useful when the engineer doing the mastering is used to analog recording and sets the level substantially less than full scale. The proper fix is to educate the engineer, but having the extra resolution is often easier.
I have to agree with high sample rates being more useful for recording (avoids aliasing), but the availability of cheap high SNR, high sample rate hardware is a boon for experimenting with ultrasonics. Someone even made an app that uses the speakers/microphones as a software sonar for power saving by switching off the monitor when the user is away.
44kHz ADC is only 2.7 samplers per cycle at 16kHz. That will have serious suckage. Sampling a 22kHz sine at 44kHz will output a constant. Sample a 21.999kHz signal for a full second at 44kHz and I think you will fail again. There is nothing wrong with the theory. Remember you cant’ get infinite sample samples over infinite time, and oversample at appropriate rates.
I can already tell you didn’t read and comprehend the article I linked.
This comment is so wrong. How do you not understand basic audio theory? There exists only 1 solution in between 1-20 000 Hz that fits those points. And your sound card/DAC will output that exact waveform.
No it won’t. As you are generating an arbitrary signal, it will shift in phase relative to your DAC clock rate, and that will cause amplitude modulation in the resulting signal as you approach the Nyquist limit. You could correct it with various means, but that would cause phase errors in the signal.
As pointed out above, at 16 kHz the DAC can only put out 2 – 3 discrete levels per cycle of the signal so it’s already a very crude representation of the sine wave you’re trying to produce
The issue is illustrated perfectly if you consider the sample rate of the DAC as if it were laying a row of pixels on a monitor. As your input signal runs out of phase with the “pixels” of your DAC, the result will necessarily get distorted
Example:
https://upload.wikimedia.org/wikipedia/commons/f/fe/Kell_factor2.png
“At 0.33 cycles/pixel, 0.66 times the Nyquist limit, amplitude can largely be maintained regardless of phase. Some artifacts are still visible, but minor.”
0.66 times the Nyquist limit for 44.1 kHz is 14.553 kHz and above this frequency, without special means such as oversampling (remember the DAC only runs at 44.1 kHz, so you don’t get “extra pixels”) it’s not possible to avoid this error. It always happens unless the signal you put into the DAC is pre-distorted the opposite way to counteract it.
“There exists only 1 solution in between 1-20 000 Hz that fits those points”
Only if you assume the solution must be a sine wave. Otherwise it could be anything.
More to the point. I would like for someone to present me a DAC with 44 kHz sample rate, that would actually output anything resembling a sine wave at 16 – 17 kHz and above – of course without being seriously low-pass filtered to that end but actually having a flat response up to 20-22 kHz.
There are no perfect reconstruction filters. The theoretically perfect filter would have to work backwards in time and have infinite delays, so no, it is not possible to put a digital representation of an arbitrary sample through the DAC and get a perfect result.
I get the feeling you need those : https://xiph.org/video/
I’m pretty sure only the early codecs for MP3 cut off at 16khz. The (patent ignoring) 3rd party codecs like Blade and Lame let higher pitches through (probably for better percussion) and I think the licensed coecs followed suit later.
/sbin/kldload /boot/kernel/sound.ko
/sbin/kldload /boot/kernel/snd_driver.ko
Problem solved.
On FreeBSD Unix. So you also need to format the hdd – to get rid of Linux – and install BSD, all process from format to full functional desktop syatem will only take around 10…15 minutes.
Bad joke to annoy and make fun of Linux fans.
Don’t read this and don’t take it in a bad way. Trying to “fish” for more unix followers.
You will end up “fishing” your pc out of the ocean if you do that again :P
You are missing the step where you fix the drivers.
He didn’t have to recompile the complete kernel. If you use the same kernel config and the same compiler, all you need to do is to rebuild that module. Nowadays it most likely also works across compiler versions, but I once had problems mixing a kernel built with GCC 2.95 with modules built with GCC 3.x because of differences in structure offsets.
And if it takes an hour to recompile the kernel, chances are that 90% of the drivers it is building are not used on your machine.
Is this native compilation on an ARM? If not, an hour means something is wrong. I have an 8 core AMD that builds kernels in 51 seconds.
rm -rf poettering
Oh don’t be childish. Systemd is really nice for administrators, and PulseAudio has been working great for many years. Personal attacks against Lennart Poettering will get you nowhere, and damage the free software community.
Engineer supporting scientific computing here (including some very low-level administration for some specialized hardware)… Systemd’s been a disaster for us, and “Lennart” is currently used here as an insult to describe shiny new RHCAs who try to change things without understanding what they do (“oh f**k me, what did the Lennart do now?”).
I’m sure it’s great if your use cases are ones that he thinks are interesting (because he’s made it pretty clear that if they aren’t, clearly, your use case is wrong).
I remember reading something about systemd´s problems, but cannot remember what it was or where. Do you have any links about it ? My currently systems are running old versions of linux, so I may not be affected yet, but when upgrading or new machines it would be good to know about the situation ….
Last time I had audio problems on Linux, I solved them by removing PulseAudio.
And yes, I recently did compile Firefox with ALSA support.
I’m a linux system admin and lenny’s work has been nothing but a pain in the ass.
ESPECIALLY logd and lenny’s reinvention of the DNS wheel.
As bad as Linux sound is at least you can compile most gnu linux stuff for it, even other posix compliant code if you can get the deps. Good luck compiling your favorite programs to run on Android aka bent Linux kernel and crap on top even if you are able to go FOSS. Effing Android sound and video drivers me we can mostly forget running even bin driver infected locked to one kernel Linux/Unix on most ARM tablets and phones.
I have to take issue with the title; the noted complaint isn’t an issue with Linux audio, it’s an issue with chipsets and drivers, and I had the exact same problem with my Windows 10 laptop, til I found the correct driver and bypassed the default filtering.
Anyway, if you have a laptop and are serious about recording and editing audio, you should buy a decent USB audio interface. They’re $100 ish new, and often available used. Check for drivers before selecting one; not all have known working Linux drivers.
I think the complaint is that it’s an indicative example of the state of non-server hardware drivers on Linux.
There is NOTHING in Linux as arcane, occult, and messed up as the audio. nothing.
Let’s see… WIFI? Runtime PM? SELinux? IMA/EVM? ACPI (ok, not Linux’ fault)?
not even close :-)
Getting an off the shelf printer working?
Wine? WiFi blobs I agree suck too!
All I can do is laugh. Linux has been out far too long for this to be an issue. Glad someone is getting on it.
I distinctly remember back in the 2.2 kernel days having to compile and add ALSA to a working Linux kernel because it wasn’t a standard part of the tree. Or you could pay for the commercial version OSS, otherwise your options were slim for compatible hardware.
I only found out about the high pass this past week when I was trying to diagnose the issue with a USB audio interface.
My biggest bugbear with audio on linux is the poor support for more than 2-in 2-out interfaces. These aren’t an issue in Windows/OS X word because most of the multi-channel interfaces use a software mixer to control the audio interface, allowing the output signal to be routed to channels 1+2 for speakers and channels 3+4 for headphones at the same time. Luckily for all the devices I’ve tested, settings can be saved to the firmware and they carry over in class compliant mode.