| |||||||||||||
Interview with Lennart Poettering (LinuxFR.org)Interview with Lennart Poettering (LinuxFR.org)Posted Jul 6, 2011 13:07 UTC (Wed) by trasz (guest, #45786)In reply to: Interview with Lennart Poettering (LinuxFR.org) by helge.bahmann Parent article: Interview with Lennart Poettering (LinuxFR.org)
Doing it in the kernel does not cause any problems, as mentioned earlier. In addition, it's easier for the system administrator - one less thing to configure.
As for the resampling - FreeBSD uses linear interpolation by default; system administrator can easily change it to e.g. SINC interpolation using sysctl(8). Could you describe why would you want to complicate it further? Since, you know, adding useless features and configuration options just because you can is one of the reasons Linux never caught on the desktop, imho.
Also - note that I'm only talking about ALSA, not the "ALSA/PA" combination; you might want to compare the latter to "OSS/PA", though.
(Log in to post comments)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 14:27 UTC (Wed) by alan (subscriber, #4018) [Link]
about the 'one less thing to configure' part. ALSA/PA works very well out of the box. It works flawlessly with my bluetooth headset, picks up the mic and all. Not much configuration needed, beyond pairing my headset.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:01 UTC (Wed) by bronson (subscriber, #4806) [Link]
Are you able to use the controls on the headphones? No matter what obsolete bluez guide I follow, mine seem to be ignored.
For me, bluetooth audio starts stuttering every few hours. killall -9 pulseaudio fixes it. Other than that, yes, PA makes bluetooth easy. That's no small feat!
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:22 UTC (Wed) by drag (subscriber, #31333) [Link]
The controls work passably well on my headphones. At least last time I checked.
One of my favorite capabilities with PA is the ability to migrate and hotplug audio.
I have USB headset (the USB audio is actually separate from the headphones, which is handy), Bluetooth headset, and onboard audio card. It's great to be able to just plug in my headphones and have it 'just work'. Also migrating audio from one device to another is fantastic.
For desktop audio Alsa/PA blows OSS out of the water. No question about it. Despite some of the ugliness.
As long as OSS exposes the timing information from the audio card back out to the applications then I don't see why OSS/PA wouldn't be any worse. Just as long as FreeBSD/Solaris/whatever has the ability to intercept applications trying to use OSS and pipe it back through PA transparently.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 14:34 UTC (Wed) by bronson (subscriber, #4806) [Link]
> Doing it in the kernel does not cause any problems
I guess you don't count poor CPU accounting and inability to configure it (especially latency) as problems? SYNC should be good enough for everybody?
Linux is starting to make a dent in the professional audio world precisely because of these "useless configuration options."
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:44 UTC (Wed) by jrigg (subscriber, #30848) [Link]
> Linux is starting to make a dent in the professional audio world precisely because of these "useless configuration options."
Exactly. I've been using Linux for pro audio work for the last six years, thanks to the configuration options provided by ALSA. Desktop and pro audio requirements are mutually exclusive in many respects. In order to cater to both sets of users a certain amount of configurability is necessary.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:28 UTC (Wed) by trasz (guest, #45786) [Link]
FreeBSD OSS allows one to configure audio latencies. I have no idea what "poor CPU accounting" you're talking about. Are you sure you're not extrapolating problems specific to one implementation onto others?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 20:09 UTC (Wed) by cmccabe (guest, #60281) [Link]
> Linux is starting to make a dent in the professional audio world
> precisely because of these "useless configuration options."
I thought JACK was the reason why Linux was useful in the professional audio world? JACK doesn't seem to be tied to ALSA, since it has OSS, CoreAudio, and other backends in addition to its ALSA backend.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 21:32 UTC (Wed) by jrigg (subscriber, #30848) [Link]
JACK is an important reason but not the only one. ALSA allows multiple interface cards to be treated as a single multi-channel device (using pcm_multi) for example. JACK will only handle one input device and one output device at a time.
OSS might be able to combine multiple interfaces too, but last time I checked it was too limited in other ways to use with my interface hardware (eg. only 48kHz supported on RME MADI cards, no driver available at all for the PCIe version). OSS seems to lag behind ALSA in support for pro level hardware, in my experience.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:32 UTC (Wed) by drag (subscriber, #31333) [Link]
>JACK will only handle one input device and one output device at a time.
No, I don't think that is true at all. I haven't used Jack in a while, but it seems with it's routing capabilities and qjackctl (to enable easy access to those capabilities) it should have no problem at all handling multiple devices.
In a system with using multiple devices at the same time it may become problematic to try to get low latency and multiple simultanous output working with correct timing. Probably need some mechanism to keep the clocks on your sound cards in sync and such things.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:45 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Yes, pro-hardware is capable of using an external clock. So you pick one reference clock and all your gear keeps time with that.
Most consumer hardware does not offer this capability, you will need to investigate nasty hacks if you want to try to strap three cheap PCI soundcards together as an alternative to buying one six channel pro card.
JACK Posted Jul 6, 2011 22:53 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Oh, I forgot to address the actual point you made. No, JACK only works with one device.
If you have several physical devices which are genuinely sync'd you can just use ALSA to weave them together. If they aren't synchronised bad stuff may happen.
The reason for working with one device is that JACK's graph execution goes like this:
1. Interrupt from hardware indicates that, say, 128 frames are ready
If JACK was willing to work with more than one device, which interrupt does it wait for? What does it do with parts of the graph which require data from more than one input device? Or send data to more than one output device?
Lots of complexity, for a corner case no professional audio people care about (they either have only one device, or their devices can be clock-locked and woven into a single virtual device) and no consumers have the gear to test.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 19:32 UTC (Thu) by jrigg (subscriber, #30848) [Link]
I was referring specifically to combining several interfaces of the same type into a single virtual device, eg. using three 8-channel interfaces as a single 24-channel device, or a couple of 64-channel MADI interfaces as a single 128-channel device.
JACK has no trouble working with multiple devices as long as you only want to use one at a time. It can use different devices for capture and playback, but it can't combine several hardware devices into a single virtual device as I described above. That's what the pcm_multi plugin in ALSA is for (and as you mentioned, hardware clock sync is required).
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:17 UTC (Wed) by rsidd (subscriber, #2582) [Link]
You know, FreeBSD has many things going for it, but desktop and multimedia applications aren't among them. Last I checked (I believe it was FreeBSD 7 or 8-CURRENT), you could panic it just by jiggling the USB audio cable inadvertently. In fact you could panic it with pretty much any USB device. I have heard that these panics have been fixed, but haven't checked. If not, it rules out FreeBSD for any serious use: on-board audio is in general not good enough for professional use.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:08 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
The documentation linked from FreeBSD's own site makes no mention of having fixed this, it's simply listed as a bug in the manual page for the USB audio driver that there is no way to properly handle this case and a panic results.
Perhaps just the documentation snd_uaudio(4) is out of date.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 5:24 UTC (Thu) by rsidd (subscriber, #2582) [Link]
Indeed, now that I think of it, what was claimed to be fixed was the panic when yanking USB mass storage devices. The uaudio problem may well still be around.
The USB flakiness is the reason I stopped using FreeBSD, a few years ago.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 16, 2011 4:58 UTC (Sat) by x0ra (guest, #76826) [Link]
There is still (as of FreeBSD 8.2) all kind of mess with uaudio(4) and the USB stack, under some condition, you can stall the entire stack (very handy when all input are going though USB), which oblige you to reset the machine...
From my pov, the biggest show stopper in FreeBSD is how binary ports are managed (whenever they are).
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 15:57 UTC (Wed) by Karellen (subscriber, #67644) [Link]
"FreeBSD uses linear interpolation by default; system administrator can easily change it to e.g. SINC interpolation using sysctl(8). Could you describe why would you want to complicate it further? Since, you know, adding useless features and configuration options just because you can is one of the reasons Linux never caught on the desktop, imho."
Ah - so *that's* why FreeBSD is so much more popular on the desktop!
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:30 UTC (Wed) by trasz (guest, #45786) [Link]
It doesn't work in that direction, I'm afraid. :-)
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 16:30 UTC (Wed) by helge.bahmann (subscriber, #56804) [Link]
> Doing it in the kernel does not cause any problems, as mentioned earlier. In addition, it's easier for the system administrator - one less thing to configure
If the system administrator has to turn a sysctl knob to choose an interpolation strategy, then that's one more thing to configure, see below.
> As for the resampling - FreeBSD uses linear interpolation by default; system administrator can easily change it to e.g. SINC interpolation using sysctl(8). Could you describe why would you want to complicate it further?
sinc filter with which cut-off characteristic exactly?
Depending on the latency requirements you may want a longer or shorter filter. You want a different filter when e.g. going from 32kHz to 44.1kHz than from 32kHz to 48kHz (you can afford more aliasing in the inaudible spectrum).
Do you think moving on-demand filter construction into the kernel is a good idea?
Since latency requirement is something only the application can specify, you want to choose on a per-application basis, and this partially makes it a policy decision (laptop running on battery with lousy internal speakers -> use cheapest method). How do you manage this policy in the kernel?
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 17:19 UTC (Wed) by alankila (subscriber, #47141) [Link]
As an aside:
It's said that for FIR filters, you can select control of phase, frequency response or latency, but not all simultaneously. Typically, SINC kernels are arranged with the best possible frequency response and linear phase characteristics. However, it's possible to give up on the linear phase property to reduce latency.
Normally SINC is a symmetric filter with mirrored halves around its midpoint, and the large values of the kernel occur at the midpoint. Therefore, at 256 taps it causes a delay of about 128 samples, with about 128 samples of ringing around the midpoint of the action of the filter kernel.
A minimum-phase reconstruction of the same filter can probably reduce the latency to just a few dozen taps, because the large values of the sinc kernel are arranged to happen as early as possible in the filter. The ringing, then, takes the rest of the kernel and has somewhat larger amplitude.
I don't think the human ear is sensitive to phase at all, especially at the highest frequencies, so I'd love if more people at least considered minimum phase filters.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 8, 2011 0:52 UTC (Fri) by HenrikH (guest, #31152) [Link]
>I don't think the human ear is sensitive to phase at all
I might be reading you wrong, but the human ear is very sensitive to phase. For example phase is how the old Dolby Surround provided more channels than speakers.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 11, 2011 10:05 UTC (Mon) by alankila (subscriber, #47141) [Link]
Yes, that's not what I meant. Phase is important when it comes to coherence of several channels, but if you process all channels with a similar transformation, people aren't usually able to notice.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 18:46 UTC (Wed) by trasz (guest, #45786) [Link]
As I said - under what circumstances would that matter? Keep in mind that we're talking about the part of the kernel that allows for several processes to use the audio device at the same time, assuming lack of userland framework such as PA, not about proffessional audio recording. In other words, it's the infrastructure that allows a process go "ping" while some other plays music, not to master a record.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 6, 2011 22:57 UTC (Wed) by nix (subscriber, #2304) [Link]
Your claim that nobody will ever use FreeBSD's audio infrastructure for professional audio recording may be correct. It is definitely incorrect with respect to Linux. People *do* use it for professional audio work, they *do* care about these things, and they *do* care about minimization of latency. Wishing that it were otherwise, and that everyone was like you and not an audio geek, will not make audio geeks go away.
Interview with Lennart Poettering (LinuxFR.org) Posted Jul 7, 2011 7:06 UTC (Thu) by helge.bahmann (subscriber, #56804) [Link]
> As I said - under what circumstances would that matter?
It matters because it means that you need at least two different audio APIs: "bare" OSS hardwired to talking directly to the kernel representation of the audio hardware, and something with a higher-level abstraction that allows to pass through a sophisticated user-space processing framework.
ALSA gives you an interface that behind your back can do both: talk to bare-metal hardware (if for some reason you want to), or have it transparently rerouted through PA. This means that ALSA provides a useful abstraction, while OSS does not at all. (Compare to e.g. OpenGL direct/indirect rendering, its hardware abstraction and what you gain over using libdrm directly).
|
|||||||||||||