---------------------------- Original Message ---------------------------- Subject: Re: Docs From: "Len Ovens" <[email protected]> Date: Mon, January 2, 2012 11:19 am To: "David Henningsson" <[email protected]> --------------------------------------------------------------------------
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 -- Ubuntu-Studio-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-studio-devel
