A Little More About Windows Sound Architecture

In my previous post, I talked about Windows Vista/7 sound architecture and how it is not realtime which causes many problems. During my research I have come across much information and many articles online talking about this specific topic. Many people seem to be unhappy with this design.

My main goal is to plug in the guitar into the line in, monitor it thru the speakers and be able to play and record. This requires realtime monitoring of the line in signal. Also known as bit perfect data streaming. On Windows 7, monitoring has such high latency that it throws off my playing. This makes it impossible to play, monitor thru the speakers and record. If it was just a matter of the recording having latency, it could be adjusted during mixdown of the tracks. But for better recording and to not have to readjust tracks, it makes sense to try to reduce latency as much as possible. By the way, I use Reaper for multitracking, which means that Reaper plays all existing tracks while recording the new one.

There’s also a lot of people using Foobar and such applications to play their media realtime without latency. I’m not sure what the point is. If the entire playback has a latency of 200ms, you would never know. Your playback would simply start 200ms later but would be continuous after starting. To move away from media center and use another application for all of this seems rather pointless considering one would never know the difference. It would make sense if there was video also being played and the audio was out of sync. But that wouldn’t happend since the media player on the same computer would adjust for all of that.

Anyway, to each their own. Every user a right to use whatever appliation they prefer.

Back to the actual architecture. Microsoft has moved all the audio streaming out of the kernel and made it user-mode streaming. Microsoft claims that this provides low-latency, secure, reliable, glitch resilient sound framework. That is the Microsoft Core Audio API. For low latency Microsoft provides the Windows Audio Session API (WASAPI) which enables an application to control audio data flow from the application to audio endpoints. So if an application implement WASAPI, then it could run with minimum latency possible.

At this point it is not clear whether the Reaper team will implement WASAPI. If they do, it will really solve some recording latency items. But it would possible help in using other DSPs for audio processing. If the sound doesn’t have to go thru the Microsoft Windows Mixer and thru Microsoft DSPs, then it could be process with as many DSP as can be used by the user without increasing latency.

Windows’ New Sound Architecture

So Microsoft Windows Vista/7 have a new architecture for playing sound. They have what they call glitch resilient sound layer. Not glitch free. Essentially, a lot of sounds go thru Windows Mixer and get DSPs to fix the sounds and then the final sound is sent to the sound card. For normal people, this is causing many glitches and playback problems. For home recorders, this causes another issue: monitor latency.

What is monitor latency? When plugging in something in the line in of the sound card, you can monitor the same signal thru the computer speakers. This is not so much of a problem for recorded playback thru line in. But if the signal is live such as a guitar signal, it will have problems. My guitar goes straight to the line in. Ok, first, I realize this is not the ideal solution and one must either buy a recording interface or mic the amps. But realistically, at 1 in the morning when a musical idea is being formed, I just want to plug the guitar in and record it. I can mic the amps later or even record clean then DSP it with a vamp. Anyway, line in playing has so much latency in monitoring that I can’t play. It throws me off rhythm.

I’m getting frustrated with it. In Win XP it was simple. All line in signal was sent to the soundcard. Apparently, in Windows XP the sound was proceseds in Kernel Streaming mode. There was also the ASIO route. But in Vista/7, the sound stuff was taken out of the kernel level to remove BSODs. There is a Windows Mixer processing all sounds.

Microsoft does have a way for an application to get control of the hardware and route signal directly to the hardware and bypass the Windows Mixer. It’s called WASAPI – Windows Audio Session API. But an application has to support it. In other words, one cannot plug in a guitar, start playing and monitoring it. Some application must first be written to support the API, and then must be run before the sound is will bypass the Windows Mixer. This mode will also disable all other sounds from any other apps. So in other words all the dings, bings, and other sounds will not be played.

Hopefully, I can use my Windows 7 machine for home recording. Otherwise, I’ll have to move to Windows XP, or buy a recording interface. Not sure, which is the more appealing option.

The Windows 7

So it’s been a while since I last posted. Lot of things have been going on. I have been recording music, installing new programs, playing with different OS’s and just been busy in general.

The one thing I would like to mention in this post is that I’ve finally moved to Windows 7. Microsoft has made the Win 7 RC1 avaialble on their website and promised that it will work unrestricted until June 2010 sometime. After that it will begin shutting down every two hours until the user either buys Windows 7 or moves to another operating system. Buying an operating systme is something I haven’t considered much before. In the past this hasn’t been an issue. I either buy an OEM computer which includes the price of the operating system in the price of the computer or I have been able to take a copy of windows from work since our work says it’s ok to take software. But recently, I had decided that Microsoft probably isn’t ok with that. So I have been only using OEM Windows XP or Linux distros. Mostly Ubuntu. I had been thinking of buying a copy of Windows XP for a  computer that lost a hard drive and didn’t come with system recovery CDs. In the end I bought another computer and it had Vista installed. Anyway, back to Windows 7….

I had a Windows XP Media Center Edition 2002. It had been working great for a long time. But recently during a power outage, the mobo on the computer got fried. Which led me to buy a new motherboard and a new CPU, which led to new RAM, video card, and case. So only the HD was resused. Anyway, I was able to boot off the hard drive, call Microsoft, and have Windows reactivated. I moved the machine to a Virtual Machine and backed up the data. This way, if I want to revert back to Windows XP after the Win 7 RC is expired, I have the option. Then I installed 64-bit edition of Windows 7. I could have used the 32-bit but if the processor is 64-bit and if all the 4 slots on the new mobo can hold 2G each allowing total of 8G of RAM, I am going to need a 64-bit OS to recognize anything higher than 3G of memory. For the most part, Microsoft says only 64-bit Windows can recognize 4G of higher of RAM. There are some articles that worded confusingly which make it appear as if the user only needs 64-bit Windows for more than 4G of memory. Additionally, some people have reported being able to see 4G of RAM in 32-bit Windows XP.

Anyway, running 64-bit OS and 32-bit apps and mixing and matching is a tricky business. I’ll write a separate post on it. However, the main thing in a 64-bit OS is that all drivers must be 64-bit. Which means even if a hardware item has Windows drivers, it will only work for 32-bit Windows for sure. For it work on 64-bit Windows, it must have 64-bit drivers. Which means that two of my TV cards are unuseable at the moment. The Media Center has a TV Card that seems old and doesn’t seems to be have 64-bit drivers or any chance of getting new drivers. The other card is a AverMedia but it’s an older version and AverMedia may not have upated drivers for that card.

Despite all of that, with only 2G of RAM, Winows 7 seems to be faster on this computer than XP. It seems very responsive, which is a huge plus. The GUI has been totally updated and has a very nice and fresh appearance. The only nit is with the start menu. First, I don’t like the tree like expanding and collapsing menus. Those make it hard sometimes to see where you are. They shouldn’t but they do. It might be a matter of just getting used to the new menu. But other big thing is that I paid decent money to buy a 22″ widescreen monitor only to be restricted to small menu the size of a handheld device trying to squint and find my item. On Linux KDE simulates the Vista look and a similar menu look. But it allows to resize the menu so one can resize the menu to the entire screen. On Windows, you can’t. Which is frustrating.

Other than that, the fonts, the windows, the speed, the taskbar styles are all very impressive. The new feature of pinning apps to taskbar is pretty cool. You can pin an application to the taskbar. When that application is running it is shown by that same button. Hoevering over the button with the mouse will show a colored background indicating that an application instance is running and click on the button has the same minimize/resotre affect that the buttons in taskbar did in the previous editions of Windows. You can right-click and launch more instance of the application. Any application that is not pinned to the taskbar simply gets it’s own button on the taskbar when running. All of the apps are grouped by default. Not sure if this is changeable, but I liked the feature so really never wanted to change it.

Anyway, there you have it – a report on Windows 7. A preliminary report.