/tech/ - Technology

General audio software thread as well I guess, since we need something more than this to discuss. Discuss ways of improving the Linux audio mess.

ClipboardImage.png (u)
[Hide] (87.3KB, 1368x575)

>>91 (OP) 
>>92
>What's the simplest way to work with Linux sound?
In practice? Just stick with ALSA plus JACK for DAWs and other audio work and run anything that requires PulseAudio through apulse. PulseAudio just adds another layer of mess above ALSA, aka more stuff that can break, and I've had more problems with it than ALSA on its own.
Your main alternatives are OSS4 and sndio. I have no idea if anyone uses OSS4 but it sounds cool even with the poor hardware and software support nowadays, while sndio is mostly used by OpenBSD users and Voidfags. There's also whatever the fuck PipeWire is, which is trying to replace PulseAudio, JACK, and some video stuff. I know jack shit about it, but it's by a Red Hat employee so there's a good chance it will be cancer.
>Discuss ways of improving the Linux audio mess
Maybe some OSS4 fags can chime in, but it sounds promising to me.

>>91 (OP) 
>If I install Gentoo 
On Gentoo you can just enable the alsa USE flag in your /etc/portage/make.conf and enable the relevant options for ALSA and the HD audio in Linux kernel config (i.e. after you run make menuconfig) The tl;dr for PukeAudio is that you enable the kernel options that the ALSA/PukeAudio gentoo wiki articles tell you to enable and just enable the pulseaudio USE flag globally in your /etc/portage/make.conf 

https://wiki.gentoo.org/wiki/ALSA#Kernel
https://wiki.gentoo.org/wiki/PulseAudio#Kernel
https://wiki.gentoo.org/wiki//etc/portage/make.conf#USE

>>121
this.

If anyone uses mpd + alsa, make sure to resample to 32bit with libsamplerate. Audible difference.

Since this thread exists, I'll repost >>>/v/23570

Save this to ~/.asoundrc
possible language: rust, relevance: 10
pcm.!default {
        type asym

        playback.pcm "plug:Output"
        capture.pcm "plug:Input"
}

pcm.Output {
        type dmix

        ipc_key 1024
        ipc_perm 0666
        slave {
                pcm "hw:FIXME,0"

                rate 48000
                periods 128
                period_time 0
                period_size 2048
                buffer_size 32768
        }
}

pcm.Input {
        type dsnoop

        ipc_key 1025
        ipc_perm 0666
        slave {
                pcm "hw:FIXME,0"

                rate 48000
                periods 128
                period_time 0
                period_size 2048
                buffer_size 32768
        }
}Replace FIXME with your audio device number. You can find out what it is by doing aplay -l if you don't have PulseAudio installed or running.

>>91 (OP) 
Whatever you do, audio is shit on Linux. If you have one of these generic on board sound chips it probaby won't be much of a problem, not matter which route you go. But try using some expensive firewire audio interface and you'll have to fight dropouts and shit.
Most consumer sound cards have mixing functionality already included so you could theoretically use bare alsa. However if you have a soundchip that can't mix you could only ever have one application at a time play audio unless you install something like pulseaudio that brings its own software mixing.
Never had any luck with Jack. It does achieve lower latencies but I never could get it to run without timing issues/jitter/dropouts. I'd rather use windows for that stuff, I can't imagine it being very fun running six gorillion VST plugins through wine.
Schismtracker and Renoise work fine though and of course limitations can sometimes lead to creativity.

>>406
>However if you have a soundchip that can't mix
>What is dmix (literally post above)
<https://alsa.opensrc.org/Dmix
>NOTE: For ALSA 1.0.9rc2 and higher you don't need to setup dmix for analogue output. Dmix is enabled by default for soundcards which don't support hardware mixing. You still need to set it up for digital outputs.
You don't know what you are talking about, go back.

boomer_wii_punch.png (u)
[Hide] (139.2KB, 1561x753)

>>91 (OP) 
>alsa + pulseaudio but run both of them through JACK
>you could use apulse to get rid of pulseaudio but for whatever reason in practice, it doesn't work as cleanly
>for an alsa + JACK only build, slam this into your .asoundrc
[code]
pcm.rawjack {
    type jack
    playback_ports {
        0 system:playback_1
        1 system:playback_2
    }
    capture_ports {
        0 system:capture_1
        1 system:capture_2
    }
}
pcm.jack {
    type plug
    slave { pcm "rawjack" }
    hint {
        description "JACK Audio Connection Kit"
    }
}
pcm.!default {
    type plug
    slave { pcm "rawjack" }
}
[/code]
i don't do any music stuff but it does make recording certain sources much easier with JACK

1455236569213.jpg (u)
[Hide] (101.6KB, 775x1523)

Redpill me on PipeWire. Do any of you fags use it? Is it any good? I'm likely reinstalling Void Linux soon and sadly sndio isn't an option because not everything I use supports it.

>>1949
Have you searched "<program you use> pipewire"?
>sndio not supported
>let me quickly ask about something also as obscure
Really nigger?

>>1950
PipeWire isn't exactly "obscure" now: it's supposedly big with Archfags who are sick of PulseAudio, and Fedora's using it by default with Ubuntu close behind. It also has a better ALSA plugin than sndio's (which only supports playback) and can spin up a pulseaudio server if you really need one for whatever reason.
Chances are, I'll probably go with ALSA +apulse again, since I'm not using Wayland (thanks Nvidia) and PipeWire makes screen recording on Wayland much easier. Mostly just wanted to hear if anyone here has tried it yet and how it worked for them.

>>1952
What's wrong with plain ALSA? ALSA is the bottom of Linux audio stack, sndio on Linux is implemented on top of it. If it is about sharing audio device, dmix is enough for most use cases.
One case ALSA fails to cover is switching device during playback. It is possible to rig some acpid scripts together to get this feature, but restart the program just work.

>>1949
>Void Linux
Just use pulseaudio, it's been surprisingly very smooth in my experience and the experiences of other void users too. Pure alsa works fine too but don't count on apulse too much.

>>1957
>What's wrong with plain ALSA?
Nothing, but it doesn't have separate volume controls for every application which can be impractical. This is why I chose to stick with pulseaudio even though the original reason I got it was because the dumpster fire known as wine won't output audio without it

>>1966
Separate volume controls is typically implemented by each individual application. What program do you use doesn't have that?

>>1967
>What program do you use doesn't have that?
Games & emulators mainly, the vast majority of them don't have proper audio controls of their own.

The only problem with pulse usually is that its defaults are bad quality (default resampling method is poor quality, while it defaults to 44.1kHz which is outdated, since a lot use 48kHz now), all while pulseaudio could not properly support some bluetooth setup that got all its hate which I don't even care about ever using.

Albeit bad defaults, pulse can actually be have transparent quality and support native playback of high fidelity audio without the need to resample (avoid-resampling) which is great for the CPU.

Is there any way to force pipewire to adapt to the native samplerate playback just like pulseaudio's avoid-resampling?

I don't want to be using a music editor at 96kHz natively and have it be downsampled back to 48kHz again, the problem is not about "audiophile bullshit" but about the wasted CPU and latency caused by unnecessary downsampling which I don't even need, I'm not using a portabledevice/laptop/bluetooth that benefits with downsampling.

Pipewire has great defaults which resamples to and have native 48kHz which most consumer video and audio formats already have. Although the default was better than pulseaudio's defaults, It's just worse if it's gonna be stuck on 48kHz only or two samplerates.
I want to know if there's a way to avoid resampling since the docs weren't clear enough.

I don't like how it's already a Plasma dependency either but that's Red Hat for you, your distro is just a RHEL cushion.

>>2018
>Albeit bad defaults, pulse can actually be have
*actually have
Also, adding to this, I don't see the point of resampling to 48kHz strictly which pipewire does. Would be a waste if you had good audio card, I don't even know which library or resampling method/algorithm it uses.

>read all posts in audio thread
>make pulse do some retarded shit soo it uses more CPU
>it makes no impact because my headphone is trash
It is so hard being poor.

>>2149
Good headphones aren't expensive. Just do some research.