[pulseaudio-discuss] Stepping down; future thoughts

[David Henningsson]

On 2016-03-29 01:31, Ahmed S. Darwish wrote:
> Hi David :-)
>
> On Mon, Mar 28, 2016 at 06:36:30AM +0200, David Henningsson wrote:
>> I've decided to stop working for Canonical, and with that, I intend to ramp
>> down my contributions to PulseAudio, on both upstream and Ubuntu levels.
>>
>
> As a user, I send my gratitude for all of your work for a better
> Linux audio. And as a recent contributor, _big_ _thanks_ for your
> very solid reviews and IRC discussions .. I've definitely learned
> a lot (summary: "keep it simple")

Thanks! You've been very receptive to feedback, and I'd encourage you to 
continue contributing to PulseAudio!

>> I could have stayed as a volunteer, but in fact I've been a bit frustrated
>> over some of PulseAudio's design choices for quite some time. Maybe some of
>> those choices were right at the time when they were made, but they make us a
>> not good enough fit for tomorrow.
>>
>>  From one end comes the embedded ASoC drivers, who have never heard of
>> timer-based scheduling, but can reconfigure themselves to decode mp3 in
>> hardware.
>>
>>  From the other end come sandboxed apps, and the security requirements that
>> come with it.
>>
>
> Memfds + per-client global mempool + policy + protections against
> malicious clients + a fuzzer, and we should then be OK - right? :)

Indeed your memfds work is a step in that direction, but as you say, 
lots of steps remain - e g the part that makes sure clients cannot mute, 
or introspect, other clients, maybe that falls under "policy"?

>> And routing - we tried, but we never got that right. It's been difficult,
>> not only due to all use cases and different demands and ideas from different
>> groups of people, but also due to the way PulseAudio is built up internally.
>>
>> In software nothing is impossible, but to re-architecture PulseAudio to
>> support all of these requirements in a good way (rather than to "build
>> another layer on top", which in the long run would make the PulseAudio even
>> more difficult to maintain) would be very difficult, so my judgment is that
>> it would be easier to write something new from scratch.
>>
>
> Would the Linux userspace be ready for yet another audio API?

It is not fair to ask for thousands of applications to rewrite their 
audio backend just because someone invented another API. Certainly one 
has to write some kind of compatibility APIs; exactly how to do this for 
PulseAudio I'm not certain yet.

That would actually be an interesting discussion to have, suppose 
someone writes a new audio server and wants to provide compatibility for 
existing PulseAudio applications; what approach does upstream PulseAudio 
recommend?

(Side note: This has already happened - roaraudio does this, using 
LD_LIBRARY_PATH hacks to inject a new libpulse. It's the only app I know 
of that tries to provide PulseAudio application compatibility.)

// David