17.02.2015 17:29, David Henningsson wrote: > Changes since v1: > - Fix according to Alexander's comments > - A new patch has been added that removes dead code imported from Chrome OS. > For easier reviewing, I will also send a total of the first three patches. > > Also note that the current routing logic are not optimal, e g, > when on 2.1 speakers, plug headphones in, then unplug headphones again, the > result might be that the stereo profile is selected instead of the expected 2.1 > profile. This is not an error with this patch set but might limit its usefulness. I think that it is convenient to write general thoughts inspired by but not directly related to this patch set by replying to PATCH 0/7, so here they are. There is one more usability limitation that comes to mind, and it is also not new. Namely, there can exist a volume balance issue. For a smooth crossover, there must exist a region on the frequency response curves of both satellites and the subwoofer where these curves both are flat and match each other. In other words, overlap, overprint each other, have exactly the same sensitivity not only at one frequency but in a finite range. In the middle of this region, one places the cross-over frequency. Unless it is specifically built to match, the subwoofer will have a different sensitivity than a satellite. That's also why hi-fi subwoofers (which can be used with different models of satellite hi-fi speakers) have a hardware knob or a switch that changes their sensitivity. And I cannot be sure either that a typical laptop subwoofer matches its satellites perfectly out of the box (in other words, in laptops, I intuitively expect "imbalance between subwoofer and satellites" to happen more frequently than "imbalance between left and right speakers") - and laptop subwoofers don't have such switch to compensate. It would be interesting to see the actual frequency response of a laptop with a subwoofer measured under both Linux and Windows. I will send the scripts to David when they are ready - hopefully on weekends. In PulseAudio, a user can work around this hardware mismatch, if it exists, by adjusting the LFE channel volume separately in pavucontrol after unlocking the sliders. But what happens when the user then adjusts the volume using the systray applet? In MATE, the applet does preserve the balance unless turned completely down or completely up. In KDE, the mixer tray applet behaves the same, but, if one clicks the tray icon, then the "Mixer" button in the plasma popup, and adjusts the volume in that window, this will reset all channels to the same level. If one uses pavucontrol, then again, there is no easy way to adjust the overall volume while preserving the deliberately-created difference between the channels. In other words, because balance is kept together with volume (as a multi-channel volume), it is prone to being reset by dumb tools. More of such dumb tools will surely be created in the future, as well-balanced headphones or desktop speakers represent the primary use case. So - given this kind of fiasco, maybe it was a bad idea to export multi-channel volume on sinks and sources, after all? Maybe it is a good idea to think again how to configure and store various settings that primarily compensate for hardware deficiency, are set once and must be preserved? And I mean not only balance, but, in multichannel setups, per-channel delays (of the order of a few milliseconds) which are also important but currently missing. And ideally, when someone implements this properly, per-device equalizer settings and/or an impulse response for digital room correction. -- Alexander E. Patrakov
