Linux Audio Is Being Further Modernized With The 4.1 Kernel

[stqn]

That may not be possible in software... depending on how it's been implemented, the whole thing could be handled in hardware, with the kernel sound system having no idea that this behaviour is happening.

That?s possible I*guess, but with my previous motherboard it was a software update that suddenly prevented me from having sound on the speakers when my headphones were plugged in.

[Nobu]

You confused distro and user here. Don't want PA, don't use it. Uninstall PA and make a breath of fresh air

Sometimes it's easier to start without something to begin with, than it is to remove it...particularly when everything has been configured and expects that thing to exist (as is the case with a lot of distros, for various included software).

That said, I take the middle ground and use Arch.

[jaxxed]

Besides that i heavily use the network streaming features. Isn't it great to use your 5.1 sound system over the network with the notebook with only ery littly basic extra configuration?

Doesn't the network traffic cause problems for you? I found that if I connect 2 devices over a standard WIFI router, and pass PA audio from one to the other, then the audio gets choppy. It used to be that PA over the network supported no compression algorithms, and the uncompressed audio stream could cause audio stutters.

If they got compression into the network stream, then I would be ecstatic, and would consider going back to using an RPi to connect to my sound system again.

[magika]

Sometimes it's easier to start without something to begin with, than it is to remove it...particularly when everything has been configured and expects that thing to exist (as is the case with a lot of distros, for various included software).

That said, I take the middle ground and use Arch.

I think the only things with hard dependencies on PA I saw are gnome-settings-center (no wonder, considering that someone is retarded) and Guitar Pro (simply bad coding for bad port).
Rest of apps works just fine with ALSA.

[curaga]

I think the only things with hard dependencies on PA I saw are gnome-settings-center (no wonder, considering that someone is retarded) and Guitar Pro (simply bad coding for bad port).
Rest of apps works just fine with ALSA.

You need a source-based distro to be able to fully remove PA.

[magika]

You need a source-based distro to be able to fully remove PA.

Why is that?
Most of the stuff is compiled with libpulse, right, but things are cool as long as I dont install or run PA daemon.

[curaga]

Because it is not "fully removed" if a part of it is still on your system? It's just wasting space, both the library itself and code using it in apps, as well as cycles as apps try to open it on startup.

[rabcor]

I saw in Audacity that my card is hw:0,2 so I tried that and while the error message is no more and ffmpeg records the video, it has no sound. And I can?t record with audacity either, I can only record "Front Mic", "Rear Mic" or "Line".

Well, just to be certain, you should run speaker-test -c 2 -D hw:0,2 -t wav (higher channel count if you've got more channels) if it plays back the sound from your speakers, then it's definitely right, if it doesn't, then you need to find a different value that does. But if it does work, then I guess you'd need to go another route to record your sound (like making alsa output sound to your speakers and a loopback which ffmpeg/audacity could then receord)

[magika]

Because it is not "fully removed" if a part of it is still on your system? It's just wasting space, both the library itself and code using it in apps, as well as cycles as apps try to open it on startup.

I can live with this because:
a) rebuilding stuff on a rolling release distro is more effort than having small shared library in memory
b) binary only things like Chrome or Steam games are still linked to it, so its still will be in my system

They sure probably query some stuff on launch and nothing else so detrimental effect on perfomance is nonexistent,

[Sundance]

What is so bad about dmix (compared to pulseaudio)?

dmix is an ALSA feature that lets you create a virtual peripheral where several sources can output sound simultaneously. dmix mixes these sources and outputs the result to the actual physical device.

There are two problems with that, and both follow from the fact the actual physical device is opened once, with middle-of-the-road buffering parameters. These parameters are, typically, the number of buffers in the ring, and their size. There has got to be at least two buffers so the device can play from one while the driver fills the other.

Because the device fires an interrupt whenever it reaches the end of a buffer, these parameters condition CPU usage and thus the power efficiency of the audio output.

And because these parameters also condition how long it will take for the device to reach a particular buffer after you've filled it, it also conditions the latency of the audio output.

Because these parameters are chosen once when the physical device is opened and will therefore be the same for every source, you end up with more latency than some of those sources need and more overall power consumption than the others require. (jackd's approach is to monopolize the device and open it with buffers as small as needed to meet the latency requirement its been configured with; as a result it also raises power consumption significantly, but that's not an issue for a DAW that will remain plugged in anyway.)

This is an old problem in audio implementations, and as with many media-related issues, it was solved by Apple first. As part of developing Core Audio, they invented a system called timer-based scheduling, where the drivers forego interrupts, the audio API manages all the buffers on its own, and uses separate timers for each source to poll them independently for incoming data with a frequency based on how much latency each source finds acceptable. This allows Core Audio to use as little power as needed while meeting each source's latency requirement. Microsoft followed suit several years later, at some point around Windows Vista IIRC.

On Linux, timer-based scheduling is exactly what PulseAudio does. That's really its main selling point. (That's also why software that accesses PulseAudio directly instead of indirectly through the ALSA emulation layer tends to work better, because then it can specify its latency requirements explicitly.)

The picture is not all rosy: a number of ALSA drivers don't behave well if you try to use them using timer-based scheduling. I understand they are coded in such a way that you can't easily forego their interrupt-based behavior. If you have one such device, you need to tell PulseAudio to NOT use timer-based scheduling, or the audio will likely be buggy/choppy. I believe that's one of the reasons why PA works great for some and not so great for others.

The above is all from memory, I may have gotten some details wrong. Do your own research! It's a fascinating field.

Doesn't the network traffic cause problems for you? I found that if I connect 2 devices over a standard WIFI router, and pass PA audio from one to the other, then the audio gets choppy.

I found this happens when the WiFi devices disconnect for a fraction of a second to scan for BSSIDs. They do that periodically in case you're moving around and need to connect to a different AP from the same SSID group. When I set the BSSID statically on both computers involved in the stream, the stuttering disappeared.