Linux Audio Is Being Further Modernized With The 4.1 Kernel

[Ancurio]

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.

Is this an innate hardware limitation, or are the drivers just coded too simplistically? Ie., are those drivers fixable?

[AJSB]

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

I'm not confusing anything...*complete* removal of PA is not that easy....when doing a "regular Uninstall of PA" actually that let behind lot's of PA related stuff that continues to show it's ugly head...if you try *fully* remove everything that is related to PA you take the risk of end up with a broken system...been there, done that.

Always better use a distro that doesn't use PA if you don't want it. period.

In a ideal world, distros that use PA should had an alternative set of packages that won't use it and during installation should ask if user/admin wanted install the distro version with PA or without it and then proceed with installation of correct set of packages .

...but we don't live in a ideal world so i gone to SLACKWARE because i have no patience to every time i install a distro spend so much time to solve all issues of a complete PA removal.

[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.

[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,

[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)

[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.

[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]

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]

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.

[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.