[Fwd: Re: Docs]

Len Ovens len at ovenwerks.net
Mon Jan 2 19:20:45 UTC 2012



---------------------------- Original Message ----------------------------
Subject: Re: Docs
From:    "Len Ovens" <len at ovenwerks.net>
Date:    Mon, January 2, 2012 11:19 am
To:      "David Henningsson" <david.henningsson at canonical.com>
--------------------------------------------------------------------------


On Mon, January 2, 2012 2:06 am, David Henningsson wrote:

> http://www.ovenwerks.net/UStudiodocs/internalaudio.html
>
> ...and I don't find it to be accurate.

Then don't look at the second one... it's worse.

> You seem to take the experience
> of your own HDA Codec and assume it applies to all HDA codecs, e g "The
> input preamps in these sound cards are generally noisy so lets try not
> to use them."

Yes this is based on my own experience... plus what I have read else
where. Try to remember we are talking about musicians here. The mics that
they are likely to have laying around are significantly different from
"made for computer mics". I should probably be specific about that.

> "Clock rates: The first thing to know about the HDA chipsets is that the
> adc operates at one clock rate." <- What is the source for that
> information?

Thank you for pointing this out. I was thinking of the AC97 spec. Where:

"Since AC-Link is a fixed-frequency link, all sample rate conversion
should be performed in the DC97 (controller) or in the software
driver."(from the wiki, but it confirms what I have seen else where)

HDA as an extension of that seems to have at least some implementations
that do the same. I did some messing around on the intel site just now and
everything I could find about HDA and how it works points to the AC97
spec... which even on the intel site is a broken link. HDA has a higher
sample clock than ac97, 4 times the 48000 ac97 had though as Intel says,
not all implementations use either the spec bitrate or the spec 32bit word
size. There are many differences from AC97 to HDA... but the more I look
the more cosmetic they seem to be. All the "good words" are there, but
audiophile sound cards are still selling well. They must be considering
the number of them that are out there... What I find more interesting is
that the hardware on these audiophile pci and pcie cards is older. The
Envy24 is still used a lot for example. It appears that many of the "HDA"
implementations are in fact AC97 hardware interfaced to the HDA standard
for driver capability and so the word "Dolby" can be attached.

> "All other rates are achieved by firmware in a DSP." "On some hardware
> the maximum rate can be found with this method: Determining the sample
> rate of a sound card." <- If the rate was changed in the firmware, user
> space would not be able to detect that using that method.

"On some Hardware" My assumption was that the only place this would be an
issue for someone using UbuntuStudio would be with a laptop/netbook...
that anyone with a desktop machine would have a "real" sound card if they
were going to record audio. It seems a number of laptops/netbooks run the
internal mic/s past the rate converting firmware and so this method works
for them. Again I should be more clear. Really the best solution is to
find the highest rate available which would be a multiple of 48000. In any
case 44100 is not a good rate to use for recording with these chip sets. I
will change things to reflect this. While I suspect the DSP rate
conversion has improved from the early AC97 systems I am not sure that
they sync channels... in fact they advertise the ability to have more than
one stream at the same time with different bitrates/wordlengths. I don't
know what they do with SPDIF inputs (which my old ac97 has) as SPDIF comes
with it's own clock, if it's 44100, I wonder what that does. I would love
to play with this on my machine with both AC97 and D66 interfaces. But the
two connectors are not matched, one is rca and the other optical. The
converters are not too expensive, but more than I am willing to spend just
to play with.

> "While the internal mic is obviously a mono device" <- this is wrong - a
> lot of machines have stereo internal mics. In Windows 7, this is used
> for beam forming and noise reduction algorithms.

Ok, I stand corrected. I have a question then. What does ALSA do with
them? They are not "stereo" really. Where is this beam forming done? Is it
done in the sound chip DSP? or by the CPU? I will take a wild guess here
that this is just two mics back to back with one of them signal inverted
for noise cancelling. So when there is only one mic fed to both inputs as
on my cheap netbook... not only is the noise cancelled but the audio as
well. That being the case, Linux is left with a problem... how to detect
only one mic. The same chipset might have one or two. While it might be
easy enough to solve in pulse (use a noise reduction switch in the user
interface that uses only left when off), there are enough applications
that use ALSA direct that this needs to be in the ALSA driver (in my
opinion). Using left as level and right as noise reduction is another
alternative... no link allowed, but... the labelling and linking would
have to change depending on which input source (internal external) was
being used. I don't know that this is a software bug... or a hardware bug
that can be fixed with software without creating other problems. The best
"fix" for this is documentation... How to use this feature.

> Also avoid links that points to how to change your system if you have
> some particular hw, e g "No internal mic on Acer Aspire" - these links
> become outdated quickly as we fix those bugs.

See my comment above. I will believe a bug fix when I see it. I don't
think it is really a bug so much as a misuse of hardware by the designer.
In any case, right now this is something that needs to be documented. It
has been known for over a year (the posts I was reading are dated 2010)
and there is no "bug fix", so for 12.04 it is probably valid.

Right now Ubuntu Studio has no docs at all. I am making a start with a
list of problems I have had and how I have gotten around them. I think I
have been pretty plain about that, but I will note that specifically. My
section on consumer grade cards needs to be redone as well. There are a
whole new pile of them I need to include... though most of these are
audiophile cards as pretty much all mother boards come with some sort of
sound interface built in.

> David Henningsson, Canonical Ltd.
> http://launchpad.net/~diwic

There is another question I have that you may be able to answer. I noticed
that all Xubuntu's documentation is copyright the ubuntu documentation
project. Should I be using the same copyright/license (artistic)? Is there
a template I should be using? Point me at a web page if that is the best
way for you to answer this.

I have a lot of stuff to add/fix. I am writing to the user who is either
switching from windows or is just starting to use their computer for
recording as a musician. I understand there are other uses, but I am
writing from my view point with the hope that those using US for other
uses will still find it useful... or will at least share their experiences
so I can include them. It may not seem very professional to you, but it
lots better than nothing (in my opinion) I understand that Canonical may
rather not have ubuntu documentation project mentioned as being part of
whatever I am doing if it does not meet quality standards. However, it may
be what new users who have questions get pointed at as there is nothing
else... Any links I should include would be great.

Thank you for your comments. They will help me to make a better set of
docs. I am hoping that other people will add some bits too, even if I have
to edit and format them for readability.

-- 
Len Ovens
www.OvenWerks.net


-- 
Len Ovens
www.OvenWerks.net




More information about the Ubuntu-Studio-devel mailing list