On 01/02/2012 08:20 PM, Len Ovens wrote:
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.
Musicians is a very diverse group, and the quality required by different
musicians is also very different. It's difficult to draw the line here;
to know what stuff really matters and where it does not.
A side note: Almost all Codecs have very good specs on paper (like DAC
S/N > 100 dB, etc), so the quality loss is in general on the analog
components outside the codecs.
For internal mics, an increasing amount of them are being connected
digitally, like this:
http://www.wolfsonmicro.com/documents/uploads/misc/en/WAN0263.pdf
I'm still very interested in knowing your ALSA info (see
http://wiki.ubuntu.com/Audio/AlsaInfo ), can you please give it to me?
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.
Sure; just don't write it as a general rule just because you have found
"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.
(But how many of those would succeed in an A/B listening test?)
"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...
Yes, but if the method suggested in the link works, then in fact it is
userspace who does the sample rate conversion, not the DSP firmware.
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.
Again an assumption without clear back up?
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?
Usually nothing, ALSA just sends the raw signal through to PulseAudio.
They are not "stereo" really. Where is this beam forming done? Is it
done in the sound chip DSP? or by the CPU?
In Windows 7, it's done on the CPU. In Linux, we have no such
application yet.
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.
As I've said before, given your alsa-info I might be able to write a
driver quirk that turns it into a mono mic at the ALSA level.
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.
https://wiki.ubuntu.com/UbuntuStudio
That said, I don't know what quality that documentation has.
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 don't know, but if I were you, I would start looking at
https://wiki.ubuntu.com/DocumentationTeam
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.
I'm not sure how our different types of documentation are organised, and
what types of documentation can go into where based on which criterias,
maybe Scott might know more of how that stuff works?
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.
I recently made the general audio troubleshooting sections at
https://wiki.ubuntu.com/DebuggingSoundProblems and
https://wiki.ubuntu.com/Audio up-to-date.
Sorry if I sounded harsh. It's just that it's not the first time I see
documentation that is based on individual pieces of hardware and the
documentation writer making the assumption that everyone else's hardware
works the same way. I understand that it is difficult to get the
overview - to know what problems are common and thus worth mentioning in
a general "help" page, and which ones are not.
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
--
Ubuntu-Studio-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
