Well, there are too many partial solutions in the Linux audio world, but the problem is partly finding a solution that fills all the needs on a modern system. I'm not sure about portaudio, whether it is now able to work with JACK (apparently that was problematic). JACK is designed to provide low-latency with apps designed to use JACK but other apps need to use the likes of ALSA loopback devices with JACK and lose any low-latency advantages in doing so. Jack is certainly the musicians choice, it seems, for these apps designed to use it. However, Skype is not a specialised music app; rather it needs designed to work as smoothly and easily as possible on a standard desktop system. JACK webpage compares the two and points to their uses as follows:jamesbond wrote: If they do want to use a "middleware" layer to hide platform-dependence code, then there are many better libraries. They can use portaudio, or use SDL, etc. that does force the end-user to install craptastic crash-prone "audio server". Heck, if they need "low-latency" audio then use JACK, for example. But pulseaudio?
http://jackaudio.org/faq/pulseaudio_and_jack.html
I can myself therefore understand Microsoft choosing to go with PulseAudio. Kind of... :-) I think it is more to do with so many major distributions providing pulseaudio on their default installations though. In that regard, I believe many Linux users (on Ubuntu and Fedora and the like) were reporting problems getting old Skypes to work with their system's pulseaudio setup. The easiest way round that for Skype was to redesign their app to drive pulseaudio rather than direct to alsa, and leave it up to the individual distribution administrators to setup their pulseaudio installations such that they worked properly out of the box (with the underlying alsa). In that case, any complaint should maybe be pointed towards Ubuntu and Fedora and so on, for adopting pulseaudio rather than say JACK (and maybe JACK would have been able to address any shortcomings it has compared to pulseaudio as a desktop audio middlelayer solution). However, things are as they are.PulseAudio and JACK can appear to have similar goals to many people, and they wonder why its not possible to replace one with the other. However, beyond a very superficial similarity, they really do not have much in common:
PulseAudio is focused on desktop and mobile audio needs. It doesn't try to address low latency usage, but does provide seamless device switching, network routing, global per-application volume control and lots more great stuff.
JACK is focused on the needs of pro-audio and music creation users. It offers the lowest possible latency, complete routing flexibility between applications and audio hardware, and all audio is always sample synchronized - apps don't run ahead or behind of others. It doesn't provide the smooth desktop experience that PulseAudio is aiming at.
I certainly agree that the best would be if Skype would leave previous code for direct Alsa use as at least an option, which is particularly useful for systems like Puppy. It worked for most of it, and presumably provided lowest latency (even Jack needs to go through the likes of ALSA) so why throw it away? Maybe we need some sort of 'fake' or dummy pulseaudio layer, which isn't a server per se but just re-routes calls to pulseaudio API through to ALSA somehow? I don't know if that is possible or not.
EDIT: Here is a link to an interesting, albeit somewhat old, article that might to some extent still explain why Skype want to use pulseaudio and not JACK:
http://0pointer.de/blog/projects/when-p ... n-not.html
Note that pulseaudio does include mechanisms for the voip app to request latency settings, though it seems that the latency requested cannot generally be guaranteed:
http://www.freedesktop.org/wiki/Softwar ... cyControl/
In any case, low latency generally means higher power consumption, which is not what mobile devices want, and pulseaudio attempts to provide dynamic configuration, which JACK apparently doesn't and Alsa alone can't.
Cheers,
William