[Fwd: Re: Docs]

[David Henningsson]

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