Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

He writes: A rich API provides methods for inspecting and controlling all available objects and their run-time and persistent properties. This makes it possible to replace configuration files with GUI tools. Many desktop environments provide such tools.

That is wrong, if I don't misunderstand it. It does not matter much for the possibility of GUI tools whether they talk to an API or whether they parse and write configuration files. That is stuff you abstract away.

It is of course possible that pulseaudio allows settings to be set that didn't exist before. It's API might be better for that - but that doesn't say you couldn't do the same with writing to configuration files if they had the same capabilities, like targeting a specific application (one of the use cases he mentions below).



There is a difference. Writing to config files doesn’t set properties at runtime.

PulseAudio needs to allow UI tools to set properties with sub-second latency.

And just reparsing the configs every time something is changed would be extremely wasteful.


Why do you need sub-second latency for something you're unlikely to do more than once a year?


Properties like source/sink volume. It's bad UX if the adjustment is performed out-of-sync with the visual (volume slider) and manual (key press) feedback.


Because I change parts of the config via the UI many times a day. In my case, because I have multiple audio cards and need to change several attributes.


That's minuscule compared to how easy it is to parse config files vs to construct and speak to API. The volume slider UX is a better argument. That's the one thing I can think of where faster changes are indeed useful.


It’s not volume sliding, but close to it. Having a button to move a running audio stream from speakers to headphones to network playback on my phone is amazing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: