Subject: Re: PortAudio Integration - msg#00054

Previous Message by Date: click to view message preview

Re: Non-native connections don't respect padevchooser settings

On Mon, 19.11.07 01:26, Ed Catmur (ed@xxxxxxxxxxxx) wrote: > Hi, > > I have something approaching the PerfectSetup[1], with a per-user daemon > and using the ALSA module and the esound protocol module for legacy > clients. > > When I change the default output device using padevchooser, it applies > only to native PulseAudio streams, not to ALSA or esound clients - in > particular, to Gnome sound events. > > I assume this is because padevchooser sets the default output device on > the root X window, which is then read by native clients but isn't > communicated to the daemon. Yes. Clients that do not use the native API do use only the algorithm that is native to their respective API for selecting servers. For ESD clients this means that only $ESPEAKER is checked. > Is there any way to fix this - for example, could the per-user > pulseaudio daemon listen for padevchooser's defaults on the root window > and apply them to streams without output device set? padevchooser as it stands now is going to die anyway. Right now it's mostly a zeroconf browser. I will replace it with something that connects to a local sound server and allows to change the default output device of it. This will allow "hot" moving of all current streams to the new device. However connections will always be proxied through the local server. This has a bad effect on latency but a good effect on the bandwith used and is probably the best way to go. As soon as this is done, padevchooser will work for both native and ESD clients. Stay tuned. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

Next Message by Date: click to view message preview

Re: Mixing streams

On Thu, 15.11.07 20:58, Tanu Kaskinen (tanuk@xxxxxx) wrote: > > Uh. That way you practically decrease the bit depth of your audio > > output to 15 bit. (Unless you happen to have a 24 bit soundcard) Not > > a very good idea for most people. > > I haven't compared 15 bit signal to 16 bit. I have a > 24-bit-only sound card and don't feel like setting up any > elaborate listening tests, so I'll take your word that > there's a perceivable difference. Hehe. I didn't say that it is perceivable. But it certainly a good thing to use the full 16bit range for recordings that are not normalized or for recordings with a large dynamic range, like Barber's adagio for strings. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4

Previous Message by Thread: click to view message preview

PortAudio Integration

Hi all, I just learned about PulseAudio, and I was wondering if there has been any work done on integrating it with the PortAudio (www.portaudio.com) cross-platform audio library - either using Pulse as a backend for Port and/or using Port as a module for Pulse (just like the ALSA module). From Googling, I found some people who said there was work being done, but does anyone have details? Brenton

Next Message by Thread: click to view message preview

pulseaudio won't run

I can't run a source-built pulseaudio 0.9.7. I get error pulsecore/mutex-posix.c:98: pa_mutex_unlock: Assertion `pthread_mutex_unlock(&m->mutex) == 0' failed. I found a similar error with a reply that said my libtool was the wrong version. I ran the recommended version of libtool with no improvement after a make uninstall and make clean followed by another ./configure and make. What else can I provide to debug/fix? Michael ____________________________________________________________________________________ Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/