Re: [pulseaudio-discuss] Progress of 'dynamic default sink' or 'device preference list'?
'Twas brillig, and Ng Oon-Ee at 01/12/10 07:48 did gyre and gimble: Hi all, Now that 0.9.22 is finally out, I'm wondering what happened to what Colin mentioned some time back about 'device preferences'. As I understood at the time, assuming 3 possible sound devices (which may or may not be plugged in):- 1. New streams would be automatically sent to the highest priority device on starting 2. Streams which have been manually moved would stay where they've been moved to. 3. When another device which has a higher priority is plugged in, all streams (except for those in 2.) are moved to it. This scheme was mentioned in preference to a generic move all sound to latest plugged-in-device scheme, I believe. Are there any plans in this direction? Not done much on it TBH. Was wanting to discuss things with Lennart further as he never quite acked the approach (not the finer details anyway) and there are still some caveats to the approach (like dealing with apps that produce multiple streams where you want to control them independently - although I think that can and should be mitigated in an app specific way). I may just crack on an do it over the winter seeing as it's getting really cold now and worry about the finer details later. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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
Re: [pulseaudio-discuss] Card sometimes doesn't create sinks/sources
'Twas brillig, and Colin Guthrie at 07/11/10 20:51 did gyre and gimble: [Resend: Didn't get through moderation last time... 2nd time lucky] Hi, This is a strange one that I've seen happen very occasionally, but cannot nail down or reliably reproduce. I've got a set of USB speakers and when coming back from suspend with them plugged in (they were not plugged in prior to suspending but have been previously with the same instance of PA). The card is recognised and appears under Configuration tab or pacmd list-cards. It shows it's profiles correctly and selects the one I want, but it does not load the sinks and sources (in this case, just sinks). Unplugging and replugging doesn't help. Changing profile doesn't help. Everything looks correct, but the sinks just don't appear. Restart PA daemon and all is well - the sinks appear as expected. I've attached the log output, but the only strange thing in there to me is the events suppressed message. Sadly it's not clear exactly which event is suppressed when it prints that message which really doesn't help debugging... someone should really fix that with the log suppression technique currently in use! Just as an update to this issue, it appears to related to DBus connections being lost on a suspend/resume cycle. org.pulseaudio.Server is not on the session bus. The reason the sinks are not created is due to the reservation protocol to allow graceful handover to other applications. Because this fails to init, we do not create the sink. Not sure if this is a DBus of PA problem yet tho'. Thanks to David Henningsson for helping debug this when it cropped up again this morning. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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
Re: [pulseaudio-discuss] [PATCH] alsa-sink: take base volume into account when applying hw volume
On Tue, 30 Nov 2010, Colin Guthrie wrote: Any comments on this one Jyri? It seems add code to sink_write_volume_cb() to mirror the normal method sink_set_volume_cb() so looks OK to me but not followed the path through to see if this is supposed to be factored in already in some other way... Your thoughts would be appreciated. Yes, The base volume stuff appeared some time between the first version of sync volume and my upstream rebase. AFAIK, the fix is correct. However, there is still the double use of string bug (originally coming from me, but it looks quite different now). The bug is not serious, the print just is not very informative. Am currently working on a problem caused by safety-margin not taken into account when rewinding. When I get this fixed I'll add a fix for double use bug too. Cheers, Jyri Col 'Twas brillig, and Juho Hämäläinen at 25/11/10 13:15 did gyre and gimble: Currently if sink base volume differs from 0dB and sync-volume is used, wrong volume values are written to hw. This patch fixes that. Signed-off-by: Juho Hämäläinen ext-juho.hamalai...@nokia.com --- src/modules/alsa/alsa-sink.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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 mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-sink: take base volume into account when applying hw volume
'Twas brillig, and Jyri Sarha at 01/12/10 10:31 did gyre and gimble: On Tue, 30 Nov 2010, Colin Guthrie wrote: Any comments on this one Jyri? It seems add code to sink_write_volume_cb() to mirror the normal method sink_set_volume_cb() so looks OK to me but not followed the path through to see if this is supposed to be factored in already in some other way... Your thoughts would be appreciated. Yes, The base volume stuff appeared some time between the first version of sync volume and my upstream rebase. AFAIK, the fix is correct. However, there is still the double use of string bug (originally coming from me, but it looks quite different now). The bug is not serious, the print just is not very informative. Am currently working on a problem caused by safety-margin not taken into account when rewinding. When I get this fixed I'll add a fix for double use bug too. Great, I'll push this fix for now then and look forward to your next batch of fixes too :) Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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
Re: [pulseaudio-discuss] [ANNOUNCE] New Version Naming Scheme
'Twas brillig, and Colin Guthrie at 28/11/10 15:31 did gyre and gimble: As you know I've been angling for some kind of solid way forward with version numbers for a while so this email is basically a description of what has been done about this and how we'll move forward. ... OK, with no major problems with the two-part version scheme voiced, I've pushed this to master now. Nothing really major has changed so it shouldn't affect things downstream in any way (that's the theory at least!). Let me know if there are any strange build issues on master. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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
Re: [pulseaudio-discuss] Progress of 'dynamic default sink' or 'device preference list'?
On Wed, 2010-12-01 at 09:20 +, Colin Guthrie wrote: 'Twas brillig, and Ng Oon-Ee at 01/12/10 07:48 did gyre and gimble: Hi all, Now that 0.9.22 is finally out, I'm wondering what happened to what Colin mentioned some time back about 'device preferences'. As I understood at the time, assuming 3 possible sound devices (which may or may not be plugged in):- 1. New streams would be automatically sent to the highest priority device on starting 2. Streams which have been manually moved would stay where they've been moved to. 3. When another device which has a higher priority is plugged in, all streams (except for those in 2.) are moved to it. This scheme was mentioned in preference to a generic move all sound to latest plugged-in-device scheme, I believe. Are there any plans in this direction? Not done much on it TBH. Was wanting to discuss things with Lennart further as he never quite acked the approach (not the finer details anyway) and there are still some caveats to the approach (like dealing with apps that produce multiple streams where you want to control them independently - although I think that can and should be mitigated in an app specific way). I may just crack on an do it over the winter seeing as it's getting really cold now and worry about the finer details later. Thanks for the quick response Colin. Would user-input as to the design of this behaviour be helpful, or just a hindrance? ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] module-combine causes wine apps sound to crash [WAS: Latency control for wine ALSA emulation?]
So after more testing, I figured out my automatic load-module module-combine was causing the problem in this mail below. The same does not occur when running on the sound card itself directly. Is there any equivalent to tsched=0 for module-combine? On Tue, 2010-11-30 at 09:40 +0800, Ng Oon-Ee wrote: Dammit, forgot to include links! [1] - http://www.mail-archive.com/pulseaudio-discuss@mail.0pointer.de/msg06596.html [2] - http://pulseaudio.org/wiki/LatencyControl On Tue, 2010-11-30 at 09:39 +0800, Ng Oon-Ee wrote: Just recently I noticed my wine games weren't outputting sound. After some trouble-shooting (and remembering old issues I'd seen on this list), I realized that starting them with pavucontrol on fixed the sound, it would work just fine. I refer to [1] and [2] where Colin says this would be due to the reduction in latency. One workaround to this is tsched=0, but I haven't needed that before for ages. I'm on pulseaudio 0.9.22, just upgraded, also just upgraded wine to 1.3.8. However I can't seem to find a combination of downgraded packages (0.9.21 and 1.3.6 respectively, which used to work) which can make things work without pavucontrol again. Could this be affected by for example lib32-alsa-lib or alsa-lib or alsa-utils (lib32-alsa-utils as well)? I'd rather not hardcode tsched=0 because I'm on a laptop =). Please let me know what other things I can do to debug, would a log be helpful (since the issue is pretty certainly the latency control), or should I get a wine log instead. That would probably be a waste of time since winealsa isn't maintained currently I believe. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH] alsa-sink: take base volume into account when applying hw volume
On 2010-12-01 11:31, Jyri Sarha wrote: Am currently working on a problem caused by safety-margin not taken into account when rewinding. When I get this fixed I'll add a fix for double use bug too. Hmm, for tsched or non-tsched? I think we merged a patch related to this from pl bossart a while ago. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] module-combine causes wine apps sound to crash [WAS: Latency control for wine ALSA emulation?]
'Twas brillig, and Ng Oon-Ee at 01/12/10 10:59 did gyre and gimble: So after more testing, I figured out my automatic load-module module-combine was causing the problem in this mail below. The same does not occur when running on the sound card itself directly. Is there any equivalent to tsched=0 for module-combine? Not that I'm aware of... maybe requires someone to give module-combine some love? I've had issues with it crashing things long ago and not really seen much in the way of fixes for it in the past little while, so they could easily still be lurking there. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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
Re: [pulseaudio-discuss] Progress of 'dynamic default sink' or 'device preference list'?
'Twas brillig, and Ng Oon-Ee at 01/12/10 10:57 did gyre and gimble: On Wed, 2010-12-01 at 09:20 +, Colin Guthrie wrote: 'Twas brillig, and Ng Oon-Ee at 01/12/10 07:48 did gyre and gimble: Hi all, Now that 0.9.22 is finally out, I'm wondering what happened to what Colin mentioned some time back about 'device preferences'. As I understood at the time, assuming 3 possible sound devices (which may or may not be plugged in):- 1. New streams would be automatically sent to the highest priority device on starting 2. Streams which have been manually moved would stay where they've been moved to. 3. When another device which has a higher priority is plugged in, all streams (except for those in 2.) are moved to it. This scheme was mentioned in preference to a generic move all sound to latest plugged-in-device scheme, I believe. Are there any plans in this direction? Not done much on it TBH. Was wanting to discuss things with Lennart further as he never quite acked the approach (not the finer details anyway) and there are still some caveats to the approach (like dealing with apps that produce multiple streams where you want to control them independently - although I think that can and should be mitigated in an app specific way). I may just crack on an do it over the winter seeing as it's getting really cold now and worry about the finer details later. Thanks for the quick response Colin. Would user-input as to the design of this behaviour be helpful, or just a hindrance? Well I've gathered quite a lot of feedback already, but please feel free to critique more! I think the comments on the blog article[1] and a thread on this list which I've long since lost of my gmane cache were the best references... i'll try and dig out the archive link to that thread when I have a sec. Col 1 http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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] Mic input volume controls
Hi folks, The way we control mic input is quite broken. I've tested here with both IDT codecs and Realtek codecs (the two most common HDA Codecs AFAIK) and as far as I see they're both broken in the same ways. Let's assume that we have an internal mic and an external mic jack, with autoswitching in the kernel. We have a Mic Boost affecting the external mic jack, a Front Mic Boost affecting internal mic, and a Capture control affecting both. Mic Boost and Front Mic Boost go from 0 to 60 dB in 20 dB steps, and Capture goes from 0 to 22.5 dB in 1.5 dB steps. 1) The first problem is PA is unable to combine both of them correctly: for the first 0 to 22.5 dB, PA moves the Capture control only. After that say at 25 dB, Mic Boost moves to +20 dB, keeping Capture at 22.5 dB, then using softvol to compensate, instead of lowering Capture. I've been suggested that changing the order of Mic Boost and Capture improves this situation, so we should probably do that. Any objections? 2) The harder problem is that PulseAudio does not know whether to control Mic Boost or Front Mic Boost, since it doesn't know what path is active at the moment. While we really need some kind of module, and appropriate kernel support, the question is what we do before that becomes sufficiently available. The next best solution, would probably be to have different profiles and manual autoswitching. While I yet have to look into the details, I guess we'll have to add different profiles for Mic, Front Mic, Rear Mic and so on, instead of having them in the same file as we have today. Any thoughts? 3) It'd be great if we could present something else than Microphone 1, Microphone 2 and so on when we have more than one mic input. Any idea of where this name actually comes from, and how we can make it better? Thanks/credits to Vitaliy Kulikov for helping with the analysis. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Mic input volume controls
'Twas brillig, and David Henningsson at 01/12/10 13:55 did gyre and gimble: Hi folks, The way we control mic input is quite broken. I've tested here with both IDT codecs and Realtek codecs (the two most common HDA Codecs AFAIK) and as far as I see they're both broken in the same ways. Let's assume that we have an internal mic and an external mic jack, with autoswitching in the kernel. We have a Mic Boost affecting the external mic jack, a Front Mic Boost affecting internal mic, and a Capture control affecting both. Mic Boost and Front Mic Boost go from 0 to 60 dB in 20 dB steps, and Capture goes from 0 to 22.5 dB in 1.5 dB steps. 1) The first problem is PA is unable to combine both of them correctly: for the first 0 to 22.5 dB, PA moves the Capture control only. After that say at 25 dB, Mic Boost moves to +20 dB, keeping Capture at 22.5 dB, then using softvol to compensate, instead of lowering Capture. I've been suggested that changing the order of Mic Boost and Capture improves this situation, so we should probably do that. Any objections? With the direction argument passed to the relevant alsa calls as we currently have, swapping them around should indeed help here yes. No objection in principle for me. I guess we'll just statically swap them around for now? In theory, I guess the order of the controlled element pipeline could be dynamically adjusted so that biggest steps happen first... but this approach would possibly introduce unwanted side effets. 2) The harder problem is that PulseAudio does not know whether to control Mic Boost or Front Mic Boost, since it doesn't know what path is active at the moment. While we really need some kind of module, and appropriate kernel support, the question is what we do before that becomes sufficiently available. The next best solution, would probably be to have different profiles and manual autoswitching. While I yet have to look into the details, I guess we'll have to add different profiles for Mic, Front Mic, Rear Mic and so on, instead of having them in the same file as we have today. Any thoughts? I guess splitting them out makes sense so as to keep the pipeline for each clean. Would you still envisage keeping each mic as a separate port? (I guess the only other option would be to check if both mics could be opened at the same time in the profile probing to allow for two alsa-sources to be loaded at the same time. But that's likely going to lead to a lot of other problems, so perhaps best to leave that until UCM can just tell us without probing). 3) It'd be great if we could present something else than Microphone 1, Microphone 2 and so on when we have more than one mic input. Any idea of where this name actually comes from, and how we can make it better? I think ultimately from the table in ./modules/alsa/alsa-mixer.c There is a difference between internal and external microphones, so I guess making the distinction between front and rear and such like wouldn't hurt anyway... that said, WTF is the diffrence between a front and rear mic physically on a laptop? Do they *really* make laptops with two mics on them for this purpose? (from the names I'd have to expect a yes answer there, but seeing as my laptop has no built in mic, I'd say having two is just showing off :D) But more seriously, why are there front and rear mics? Is this for stereo recording? If so should these inputs be handled as a single, multichannel source rather than separate mono or stereo ones? I mean we don't expose the Rear playback so why do we do it on mics? As you can tell, my foo for recording is rather weak :D Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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
Re: [pulseaudio-discuss] [PATCH] alsa-sink: take base volume into account when applying hw volume
On Wed, 1 Dec 2010, David Henningsson wrote: On 2010-12-01 11:31, Jyri Sarha wrote: Am currently working on a problem caused by safety-margin not taken into account when rewinding. When I get this fixed I'll add a fix for double use bug too. Hmm, for tsched or non-tsched? I think we merged a patch related to this from pl bossart a while ago. Sorry, should have been more specific. I was talking about sync-volume-safety-margin, not rewind_safeguard related to tsched mode rewinding. However, the two things are closely related in this problem case. When DMA buffer is rewound the sync-volume events should rewound at the same time. This works already now. However the volume event rewinding is not modifying the new expiry time with sync-volume-safety-margin depending on whether we are changing the volume up or down. Cheers, Jyri ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Mic input volume controls
On Wed, Dec 01, 2010 at 03:09:10PM +, Colin Guthrie wrote: wouldn't hurt anyway... that said, WTF is the diffrence between a front and rear mic physically on a laptop? Do they *really* make laptops with two mics on them for this purpose? (from the names I'd have to expect a yes answer there, but seeing as my laptop has no built in mic, I'd say having two is just showing off :D) But more seriously, why are there front and rear mics? Is this for stereo recording? If so should these inputs be handled as a single, multichannel source rather than separate mono or stereo ones? I mean we don't expose the Rear playback so why do we do it on mics? As you can tell, my foo for recording is rather weak :D You might have more than two microphones built in to use them for beam forming applications in which case you're looking at a many channel array and do want everything in sync. On the other hand you may be doing something a lot less sophisticated and just have several sets of microphones for different physical use cases (eg, one set for use in tablet mode with the screen fully folded over and another for use in laptop mode) in which case you'd probably have only one in play at once. Or even some combination of the above :) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Progress of 'dynamic default sink' or 'device preference list'?
'Twas brillig, and Ng Oon-Ee at 01/12/10 15:53 did gyre and gimble: 1 http://colin.guthr.ie/2010/02/this-is-the-route-to-hell/ Thanks Colin, I'll definitely try and contribute ideas, at the least. May I assume this ML is better for it than your blog? =) General praise can go on my blog, criticism can come here :D But more seriously, yeah, this thread is as good as any. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] 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
