Re: [pulseaudio-discuss] Mic input volume controls
'Twas brillig, and Kulikov, Vitaliy at 01/12/10 17:34 did gyre and gimble: Hello everybody, I would like to add more details for issue #1. Just changing order of the capture and MIC volume controls in the path is not enough if those volumes have gain only ranges and the reason is that, AFAIK, currently PA adjusts requested volume to the higher HW volume step. But if we change it to lower HW step it should work just fine. Here is the example how that works. Let's say we have 22.5 dB gain only range with the 1.5 dB steps for capture HW control and 40 dB gain only range with the 10 dB steps for MIC boost control. Now, for all volumes between 0 and 10 dB PA will keep MIC boost level at 0 dB (when it is first in the path) and set capture level to 1.5, 3, 4.5 etc levels. And when level reaches 10 dB, then MIC boost will be set at 10 dB and capture at 0 dB. For the requested levels between 10 and 20 db, MIC boost will be kept at 10 dB and capture level will take the difference and so on. What you describe above is how PA currently works with regards to volume changes. We use the alsa API with a +1 dir argument to various functions e.g. http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.html#gef9c6ce9deb46de7b5727dc9982dc6d6 So we will use accurate or first above this means that less attenuation will be done if the accuracy cannot be performed exactly. So no need to worry about this. 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] Mic input volume controls
'Twas brillig, and David Henningsson at 07/12/10 08:35 did gyre and gimble: On 2010-12-04 19:09, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 02/12/10 10:38 did gyre and Let's play with the idea that we added a configurable Direction key to these profiles that controlled whether we moved up or down to the nearest step. Wouldn't that help? Then we could have Mic Boost first in chain, then set it to move down rather than up. Or maybe that we should instead say that if we're above 0 dB, we move down, and if we're below 0 dB, we move up? Would that make sense? I'm not really sure here. A specific direction key may complicate what is already a rather complicated thing, so if we can possibly do things sensibly without it, then I'd suggest that would be more attractive (if it works reliably enough). We want to maximise quality while avoiding digital distortion, that's basically the problem in a nutshell. We're assuming (sometimes incorrectly; but that's our best guess) that this golden spot will be achieved with all sliders at 0 dB. I think my approach makes sense, unless I'm missing something: If we're aiming for something above 0 dB, let's round down to make sure we avoid distortion, and if we're below 0 dB, let's round up to make sure we get maximum quality. I see what you mean here. At present we always pass +1 to the various alsa functions that take it (e.g. snd_mixer_selem_set_playback_dB()), but after we adjust for base volume, we may be requesting alsa volumes of 0dB (e.g. if our base volume is at 30%, then 35% will be a +dB in alsa). So yeah, I think you are correct here, the rounding needs to factor this in. It's a pity there is not a fourth option to these calls in alsa (i.e. in addition to -1, 0, +1) that did appropriate rounding, but we can deal with this I guess. And then we always start with the control that's closest to the physical hardware and work our way in. I guess so. What's in and out here; that's currently determined by the order in which PulseAudio reads them in, right? That complicates matters a little given the include file structure and so I'm thinking maybe we should add a extremity=number key to the config file? (This is unrelated to the direction key suggested previously.) We would then start with the one having the highest extremity score. I guess that would allow for a clearer, more deterministic approach. Otherwise we would get in trouble if we have a profile with a volume control B (with extremity=2), which then includes a file with both control A (with extremity=1) and control C (with extremity=3) in the same include file. I think that would actually make things clearer. What do you think? While I've never completely grasped absolutely everything in the mixer profiles stuff, I think you speak sense :) 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] Mic input volume controls
'Twas brillig, and Colin Guthrie at 09/12/10 16:12 did gyre and gimble: 'Twas brillig, and Kulikov, Vitaliy at 01/12/10 17:34 did gyre and gimble: Hello everybody, I would like to add more details for issue #1. Just changing order of the capture and MIC volume controls in the path is not enough if those volumes have gain only ranges and the reason is that, AFAIK, currently PA adjusts requested volume to the higher HW volume step. But if we change it to lower HW step it should work just fine. Here is the example how that works. Let's say we have 22.5 dB gain only range with the 1.5 dB steps for capture HW control and 40 dB gain only range with the 10 dB steps for MIC boost control. Now, for all volumes between 0 and 10 dB PA will keep MIC boost level at 0 dB (when it is first in the path) and set capture level to 1.5, 3, 4.5 etc levels. And when level reaches 10 dB, then MIC boost will be set at 10 dB and capture at 0 dB. For the requested levels between 10 and 20 db, MIC boost will be kept at 10 dB and capture level will take the difference and so on. What you describe above is how PA currently works with regards to volume changes. We use the alsa API with a +1 dir argument to various functions e.g. http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.html#gef9c6ce9deb46de7b5727dc9982dc6d6 So we will use accurate or first above this means that less attenuation will be done if the accuracy cannot be performed exactly. So no need to worry about this. I think I perhaps misunderstood your point. Perhaps you were talking about volumes above 0dB, in which case the +1 direction is not really appropriate. I kinda missed that distinction in David's original messages but I saw sense in my latest reply! 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] Mic input volume controls
-Original Message- From: pulseaudio-discuss-boun...@mail.0pointer.de [mailto:pulseaudio-discuss-boun...@mail.0pointer.de] On Behalf Of Colin Guthrie Sent: Thursday, December 09, 2010 3:27 PM To: pulseaudio-discuss@mail.0pointer.de Subject: Re: [pulseaudio-discuss] Mic input volume controls 'Twas brillig, and Colin Guthrie at 09/12/10 16:12 did gyre and gimble: 'Twas brillig, and Kulikov, Vitaliy at 01/12/10 17:34 did gyre and gimble: Hello everybody, I would like to add more details for issue #1. Just changing order of the capture and MIC volume controls in the path is not enough if those volumes have gain only ranges and the reason is that, AFAIK, currently PA adjusts requested volume to the higher HW volume step. But if we change it to lower HW step it should work just fine. Here is the example how that works. Let's say we have 22.5 dB gain only range with the 1.5 dB steps for capture HW control and 40 dB gain only range with the 10 dB steps for MIC boost control. Now, for all volumes between 0 and 10 dB PA will keep MIC boost level at 0 dB (when it is first in the path) and set capture level to 1.5, 3, 4.5 etc levels. And when level reaches 10 dB, then MIC boost will be set at 10 dB and capture at 0 dB. For the requested levels between 10 and 20 db, MIC boost will be kept at 10 dB and capture level will take the difference and so on. What you describe above is how PA currently works with regards to volume changes. We use the alsa API with a +1 dir argument to various functions e.g. http://www.alsa-project.org/alsa-doc/alsa-lib/group___simple_mixer.htm l#gef9c6ce9deb46de7b5727dc9982dc6d6 So we will use accurate or first above this means that less attenuation will be done if the accuracy cannot be performed exactly. So no need to worry about this. I think I perhaps misunderstood your point. Perhaps you were talking about volumes above 0dB, in which case the +1 direction is not really appropriate. I kinda missed that distinction in David's original messages but I saw sense in my latest reply! Yes, that's what I meant and my point was just to support David's suggestions. And I was about to type that scenario above actually does not work with the current PA but then saw your new response to David. Another thing, if my memory does not fail me, I believe that somebody in that same thread stated that 20 dB gain should be good enough for all purposes but that is not what my experience tells me. It may be good enough when someone has its mic close to the mouth but may be not good enough for mic far on the desk. This is why all those mic boost controls with the ranges of 30 or 40 dB gain are in the audio codecs. Vitaliy 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 ___ 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 2010-12-04 19:09, Colin Guthrie wrote: 'Twas brillig, and David Henningsson at 02/12/10 10:38 did gyre and gimble: On 2010-12-01 16:09, Colin Guthrie wrote: '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. Hmm. I remember Lennart's original approach would have been to maximize signal quality (i e, move Master and let PCM stay at 0 dB). Moving this analogy to the input case, what would be the highest quality for 20 dB - having Mic Boost at 20 dB and Capture at 0 dB, or Mic Boost at 0 dB and Capture at 20 dB? I would agree that using the highest quality pipeline is probably the best approach, but I'm afraid I also have no idea how to determine which approach is higher quality! My logic of putting the biggest steps first was really just to maximise using alsa controls rather than falling back to our own adjustments in software. This just seemed sensible but there could very well be quality arguments against it (I wouldn't want my PCM to be favoured over my Master for playback for example as the former is softvol) Let's play with the idea that we added a configurable Direction key to these profiles that controlled whether we moved up or down to the nearest step. Wouldn't that help? Then we could have Mic Boost first in chain, then set it to move down rather than up. Or maybe that we should instead say that if we're above 0 dB, we move down, and if we're below 0 dB, we move up? Would that make sense? I'm not really sure here. A specific direction key may complicate what is already a rather complicated thing, so if we can possibly do things sensibly without it, then I'd suggest that would be more attractive (if it works reliably enough). We want to maximise quality while avoiding digital distortion, that's basically the problem in a nutshell. We're assuming (sometimes incorrectly; but that's our best guess) that this golden spot will be achieved with all sliders at 0 dB. I think my approach makes sense, unless I'm missing something: If we're aiming for something above 0 dB, let's round down to make sure we avoid distortion, and if we're below 0 dB, let's round up to make sure we get maximum quality. And then we always start with the control that's closest to the physical hardware and work our way in. What's in and out here; that's currently determined by the order in which PulseAudio reads them in, right? That complicates matters a little given the include file structure and so I'm thinking maybe we should add a extremity=number key to the config file? (This is unrelated to the direction key suggested previously.) We would then start with the one having the highest extremity score. Otherwise we would get in trouble if we have a profile with a volume control B (with extremity=2), which then includes a file with both control A (with extremity=1) and control C (with extremity=3) in the same include file. I think that would actually make things clearer. What do you think? 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
Re: [pulseaudio-discuss] Mic input volume controls
On 2010-12-01 16:09, Colin Guthrie wrote: '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. Hmm. I remember Lennart's original approach would have been to maximize signal quality (i e, move Master and let PCM stay at 0 dB). Moving this analogy to the input case, what would be the highest quality for 20 dB - having Mic Boost at 20 dB and Capture at 0 dB, or Mic Boost at 0 dB and Capture at 20 dB? To be honest, I'm not sure, but in theory I assume Mic Boost should be at 20 dB and Capture at 0 dB because the signal path between Mic Boost and Capture would be stronger. Let's play with the idea that we added a configurable Direction key to these profiles that controlled whether we moved up or down to the nearest step. Wouldn't that help? Then we could have Mic Boost first in chain, then set it to move down rather than up. Or maybe that we should instead say that if we're above 0 dB, we move down, and if we're below 0 dB, we move up? Would that make sense? 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? Hmm, what does port mean in this context? Since we might have to control different pipelines, I don't see how we can have it in the same profile. (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, Agreed; let's avoid more than one alsa-source at this point even if it's possible for some codecs. so perhaps best to leave that until UCM can just tell us without probing). After having spoken to Mark Brown at Plumber's, he does not expect UCM to handle HDA stuff in the near future, it will be something for the embedded world primarily and we will still have to rely on PA's mixer paths. So unfortunately, I wouldn't hope for UCM to be our great problem solver. 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 forstereo 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
Re: [pulseaudio-discuss] Mic input volume controls
On Thu, Dec 02, 2010 at 11:38:08AM +0100, David Henningsson wrote: Hmm. I remember Lennart's original approach would have been to maximize signal quality (i e, move Master and let PCM stay at 0 dB). Moving this analogy to the input case, what would be the highest quality for 20 dB - having Mic Boost at 20 dB and Capture at 0 dB, or Mic Boost at 0 dB and Capture at 20 dB? It's not going to make such an enormous difference if both are analogue, but in general each analogue amplification stage will introduce noise so you want to amplify as early as possible. If Capture is digital (which is possible) then it is vastly better to do the amplification in the boost stage as you've discarded data in the ADC with the signal at the low level it was at. so perhaps best to leave that until UCM can just tell us without probing). After having spoken to Mark Brown at Plumber's, he does not expect UCM to handle HDA stuff in the near future, it will be something for the embedded world primarily and we will still have to rely on PA's mixer paths. So unfortunately, I wouldn't hope for UCM to be our great problem solver. Well, someone can always set up use cases for their system if they want to. I'd expect Pulse to be able to DTRT with PC hardware without any of that most of the time, though. ___ 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] 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
