Hi all,

is it just me or has anyone else experienced that the latest released skype for linux starts up fine but then hangs completely: window can be resized but the "skype contents" don't follow, pushing buttons doesn't work and even closing the window is impossible?

I run Ubuntu Hardy Heron Alpha 6 with all the latest updates, the latest kernel etc.

Earlier betas worked fine, video and all. Now I can't even see who's online before it crashes.

Please let me know if further details is required to help debug.

The cause for this is Skype's developers refusing to provide support for PulseAudio in Skype. I don't understand why, but they do it. It's annoying. Really annoying.

Go to Skype preferences and change your sound device to one of the hw or plughw devices. "default" and "pulse" refer to PulseAudio, and since Skype doesn't like cooperating with PulseAudio, it hangs miserably while eating your CPU.

Okay, I'll bite.

Can you tell me why PulseAudio interferes with basic ALSA functionality?

One thing that really gets to me personally, is when a new technology comes along promising to make life easier yet interferes with existing system functionality. I'm sorry, but I've looked into the PulseAudio system. I like it. I like the advantages. But if distribution maintainers and developers insist on installing it in a way where ALSA's own dmix system can no longer be used, then this gets no respect from me -- at the end of the day, it only creates pain for the user, as you're seeing here.

You can't just expect every audio application to drop their pants and jump on to every new audio subsystem (and there have been a LOT in the Linux land) shortly after distributions start using them.

I'm sorry we (as Skype) don't have native PulseAudio support as yet. It may come in the future. But this is no reason Skype shouldn't co-exist with PulseAudio on such a system at present.

Andrew.

Fine, granted, PulseAudio does interfere with dmix's capability. However, PulseAudio has an ALSA plugin which allows native ALSA applications to use PulseAudio instead. Why doesn't Skype support that? Instead it just fails miserably in the presence of _any_ sound daemon. Surely it can't be that hard to implement?

"It may come in the future." How many versions down the road are we talking? This issue has been raised since version 1.3, but only recently distributions have made PulseAudio the default sound system.

If it's so hard to use PulseAudio, how about using some other higher level library for accessing the sound? Maybe SDL, Gstreamer, Xine, or Phonon? All of these have support for PulseAudio among other sound systems.

However, I must thank you for pointing out to me that PulseAudio messes up dmix and broke sound with Skype. It was from that that I managed to find this:
https://bugs.launchpad.net/ubuntu/+source/p...dio/+bug/109439
and finally come up with this within the hour:
http://ubuntuforums.org/showthread.php?p=4526841#post4526841

Andypoo and hyperair, thanks for the information.
Andypoo: I see your point completely, and I have added my support to this bug: https://bugs.launchpad.net/ubuntu/+source/p...dio/+bug/198453

FYI though, Ubuntu Hardy is about to complete and to be the new Long Term Support release of Ubuntu. You risk loads of users with this issue shortly! If there's anything you can do to help enlighten the ubuntu devs on how to support skype (and other ALSA reliant apps) please try to help!

A better question is, why doesn't it work then?

We know that:
a) Skype works with ALSA without PulseAudio.
b) Skype doesn't work with ALSA through PulseAudio.

If Skype works with ALSA without PulseAudio, then surely, PulseAudio's ALSA plugin doesn't work correctly?

I agree that the situation could be more complex, but in any case, if Skype can work natively on the same system, then PulseAudio should respect this and either let it run, or have a plugin system which allows it to run as it did before. Anything else is a regression.

To be honest, I'm not personally responsible for sound engine-related issues, so I'm only taking in this info and passing it on as needed. With regards support for PulseAudio, I don't have a specific time for when this will be released.

Andrew.

PS. Sorry for biting. I realise this is an issue, and I want to get a solution too. In the long-term, PulseAudio support can be useful for some people (I don't deem the problems above to be reason enough to add PulseAudio support). In the short-term, it's not necessary, and Skype should work quite happily without it.

It seems Skype isn't the only affected app. There are others. For example Wine, which only works well through OSS emulation.

As for PulseAudio respecting other ALSA apps and dmix, I've managed to get it to do that by changing some configuration settings. It seems that there were issues with module-hal-detect, causing PulseAudio to grab the hw device.

Just to note - there is an outstanding issue with Skype overriding dmix if you explicitly set a sound device. We recommend sticking with the default device (where possible) for now.

So, if the solution involves creating another device which pipes through with dmix support, there could be problems using such a custom device in Skype currently.

Andy.

Hyperair - if you're able to make this work now, you should post a workaround/fix to the launchpad bug...?

There isn't a specific Launchpad bug to Skype. I just mixed and matched a few guides, managed to get PulseAudio to connect to dmix instead of grabbing the whole sound card.

Getting Skype to work with the custom dmix device didn't bring any complications to me. Also, my default ALSA device is of type pulse, because I'd rather all my ALSA applications connect to PulseAudio instead. In fact, the easiest way to go about this entire workaround is to just make a custom dmixer device in /etc/asound.conf, and making both PulseAudio and Skype use the same custom dmixer device.

Also, this works for other stubborn applications such as Audacity.

It should be noted though, that PulseAudio's module-suspend-idle has a bug when you get PulseAudio to use dmix. Some assertion failure while starting up. If you don't kill PulseAudio once it has managed to start up though, it should be quite stable. But getting it to even start up is a hit or miss for me. The quick fix is of course to not load module-suspend-idle, but on my system, dmix begins crackling if it isn't released after a very long period of time.

Hi there.

I'm not a PulseAudio dev but I'm fairly close to the core of the main development and have recently begun coding on some additional modules for PA. I'm also the packager for PulseAudio in Mandriva linux.

I think I should come along here and try and clear a few things up.

PulseAudio + DMIX

While I don't dispute the fact that this combination is useful for some people to get things working with Skype, it is very important to realise that this is very ugly work around and it is not very surprising it does not work perfectly in practice. DMIX is essentially a build in sound server in ALSA. It is launched automatically but, in principle it is doing the same job as a userspace solution like PulseAudio. It makes no sense to layer one sound server on top of the other. Pulseaudio should really be seen as DMIX on steroids. As more and more distros switch to PA we'll see less and less use of DMIX.

Skype + ALSA
Skype should not program anything specically targeted at DMIX. Skype should be programmed to interface with the ALSA API in a standard way. It is very easy to make mistakes in implementing the ALSA API as it lets you get away with a bunch of mistakes and still play sound. People have mentioned Wine before in this thread. I've looked at the wine ALSA driver and it was terrible. It was doing some really dumb stuff, not even loading the "default" device properly (accessing it as default:0 which really fails when working with something other than dmix or hardware). It's getting better now because people who care about this are working on it. It's very easy to write ALSA clients with the assumption that the device is a hw device. It should really be written/tested against e.g. an IOPLUG "device". This would allow things like bluetooth headsets and pulseaudio to work without any modification or specific support. While there have been bugs in the ALSA plugin for pulse, it's also highlighted a lot of slightly buggy implementations of ALSA clients. It has also thrown up a couple of limitations int he IOPLUG structure that will probably be addressed in the not too distant future. Some of these improvements may make Skype "just work" but who knows?

Unfortunately as Skype is closed, we cannot scrutinise the ALSA implementation to see if it is at fault in this regard or if there is indeed some problem with the pulse plugin for ALSA. I'm sure it wouldn't take long for someone who fully appreciates the ALSA API to look at that bit of the code and work out what needs to be fixed, but ALSA, that is not possible. Earlier statements on this thread: "installing it in a way where ALSA's own dmix system can no longer be used" seems to make the assertion that DMIX was being specifically targetted with Skype. This makes the assumption that the user wants to use DMIX, which is not the correct approach to writing an ALSA client. I really do hope it is appreciated that DMIX is not necessarily available. Nor is real audio hardware necessarily available. As explained previously PulseAudio should be thought of as an upgrade to DMIX with a different API. Therefore specifically tailoring to the old "mixing" API is not a good approach.



In an ideal world Skype would be modified to use a third party library for sound access but licensing restraints mean that many good libraries cannot be used. SDL is an option (LGPL) but it's pulse implementation is somewhat simple and does not feed back latency issues that would be important for Skype to support e.g. good lipsync in video. For this reason I think SDL should not be adopted.

A solid ALSA implementation in Skype would address most issues for most users but a pluggable sound API for Skype would be best - allowing a good plugin to directly support pulse to be produced, complete with latency feedback. Perhaps you could abstract out the current Alsa implementation via a simple API and open source that part? I'd doubt that this particular bit of code contains any IP sensitive information and doing this relatively simple (I would hope) refactoring would allow progress in this area to push ahead without requiring direct resources of Skype staff.

I doubt this will happen but you don't ask and you don't get!

Please forgive my changing case of ALSA, alsa, pulse, PulseAudio etc. etc.

@coling: Thanks for posting. I understand it was an ugly workaround, but that's the only way to get it working so far. I'd like to ask why module-suspend-idle and dmix clash so badly as to produce an assertion error consistently?

Disregarding the philosophical debate on ALSA vs PulseAudio and whose responsibility it is to fix what: Ubuntu Hardy Heron is about to be released. It's a Long Term Release (meaning it is intended to be installed and supported for ~ 3 years from Canonical's side). Conservatively estimating, in 10 days there are hundreds of thousands of users getting the option to do a one-click upgrade, of whom more than 91 THOUSAND have skype installed according to popcon.ubuntu.com. Mandriva and Fedora are all similarly switching to PulseAudio.

Dare I be the crazy adult in the room and suggest skype developers reach out to the PulseAudio devs and/or ubuntu/mandriva/fedora devs and help debug this issue before we all have have a cast of thousands on our hands, whining about regressions...? Or perhaps at least put a "pinned" note on top of the Skype for Linux forums to warn people of the problems?

References:
10 days and counting down quickly: https://wiki.ubuntu.com/HardyReleaseSchedule
the team: https://launchpad.net/~ubuntu-audio/+members
http://wiki.mandriva.com/en/2008.1_Errata#No_sound_in_Skype

Associated bug reports:
https://bugs.launchpad.net/ubuntu/+source/p...dio/+bug/198453
https://developer.skype.com/jira/browse/SCL-271

The simple answer is that they just. don't. care. After a tonne of requests to do this that they refuse to entertain, I don't see any reason to convince me otherwise. Instead they just hide behind the excuse that PulseAudio broke ALSA. It's true that PulseAudio's ALSA plugin implementation isn't perfect, but that's because libasound permits some non-standard behaviour, which evidently Skype uses.

To address some key points:

1. We will likely add PulseAudio support in the future.
2. We've never 'not cared'.
3. We are in contact with distribution maintainers throughout the development process.

Andrew.

Andrew,

It's reassuring to know that Skype developers are working on this - the functionality is, as far as I am concerned, long overdue. I changed to PulseAudio well over a year ago - which was when I stopped using Skype for anything other than an IM service. And the main reason I changed was that my machine generally has multiple sound sources active at any one time. I think it is fair to say that most desktop users are the same. I want to listen to a CD while I work - but it would be nice if Skype could come in on top to let me know of an incomming call. At the moment, it can't - and non-stop audio, with message alerts from other IM clients, take precedence over any single application.

What I'm not so impressed by is the apparent squabbling between the two camps. Your automatic assumption that "Skype works with ALSA, and doesn't with PulseAudio, therefore PulseAudio is broken" at the top of this thread is not very helpful. As Skype is closed source, can you not say PRECISELY what is wrong, and how PulseAudio could be fixed? Even better, offer a patch to fix it?

As Skype supports ALSA, surely it can't be too complicated to do a bit of bug-squashing? Or must we wait for native PulseAudio support?

Sorry if my behaviour was seen as igniting a flamewar, as that really wasn't my intent. And some of my posts were out of frustration.

With regards "And the main reason I changed was that my machine generally has multiple sound sources active at any one time. I think it is fair to say that most desktop users are the same.", ALSA offers this already. It's called dmix. And it's a feature Skype uses rather heavily.

It became standard in ALSA in 1.0.11, which is why Skype's ALSA requirement is set around this time. Skype can work quite well with playing system sounds at the same time whilst in the middle of Skype call. You can even call to yourself on the same machine (if you're really bored) and have dual-way recording and playback thanks to ALSA's dmix and dsnoop.

I'm not going to dwell on the specifics of the issue anymore, as it has been covered by those interested involved and we're working on it. But suffice to say, PulseAudio provides an alternate implementation to ALSA's native dmix feature, however to achieve predictable behaviour (for PulseAudio applications) they had to bypass dmix in ALSA. This meant that programs like Skype stopped working so well.

I don't think anybody specifically is at fault with this system, but it does mean that Skype requires dmix. PulseAudio (by its default configuration in most systems) disables dmix. So if we want Skype to work on PulseAudio systems properly with multiple applications using the audio device, we need native PulseAudio support in Skype.

So my apologies again for any squabbling that I began between Skype vs PulseAudio or any such debate. My comments were my own as a frustrated Linux/Skype user and don't reflect any company policy or direction.

Andrew.

@Andypoo: Thank you for the very good ALSA Support and the very good Skype client for Linux.

I am your opinion.

Additional:
We don't know how PulseAudio itself evolves.
Spend much energy into this is maybe an aberration...

@Andypoo

Just thought I'd quickly address one thing you said in your post:



dmix is offered by alsa as a 'virtual' sound card.

pulseaudio on the other hand runs as a daemon that programs can connect to and then pulseaudio sends the sound to alsa/etc on that program's behalf.

One thing it appears you do not realise though is that pulseaudio *also* provides a 'virtual sound card' for alsa - just like dmix. This means that alsa applications can send their audio to alsa, and alsa will then send the audio to pulseaudio, which will then mix and send the audio back to alsa and play through the hardware device.

The issue that a lot of people here are complaining about, is that an application should not rely on dmix. It should just pretend that it is talking to a sound card and let the mixing magic happen on the other end. If an application is written correctly, and the pulseaudio alsa 'sound card' is written correctly, then there should be no hassle with that application sending audio to pulseaudio (via alsa) *without* that application having pulseaudio support.

Pulseaudio support in Skype would be GREAT! But! We don't need it. We just need skype to support alsa correctly. If it used alsa correctly, then we could all just set our default alsa devices to use the pulseaudio plugin and skype would fit in with the rest of the desktop.

Thanks for the software btw!

Daniel

Halo,

I'm kind of new to Ubuntu and Linux in general, but i found the following thread and reply to the problem by hyperair. What do you think?

http://ubuntuforums.org/showthread.php?p=4526841#post4526841

Regards,
Levent04

Hi @all,

at first i want to thank the skype developers (@andypoo for instance, and of course all the other ones...) for their magnificent application. And the did a very good job, as far as i am concerned.
In my case i am also currently only use the chat functionality of skype. Because i am part of that 91 thousand (unbelievable...) Ubuntu users. But i bugs me alot since a few weeks because i really like the video and voice chat ability. At work i use it all the time for business.
The main point is: Too many people will use PulseAudio
A couple of years ago alsa was the only viable option for sound. I agree with that. But most audio players i use dont use dmix in alsa, so hearing music while a skype call comes in, never worked for me.
But at the moment we are having a paradigm shift in the use of sound server. As one the preposts here pointed out: All the latest Ubuntu LTS PLUS Fedora PLUS Mandriva distributions are going to work with PulseAudio now, and in the near future. That is a fact.
So i suppose you will get a lot of grumpy/dissapointed linux users over this. Because for chat i can also have Jabber/GTalk or so. One of the unique things in Skype was the audio conferencing, and i completly fell in love with video conferencing. And these ultimatly cool features will not work in the latest release of the distro of my choice?
When i first heard this, i thought it was a bad joke...

But i am confident that you will fix this error, hopefully soon. Because i really want to have my multi-channel communication back in linux.

Yours faithfully, Mark

Hi everybody,

This is my first post.

Few months ago I bought MacBook Pro and installed Ubuntu (i no more use WinXP or Vista or the likes from MS). I have been struggling to get skype working on it, especially after the arrival of PulseAudio. But i found this - a chance stumbling

https://bugs.launchpad.net/ubuntu/+source/p...dio/+bug/198453

especially the suggestion from one Mr. Roberto Cássio Jr.

$ asoundconf set-pulseaudio

Seems to make the trick. I now no more have to use the OSS Skype (with poor audio quality). Though I am not sure at this time, if I have to enter this command everytime I have to login to my Ubuntu Box.

Hope the same works for you guys. God Luck!

--
Pravin