Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Sat, Jun 09, 2012 at 07:00:19PM +0200, Antoine Jacoutot wrote: On Sat, Jun 09, 2012 at 04:00:27PM +0200, Alexandre Ratchov wrote: On Fri, Jun 08, 2012 at 10:39:16AM +0200, Antoine Jacoutot wrote: If you want to try it and have sndio diffs to review, fix, etc... don't hesitate. I'm not against pulse; it's just very low in my todo list. I don't know anyone in the project able to do that but you (and jakemsr but he's gone now). Come on, there are sndio backends written by others as well, the API is simple and it's documented. But that's not the point. It _is_ the point. And I already discussed with you several times privately in the past about how this is exactly the point. One cannot expect to know all the APIs around; when I compile something that requires X libraries I don't need to know much about the X API; if I compile something --with-ssl I don't need to be familiar withe the openssl API (thank god!). With sndio each time an application deals with audio (whether it's big like pulse or a small one), then it needs to be ported over which may not be trivial and requires audio knowledge. Look how long people have been trying to port chromium over to sndio without success... This is true only for very small programs. Making the program build is only part of the work. What if the program doesn't work very well, say audio stutters? You have to fix it, and debugging timing bugs is a nightmare. Experience has shown that it's easier to write sndio backends than to debug timing bugs or deal with subtle differences between API implementations, or subtle timing differences in the behavior. AFAICT, this was explained several times by jakemsr@ who ported a lot of audio programs to OpenBSD. In other words, having $RANDOM_LINUX_API might save porting time only for trivial players, but would make us spend more time on the average audio program. And I understand very well your frustration. I know that you can't just type ./configure make to build linux apps, and this difference seems gratuitous. But it isn't. This is best we could do. And I believe it was the right choice. So far sndio has changed nothing to me as a regular user but has been nothing but pain as a porter. I having nothing per se against it, I'm sure it 's not a nih syndrom and does fullfil some needs for you audio gurus. When you first discussed about adding this new audio API several years ago one of the first thing I asked you guys was to think about some compatibility glue with e.g. OSS to leverage the work for porters. OSS compat glue doesn't work very well. It would help you compile linux programs but you would spend more time if you want programs to work well. And we already have OSS compat glue that has proven that compat glue doesn't help, except for trivial code. While it brings more problems. And I repeatedly talk to you everynow and then about it. I already spends a huge amount of time on ports, for myself, by helping people, by reviewing stuffs, by working on the infrastructure to ease my fellow porters'work... I think I already share a large burden on the ports maintainance; I wish I had 48h days to learn new APIs all the time, but I don't. So what do you prefer? learn the OSS API to be able to debug timing issues stuttering? or learn sndio, which is order of magnitude simpler. And same here, I wish I had 48h days to finish my stuff and help with porting. The point is that you can't ask me to postpone fixing other audio stuff in order to work on software I don't use. Especially after I've told you that I don't think it would work very well. I have never requested that _you_ do this. Sorry, my bad. I misunderstood your point. If you think it would work well enough for you, or just want to try it then write a sndio backend for pulse. I'll be there to help debugging stuff, explaining parts of the API that are not clear, etc. [...] As we're at it, a more general note: we're a small community; we don't have full-time developpers working on fashionable software. Exactly, so why are we forced to be uncompatible with everyone else? Mainly for audio centric technical reasons. To ease porting of audio programs was one of the them. Again by porting I mean make programs work without stuttering, not just build. There are already many places where we defer from the majority of Unices (for good reason, I'm not complaining here) but audio should be something that should just work by respecting some sort of standard. Not official standard, but the pragmatic one, that is the one most people use and expect so be available on a system (OSS? ALSA? SUN?). Technically, OSS and SUN are kernel-based so they prevent us from moving audio stack out of the kernel and moving forward. So they don't do the job. Futhermore they are very error-prone and hard to use for full-duplex programs. Audio is inherently simple and deserves a simple api. ALSA is
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Wed, Jun 13, 2012 at 10:28:41AM +0200, Alexandre Ratchov wrote: I don't want to cover all use cases, I just want to be able to have audio and mixer controls on my desktop, or is that a use case that is too unrealistic? AFAICS, writing/porting a simple mixer GUI to control the volume is less work than porting pulseaudio. That does not cover the issue where softwares use pulse API to trigger events, like change volume and such things. All these applications will need to be rewritten (and these aren't simple, look at what gnome-settings-daemon does) and pushing is upstream would be impossible. -- Antoine
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Fri, Jun 08, 2012 at 10:39:16AM +0200, Antoine Jacoutot wrote: If you want to try it and have sndio diffs to review, fix, etc... don't hesitate. I'm not against pulse; it's just very low in my todo list. I don't know anyone in the project able to do that but you (and jakemsr but he's gone now). Come on, there are sndio backends written by others as well, the API is simple and it's documented. But that's not the point. The point is that you can't ask me to postpone fixing other audio stuff in order to work on software I don't use. Especially after I've told you that I don't think it would work very well. If you think it would work well enough for you, or just want to try it then write a sndio backend for pulse. I'll be there to help debugging stuff, explaining parts of the API that are not clear, etc. [...] As we're at it, a more general note: we're a small community; we don't have full-time developpers working on fashionable software. IMHO, having a small set of quality programs that cover all use-cases is more realistic than supporting everything that exists. Spending a lot of time on tons of programs with duplicate funtionalty won't bring us quality. My 2 cents -- Alexandre
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Sat, Jun 09, 2012 at 04:00:27PM +0200, Alexandre Ratchov wrote: On Fri, Jun 08, 2012 at 10:39:16AM +0200, Antoine Jacoutot wrote: If you want to try it and have sndio diffs to review, fix, etc... don't hesitate. I'm not against pulse; it's just very low in my todo list. I don't know anyone in the project able to do that but you (and jakemsr but he's gone now). Come on, there are sndio backends written by others as well, the API is simple and it's documented. But that's not the point. It _is_ the point. And I already discussed with you several times privately in the past about how this is exactly the point. One cannot expect to know all the APIs around; when I compile something that requires X libraries I don't need to know much about the X API; if I compile something --with-ssl I don't need to be familiar withe the openssl API (thank god!). With sndio each time an application deals with audio (whether it's big like pulse or a small one), then it needs to be ported over which may not be trivial and requires audio knowledge. Look how long people have been trying to port chromium over to sndio without success... So far sndio has changed nothing to me as a regular user but has been nothing but pain as a porter. I having nothing per se against it, I'm sure it 's not a nih syndrom and does fullfil some needs for you audio gurus. When you first discussed about adding this new audio API several years ago one of the first thing I asked you guys was to think about some compatibility glue with e.g. OSS to leverage the work for porters. And I repeatedly talk to you everynow and then about it. I already spends a huge amount of time on ports, for myself, by helping people, by reviewing stuffs, by working on the infrastructure to ease my fellow porters'work... I think I already share a large burden on the ports maintainance; I wish I had 48h days to learn new APIs all the time, but I don't. The point is that you can't ask me to postpone fixing other audio stuff in order to work on software I don't use. Especially after I've told you that I don't think it would work very well. I have never requested that _you_ do this. If you think it would work well enough for you, or just want to try it then write a sndio backend for pulse. I'll be there to help debugging stuff, explaining parts of the API that are not clear, etc. [...] As we're at it, a more general note: we're a small community; we don't have full-time developpers working on fashionable software. Exactly, so why are we forced to be uncompatible with everyone else? There are already many places where we defer from the majority of Unices (for good reason, I'm not complaining here) but audio should be something that should just work by respecting some sort of standard. Not official standard, but the pragmatic one, that is the one most people use and expect so be available on a system (OSS? ALSA? SUN?). IMHO, having a small set of quality programs that cover all use-cases is more realistic than supporting everything that exists. Spending a lot of time on tons of programs with duplicate funtionalty won't bring us quality. I don't want to cover all use cases, I just want to be able to have audio and mixer controls on my desktop, or is that a use case that is too unrealistic? -- Antoine
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Thu, Jun 07, 2012 at 10:00:26PM +0200, Antoine Jacoutot wrote: On Thu, Jun 07, 2012 at 04:07:38PM -0400, Brad Smith wrote: - Original message - On Thu, Jun 07, 2012 at 09:40:52AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 03:32:41PM +0200, Rafael Sadowski wrote: On Thu Jun 07, 2012 at 06:49:37AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 05:30:39AM -0500, Amit Kulkarni wrote: Hi guys, I am building kdelibs, runtime and am hitting the same problem as Rafael. The undefined references to pthread_* functions in kdelibs was easy to fix. Disable building with PulseAudio support. I think it's not the worst idea to disable PulseAudio (-DWITH=PulseAudio:BOOL=OFF). The speaker setup GUI needs pulseaudio. But, does it's really everything OK with our pulseaudio libs? It doesn't matter. You cannot use PulseAudio. Disable it. I use PulseAudio on gnome everyday. There is still no sndio backend.. I use it for the mixer. sndio isn't capable of that. There's a MIDI based mixer API with a master volume knob and a per-application volume knob. There's a small program to control this in the audio/aucatctl port. If you plan to work on a mixer control GUI, I could prepare a very simple example program suitable for copy pasting in GUIs. Let me know if so. -- Alexandre
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Fri, Jun 08, 2012 at 08:53:25AM +0200, Alexandre Ratchov wrote: There's a MIDI based mixer API with a master volume knob and a per-application volume knob. There's a small program to control this in the audio/aucatctl port. If you plan to work on a mixer control GUI, I could prepare a very simple example program suitable for copy pasting in GUIs. Let me know if so. To be honest I'd rather have someone fix pulseaudio to use sndio; all GNOME applications have support for pulse and I'd rather have pulse with sndio rather than rewritting all GNOME apps that touch sound... -- Antoine
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Fri, Jun 08, 2012 at 09:16:13AM +0200, Antoine Jacoutot wrote: On Fri, Jun 08, 2012 at 08:53:25AM +0200, Alexandre Ratchov wrote: There's a MIDI based mixer API with a master volume knob and a per-application volume knob. There's a small program to control this in the audio/aucatctl port. If you plan to work on a mixer control GUI, I could prepare a very simple example program suitable for copy pasting in GUIs. Let me know if so. To be honest I'd rather have someone fix pulseaudio to use sndio; all GNOME applications have support for pulse and I'd rather have pulse with sndio rather than rewritting all GNOME apps that touch sound... This would stack two audio servers and two client libraries; this is unlikely to work very well. -- Alexandre
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Fri, Jun 08, 2012 at 10:03:51AM +0200, Alexandre Ratchov wrote: On Fri, Jun 08, 2012 at 09:16:13AM +0200, Antoine Jacoutot wrote: On Fri, Jun 08, 2012 at 08:53:25AM +0200, Alexandre Ratchov wrote: There's a MIDI based mixer API with a master volume knob and a per-application volume knob. There's a small program to control this in the audio/aucatctl port. If you plan to work on a mixer control GUI, I could prepare a very simple example program suitable for copy pasting in GUIs. Let me know if so. To be honest I'd rather have someone fix pulseaudio to use sndio; all GNOME applications have support for pulse and I'd rather have pulse with sndio rather than rewritting all GNOME apps that touch sound... This would stack two audio servers and two client libraries; this is unlikely to work very well. In this case, I will re-enable OSS in pulseaudio and use that. Also you should remove audio/jack then. -- Antoine
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Fri, Jun 08, 2012 at 10:09:34AM +0200, Antoine Jacoutot wrote: On Fri, Jun 08, 2012 at 10:03:51AM +0200, Alexandre Ratchov wrote: On Fri, Jun 08, 2012 at 09:16:13AM +0200, Antoine Jacoutot wrote: On Fri, Jun 08, 2012 at 08:53:25AM +0200, Alexandre Ratchov wrote: There's a MIDI based mixer API with a master volume knob and a per-application volume knob. There's a small program to control this in the audio/aucatctl port. If you plan to work on a mixer control GUI, I could prepare a very simple example program suitable for copy pasting in GUIs. Let me know if so. To be honest I'd rather have someone fix pulseaudio to use sndio; all GNOME applications have support for pulse and I'd rather have pulse with sndio rather than rewritting all GNOME apps that touch sound... This would stack two audio servers and two client libraries; this is unlikely to work very well. In this case, I will re-enable OSS in pulseaudio and use that. If you want to try it and have sndio diffs to review, fix, etc... don't hesitate. I'm not against pulse; it's just very low in my todo list. Also you should remove audio/jack then. IMHO audio/jack is very different. It's for music production software. In this case the right thing is to give jack full hardware access. There's no point in sharing the audio device between music production studio software (jack programs) and players/games/whatever during performance. AFAICS, that's most linux users opinion as well. -- Alexandre
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
If you want to try it and have sndio diffs to review, fix, etc... don't hesitate. I'm not against pulse; it's just very low in my todo list. I don't know anyone in the project able to do that but you (and jakemsr but he's gone now). -- Antoine
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Thu, 7 Jun 2012 09:01:48 +0200 Rafael Sadowski raf...@sizeofvoid.org wrote: - Forwarded message from Rafael Sadowski raf...@sizeofvoid.org - From: Rafael Sadowski raf...@sizeofvoid.org Date: Wed, 6 Jun 2012 10:39:50 +0200 Subject: WIP build x11/kde4/runtime with the new audio/pulseaudio To: Robert Nagy rob...@openbsd.org Hello Robert, I work with Amit and Vadim on the new KDE4[1] port. I have problems with the pulseaudio port. runtime output: /usr/bin/c++ -O2 -pipe -Woverloaded-virtual -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden -fexceptions -UQT_NO_EXCEPTIONS -O2 -DNDEBUG -DQT_NO_DEBUG CMakeFiles/testkhtml.dir/testkhtml_automoc.o CMakeFiles/testkhtml.dir/testkhtml.o -o ../bin/testkhtml ../lib/libkdecore.so.8.0 ../lib/libkhtml.so.8.0 /usr/local/lib/libphonon.so.7.0 ../lib/libkjs.so.6.0 ../lib/libkparts.so.5.0 ../lib/libkio.so.8.0 /usr/local/lib/qt4/libQtNetwork.so.9.1 /usr/local/lib/qt4/libQtXml.so.8.0 ../lib/libnepomukutils.so.0.0 ../lib/libnepomuk.so.0.0 ../lib/libkdeui.so.9.0 ../lib/libkdecore.so.8.0 /usr/local/lib/qt4/libQtDBus.so.2.0 /usr/local/lib/qt4/libQtCore.so.9.0 -pthread /usr/local/lib/qt4/libQtGui.so.10.0 /usr/local/lib/qt4/libQtSvg.so.7.0 /usr/local/lib/libsoprano.so.1.0 -Wl,-rpath,/usr/ports/pobj/kdelibs-4.8.3/build-amd64/lib:/usr/local/lib/qt4:/usr/local/lib -Wl,-rpath-link,/usr/ports/pobj/kdelibs-4.8.3/build-amd64/lib:/usr/X11R6/lib:/usr/local/lib ../lib/libkdecore.so.8.0: warning: strcpy() is almost always misused, please use strlcpy() ../lib/libkdecore.so.8.0: warning: strcat() is almost always misused, please use strlcat() ../lib/libkdecore.so.8.0: warning: sprintf() is often misused, please use snprintf() /usr/local/lib/libintl.so.6.0: warning: stpcpy() is dangerous GNU crap; don't use it /usr/local/lib/libgif.so.5.4: warning: vsprintf() is often misused, please use vsnprintf() /usr/bin/ld: warning: libpulsecommon-2.0.so, needed by /usr/local/lib/libpulse.so.1.1, not found (try using -rpath or -rpath-link) /usr/local/lib/libpulse.so.1.1: undefined reference to `pa_mutex_unlock' /usr/local/lib/libpulse.so.1.1: undefined reference to `pa_client_conf_env' /usr/local/lib/libpulse.so.1.1: undefined reference to `pa_mempool_block_size_max' /usr/local/lib/libpulse.so.1.1: undefined reference to `pa_client_conf_load' /usr/local/lib/libpulse.so.1.1: undefined reference to `pa_close_pipe' ... (other pa_ function). after a view in libpulse env LD_DEBUG=1 ldd /usr/local/lib/libpulse.so.1.1. I've seen this error output: loading: libpulsecommon-2.0.so required by /usr/local/lib/libpulse.so.1.1 dlopen: failed to open libpulsecommon-2.0.so unload_shlib called on /usr/local/lib/libpulse.so.1.1 dlopen: /usr/local/lib/libpulse.so.1.1: done (failed). Cannot load specified object This also explains the following messages: #ldd /usr/local/lib/libpulse*.so* /usr/local/lib/libpulse-mainloop-glib.so.0.0: Cannot load specified object /usr/local/lib/libpulse-simple.so.0.0: Cannot load specified object /usr/local/lib/libpulse.so.1.1: Cannot load specified object /usr/local/lib/libpulsecore-2.0.so: Cannot load specified object I hope this is helpful. I use fresh and clean -current. If I can help you, let me know it. Cheers, Rafael [1] https://github.com/jasperla/openbsd-wip/tree/master/x11/kde4 - Forwarded message from Amit Kulkarni amitk...@gmail.com - From: Amit Kulkarni amitk...@gmail.com Date: Sun, 3 Jun 2012 10:10:07 -0500 Subject: Re: build x11/kde4/runtime with the new audio/pulseaudio To: Rafael Sadowski raf...@sizeofvoid.org Cc: Vadim Zhukov persg...@gmail.com Message-ID: CAOS-L3jj=miXZ-dPevpF08x4hA4exr-MV-Ej+MDSnfK=zcr...@mail.gmail.com On Sun, Jun 3, 2012 at 7:12 AM, Rafael Sadowski raf...@sizeofvoid.org wrote: Hi Amit, hey Vadim, does anyone can build x11/kde4/runtime with the new pulseaudio? I get the following error(s): /usr/local/lib/libpulse.so.1.1: undefined reference to .. (all pa_* functions) Maybe my libpulse is the problem. I needfeedback. Thanks and cheers, Rafael Rafael, If you have built kdelibs, pim etc, please push them to wip. I will handle any cleanup and polishing. The new pulseaudio may cause problems. Ask brad, ajaucatot@ or robert@ for help in that. thanks - End forwarded message - - End forwarded message - Hi guys, I am building kdelibs, runtime and am hitting the same problem as Rafael. The undefined references to pthread_* functions in kdelibs was easy to fix. The problem seems to be /usr/bin/ld: warning: libpulsecommon-2.0.so, needed by /usr/local/lib/libpulse.so.1.1, not found (try using -rpath or -rpath-link) I confirm that libpulsecommon-2.0.so is present in /usr/local/lib/pulseaudio. Why isn't it loaded by ld? Any clue stick/ hints please? [ 2%] Built target knotifyplugin make -f
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Thu, Jun 07, 2012 at 05:30:39AM -0500, Amit Kulkarni wrote: Hi guys, I am building kdelibs, runtime and am hitting the same problem as Rafael. The undefined references to pthread_* functions in kdelibs was easy to fix. Disable building with PulseAudio support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Thu Jun 07, 2012 at 06:49:37AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 05:30:39AM -0500, Amit Kulkarni wrote: Hi guys, I am building kdelibs, runtime and am hitting the same problem as Rafael. The undefined references to pthread_* functions in kdelibs was easy to fix. Disable building with PulseAudio support. I think it's not the worst idea to disable PulseAudio (-DWITH=PulseAudio:BOOL=OFF). The speaker setup GUI needs pulseaudio. But, does it's really everything OK with our pulseaudio libs? Cheers, Rafael
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Thu, Jun 07, 2012 at 03:32:41PM +0200, Rafael Sadowski wrote: On Thu Jun 07, 2012 at 06:49:37AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 05:30:39AM -0500, Amit Kulkarni wrote: Hi guys, I am building kdelibs, runtime and am hitting the same problem as Rafael. The undefined references to pthread_* functions in kdelibs was easy to fix. Disable building with PulseAudio support. I think it's not the worst idea to disable PulseAudio (-DWITH=PulseAudio:BOOL=OFF). The speaker setup GUI needs pulseaudio. But, does it's really everything OK with our pulseaudio libs? It doesn't matter. You cannot use PulseAudio. Disable it. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Thu, Jun 7, 2012 at 8:40 AM, Brad Smith b...@comstyle.com wrote: On Thu, Jun 07, 2012 at 03:32:41PM +0200, Rafael Sadowski wrote: On Thu Jun 07, 2012 at 06:49:37AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 05:30:39AM -0500, Amit Kulkarni wrote: Hi guys, I am building kdelibs, runtime and am hitting the same problem as Rafael. The undefined references to pthread_* functions in kdelibs was easy to fix. Disable building with PulseAudio support. I think it's not the worst idea to disable PulseAudio (-DWITH=PulseAudio:BOOL=OFF). The speaker setup GUI needs pulseaudio. But, does it's really everything OK with our pulseaudio libs? It doesn't matter. You cannot use PulseAudio. Disable it. Ok, thanks a lot for the advice!
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Thu, Jun 07, 2012 at 09:40:52AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 03:32:41PM +0200, Rafael Sadowski wrote: On Thu Jun 07, 2012 at 06:49:37AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 05:30:39AM -0500, Amit Kulkarni wrote: Hi guys, I am building kdelibs, runtime and am hitting the same problem as Rafael. The undefined references to pthread_* functions in kdelibs was easy to fix. Disable building with PulseAudio support. I think it's not the worst idea to disable PulseAudio (-DWITH=PulseAudio:BOOL=OFF). The speaker setup GUI needs pulseaudio. But, does it's really everything OK with our pulseaudio libs? It doesn't matter. You cannot use PulseAudio. Disable it. I use PulseAudio on gnome everyday. -- Antoine
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
On Thu, Jun 07, 2012 at 04:07:38PM -0400, Brad Smith wrote: - Original message - On Thu, Jun 07, 2012 at 09:40:52AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 03:32:41PM +0200, Rafael Sadowski wrote: On Thu Jun 07, 2012 at 06:49:37AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 05:30:39AM -0500, Amit Kulkarni wrote: Hi guys, I am building kdelibs, runtime and am hitting the same problem as Rafael. The undefined references to pthread_* functions in kdelibs was easy to fix. Disable building with PulseAudio support. I think it's not the worst idea to disable PulseAudio (-DWITH=PulseAudio:BOOL=OFF). The speaker setup GUI needs pulseaudio. But, does it's really everything OK with our pulseaudio libs? It doesn't matter. You cannot use PulseAudio. Disable it. I use PulseAudio on gnome everyday. There is still no sndio backend.. I use it for the mixer. sndio isn't capable of that. -- Antoine
Re: [raf...@sizeofvoid.org: WIP build x11/kde4/runtime with the new audio/pulseaudio]
- Original message - On Thu, Jun 07, 2012 at 09:40:52AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 03:32:41PM +0200, Rafael Sadowski wrote: On Thu Jun 07, 2012 at 06:49:37AM -0400, Brad Smith wrote: On Thu, Jun 07, 2012 at 05:30:39AM -0500, Amit Kulkarni wrote: Hi guys, I am building kdelibs, runtime and am hitting the same problem as Rafael. The undefined references to pthread_* functions in kdelibs was easy to fix. Disable building with PulseAudio support. I think it's not the worst idea to disable PulseAudio (-DWITH=PulseAudio:BOOL=OFF). The speaker setup GUI needs pulseaudio. But, does it's really everything OK with our pulseaudio libs? It doesn't matter. You cannot use PulseAudio. Disable it. I use PulseAudio on gnome everyday. There is still no sndio backend.. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
