| |||||||||||||
Interview with Lennart Poettering (LinuxFR.org)Interview with Lennart Poettering (LinuxFR.org)Posted Jul 6, 2011 16:30 UTC (Wed) by helge.bahmann (subscriber, #56804)In reply to: Interview with Lennart Poettering (LinuxFR.org) by trasz 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
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?
(Log in to post comments)
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).
|
|||||||||||||