4 ms·

I use headphones, and have tactile transducers on my chair. The transducers make the audio sound much louder than it actually is. That is good for your ears and

by madez 9y ago

I use headphones, and have tactile transducers on my chair. The transducers make the audio sound much louder than it actually is. That is good for your ears and your neighbours. Because of this setup I need full-range stereo output on my headphones and low-passed LFE for the transducers. How can I do this PulseAudio? When I enable lfe-remixing, I get full-range output on my transducers and I hear voices in my chair. If I set lfe-crossover-freq, I lose the bass on my headphones. I found this patch https://pw-emeril.freedesktop.org/patch/171424/ https://pw-emeril.freedesktop.org/patch/171424/ which seems solve the problem, but it was rejected.

madez 9y ago
I'd like to add that the patch was rejected because the maintainer had a use-case in mind, deemed the feature not a good solution, and therefore rejected the patch. I would comment directly on the site, but because the certificate is invalid, I cannot register an account. I don't like the attitude to reject a patch just because one can't come up with a use-case. Obviously there is a use-case, else the patch wouldn't have been developed. Also, the feature would be hidden in a configuration file that is meant for advanced configuration anyways. On top of that, I have a AV-receiver that does support all of this bass management. For every channel I can configure individual crossover frequencies, and I can but don't need to use a subwoofer. Why doesn't PulseAudio give me these freedoms? Why would a free software developer deny others easy ways, or any ways at all, to configure their system? This is equivalent to the walled-garden approach of many closed systems. Why does this occur in free software?
- daenney 9y ago
  Every single feature someone accepts into a code-base comes at a cost. That feature needs to be reviewed, tested and above all maintained and deal with any possible bugs that might arise from it. Especially open source developers only have limited amounts of time to spend on something. Investing time in this feature means not being able to invest time in something else. Accepting a feature that a few people might use, hidden away somewhere in the advanced configurations, might very well not be worth the trade-off to them, even though you personally find the feature valuable. It has nothing to do with a walled garden. Ultimately, if this is so important to you, you have the choice to fork and maintain it yourself and carry that cost. That'll most likely be a lot of work, especially if you want to keep in sync with upstream. But it might give you a better understanding of and appreciation for the tremendous amount of work and effort that goes into projects like these. Work that goes largely unpaid.
- awalton 9y ago
  > Why would a free software developer deny others easy ways, or any ways at all, to configure their system? Because of the "drive-by contributor" problem. Come by, drop off a patch that solves exactly your problem, never show up again to maintain the feature, even if it breaks, even if it's been broken for years. That forces me, the developer, to either continuously test your patch (which I may not be able to do if I don't have your hardware/software/configuration/use-case-in-mind), or to shrug and hope it works. We have to just trust your initial work and have it no way weigh in on the future of our product? We've learned too much as Open Source Software Engineers to just trust random drive-by contributions. We've gone from default-accept-all to default-deny, because at the end of the day that's what keeps quality in our software.

by madez 9y ago

madez 9y ago

I'd like to add that the patch was rejected because the maintainer had a use-case in mind, deemed the feature not a good solution, and therefore rejected the patch. I would comment directly on the site, but because the certificate is invalid, I cannot register an account. I don't like the attitude to reject a patch just because one can't come up with a use-case. Obviously there is a use-case, else the patch wouldn't have been developed. Also, the feature would be hidden in a configuration file that is meant for advanced configuration anyways. On top of that, I have a AV-receiver that does support all of this bass management. For every channel I can configure individual crossover frequencies, and I can but don't need to use a subwoofer. Why doesn't PulseAudio give me these freedoms? Why would a free software developer deny others easy ways, or any ways at all, to configure their system? This is equivalent to the walled-garden approach of many closed systems. Why does this occur in free software?

daenney 9y ago
Every single feature someone accepts into a code-base comes at a cost. That feature needs to be reviewed, tested and above all maintained and deal with any possible bugs that might arise from it. Especially open source developers only have limited amounts of time to spend on something. Investing time in this feature means not being able to invest time in something else. Accepting a feature that a few people might use, hidden away somewhere in the advanced configurations, might very well not be worth the trade-off to them, even though you personally find the feature valuable. It has nothing to do with a walled garden. Ultimately, if this is so important to you, you have the choice to fork and maintain it yourself and carry that cost. That'll most likely be a lot of work, especially if you want to keep in sync with upstream. But it might give you a better understanding of and appreciation for the tremendous amount of work and effort that goes into projects like these. Work that goes largely unpaid.
awalton 9y ago
> Why would a free software developer deny others easy ways, or any ways at all, to configure their system? Because of the "drive-by contributor" problem. Come by, drop off a patch that solves exactly your problem, never show up again to maintain the feature, even if it breaks, even if it's been broken for years. That forces me, the developer, to either continuously test your patch (which I may not be able to do if I don't have your hardware/software/configuration/use-case-in-mind), or to shrug and hope it works. We have to just trust your initial work and have it no way weigh in on the future of our product? We've learned too much as Open Source Software Engineers to just trust random drive-by contributions. We've gone from default-accept-all to default-deny, because at the end of the day that's what keeps quality in our software.