pulse audio

Len Ovens len at ovenwerks.net
Sat Dec 24 19:29:18 UTC 2011


On Fri, December 23, 2011 8:47 pm, David Henningsson wrote:

>> Internal mics:
>>     In the aspire one netbook(and others with the same chip set) in
>> order
>> to use the internal mic. The capture must have the two channels
>> unlocked and the left channel set at 0 then use the right level to set.
>> Wow, thats intuitive... I'm not sure thats the whole thing because I
>> was getting use out of it with both levels the same at least with the
>> alpha. I tried this with xubunutu oneric.
>
> This means you have a stereo internal mic where one channel is phase
> inverted. This is not very common, but I've seen it before. In some
> cases, we tweak this by turning it into a mono mic, since we have no
> code for automatic [1] phase inverting in either ALSA, PulseAudio or
> Jack (AFAIK). You can check if this is fixed upstream using
> https://wiki.ubuntu.com/Audio/UpgradingAlsa/DKMS and if it isn't, feel
> free to file a bug for it (using "ubuntu-bug audio") and point me to it.

Quick check to see if phase inversion is problem... turn up left turn down
right... that works too. Yup Phase inversion it is. Using only left is
kind of a standard anyway, and the mic is a mono device. I am wondering if
this is a little known "feature" for use in phone stuff to limit feed back
with an open speaker... of course the speaker is some distance from the
mic and would put out whatever phase of the mic we are using plus the
distance would add phase too. It could only help (be possibly useful) if
the two channels can be accessed separately. But it seems to be set up as
a mono input anyway as I can't record the two inverted channels. I also
can't use the internal mic along with an external mic, so choosing phase
is no help there. Having thought (out loud, sorry) about this. My sense is
that any software that deals with this mic should not offer to lock these
channels. And instead of combining them should offer one or the other with
a single slider and phase switch. Personally, I would just offer the left
channel and be done with it. Set right to lowest setting. I am guessing
this should be done in the kernel or alsa driver. Not in pulse.

>> Internal mics 2:
>>      I don't know why, but... for some reason the internal mic seems to
>> have it's own adc. It is set at one speed, in my case 48000. When read
>> at 44100 (the default) it sounds staticy because of the mismatch. Kind
>> of like under runs I would guess. So on this machine (cheap netbook)
>> It is best to set the default to 48000 in the pulse config file. Pulse
>> is highly configurable there is no doubt, but figuring that out takes
>> some time. I would suspect both ALSA and jack should also be set to
>> the native frequency of the sound card (if using the internal sound
>> card). Good sound cards don't have this problem.
>
> Hmm, I guess they chose the cheapest possible HDA Codec as well, huh?
> Anyway, this is a problem I've vaguely heard of, but I'm not sure if
> we/upstream have a good solution for this class of problems yet.

Well I got this info from this page:

https://wiki.archlinux.org/index.php/PulseAudio

They say to test like this:

----------------8<-------------------------------
2. Determine sampling-rate of the sound card

arecord -f dat -r 60000 -D hw:0,0 -d 5 test.wav

output:

  "Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 60000 Hz,
Stereo
  Warning: rate is not accurate (requested = 60000Hz, got = 96000Hz)
  please, try the plug plugin

observe, the got = 96000Hz, this is the max sample-rate of our card.
---------------8<----------------------------------

In my case I got 48000. So I set that as the default in
/etc/pulse/daemon.conf

Obviously arecord has some way of asking for a rate change and getting
back what the rate change returned. Perhaps pulse could use the same
technique on startup to set its default rate. (setting 96k as default is
kind of a drag, but 48k would be ok) My info on the intel HDA style audio
stuff (admittedly outdated) is that they use a 48k ADC and a firmware dsp
rate changer to get anything else... means that recording at 44100 it
would be easy to get two channels that end up out of sync by the end of
the recording. Some of the newer ones might start with 96k and work from
there. I would think grabbing every second sample for 48k would be
acceptable. In the case of rate changes happening anyway, the native rate
should be used for best quality. (with an internal mic? quality?) Some HDA
setups even run 48k through the rate change DSP to get 48K :-P

All of these things should be part of a "how to set up your hardware for
best sound" How to. It is all very well to ship pulse/jack/alsa set up to
the tested best rate and have the mic set up right. But the user who goes
"I'm making a CD I want 44100" without knowing the problems doesn't help.
I don't know if a software rate change can do better than an on the fly
dsp... it should be able to correct for drift on a file of known size and
make sure all channels are in sync as it goes though. It has time as it is
not doing things in real time. At the very least, it is all open and
available for people to change. The dsp firmware is closed.

> [1] You can insert manual ttable tweaks in .asoundrc though to turn one
> phase around, but then it might do that for all inputs and not just the
> internal mic, which is not what you want...

As it is a mono device, I would prefer to call the left and right two
separate channels or just use the left channel and turn right off. For my
own use, it doesn't matter. I know whats happening and will adjust for
whatever use I have.

Any changes I would want made would be for general distribution...
Probably this means in the alsa module for this chip. I want what is best
for Ubuntu studio at this point. It looks like documentation is the best
solution. We are aiming at a wide use spectrum even though it is only the
creative end of things. I would think that for most people using
ubuntustudio, getting to know one's gear is just part of the process.
Having said that, I am sure there are lots of people who want to hit one
button and go too.

Anyway, Merry Christmas... Don't be in a hurry to answer this. It sounds
like fixing things for one system can break things for another too easy.
Better to learn one's systems quirks.


-- 
Len Ovens
www.OvenWerks.net




More information about the Ubuntu-Studio-devel mailing list