Re: [pulseaudio-discuss] permanent microphone boost
'Twas brillig, and Piscium at 05/05/10 19:00 did gyre and gimble: I am completely ignorant about audio stacks, so I don't know if mic boost belongs in Alsa or PA. However as far as I know the only audio GUI that comes in the default installation for some distros is PulseAudio's. So from a usability point of view it would be nice to have a tick box for mic boost there. Such a tick box is for example available in Windows. So I am happy that I found how to solve my problem with the help of the forum, but other people are probably not so lucky! Well the solution you're using is not really a good one. It will not work when a mixer probably controls that element, which AFAICT is what should happen. Perhaps it's just not handled properly (despite the fact that on the surface the code looks like it should work). I'll ask Lennart to comment to hopefully get to the bottom of the real problem. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] 24 bit sound
Dear list, I'm in the process of buying a new soundcard. For a little more money I can get a 24-bit one, which I figure would be nice for things like software mixing. However, I can't find anything on how PulseAudio handles audio above 16 bit / 48KHz. Will my 24-bit upgrade be lost in software? Also, what about higher frequencies, 96KHz and upwards? Regards, David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] rtkit: add pid as argument
On 2010-04-25 22:11, Lennart Poettering wrote: On Sun, 25.04.10 21:41, David Henningsson (launchpad@epost.diwic.se) wrote: which handle corresponds to the thread, or even if that handle is local or not. Wineserver controls this information so all requests that involve handles involve a wineserver call, in general. So racing cannot happen, because wineserver is the only one making the requests. Just a question, what about RLIMIT_RTTIME, which rtkit requires to be set for enabling rt? AFAIK there is no equivalent in Windows. Well, we enforce RLIMIT_RTTIME mostly because we can, not because it would really inhibit all kind of RT-related misbehaviour of the clients. Or in other words: RLIMIT_RTTIME is quite useful as a protection against programming errors somewhre, however it is still easily circumventable by people who really try to do evil things, unless combined with other tricks, such as SCHED_RESET_ON_FORK. So let my rephrase my question to Maarten: Since there is no equivalent to RLIMIT_RTTIME in Windows, applications might assume they can run in RT for extended periods of time. This might be considered bad application behavior in any operating system, but nonetheless - do we risc regressions when these applications are being killed, instead of the previous behavior which just let them run in non-RT? // David ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] 24 bit sound
On Fri, 2010-05-07 at 00:22 +0200, David Björkevik wrote: I'm in the process of buying a new soundcard. For a little more money I can get a 24-bit one, which I figure would be nice for things like software mixing. What's your use case? You don't mention recording / audio production, so I'm assuming that you are mainly interested in the sound quality for music listening. I'm extremely skeptical about 24 bit making any perceivable difference for mixing multiple output streams together, and in the case where quality really matters, i.e. music listening, you tend not to have multiple output streams in the first place. However, I can't find anything on how PulseAudio handles audio above 16 bit / 48KHz. Will my 24-bit upgrade be lost in software? Pulseaudio should handle 24-bit hardware just fine. Also, what about higher frequencies, 96KHz and upwards? Pulseaudio should handle any sample rate just fine. Again, I don't believe you actually gain anything from higher sample rate, all other things being equal. Now, when comparing a higher-spec sound card to the cheapest available consumer card, all things might not be equal - the bit depth and sample rate don't determine the sound quality, but other aspects might very well make the higher-specced card sound better. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Fixing git branches
Hello, The rules documented in http://pulseaudio.org/wiki/GitBranches seem sensible to me, but the documentation doesn't match reality: according to the wiki page, there should be a branch named 0.9.21-stable, but there isn't, and all commits in stable-queue should also be in master, but they aren't. Which one is wrong, the documentation or the implementation? If the latter, are the following steps the things that need to be done in order to fix the situation? * Merge stable-queue into master. * Create 0.9.21-stable, initializing it to point to the v0.9.21 tag. * Go through all commits in stable-queue since v0.9.21 and move pure bug fixes into 0.9.21-stable, leaving minor new additions in stable-queue (this would mean rewriting stable-queue's history). If I've understood everything correctly so far, is there anything else holding that work from being done than the fact that nobody has had the motivation to do it? If there are no other problems, I think I'd be willing to do at least the first step next week. If the two other steps are considered important, I could do them too, but maybe the stable-queue-only solution for 0.9.21 updates is good enough for this release cycle. If I should go ahead and do the merge, does someone have hints what to do with the numerous .po file conflicts like this: HEAD #: ../src/modules/module-rygel-media-server.c:593 #: ../src/modules/module-rygel-media-server.c:607 === #: ../src/modules/module-rygel-media-server.c:570 #: ../src/modules/module-rygel-media-server.c:584 origin/stable-queue I'm not familiar with .po files - can I possibly ignore the conflicts altogether and regenerate the files easily after the merge to reflect the updated state of the master branch? If so, how is that done? -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
