Main Area and Open Discussion > Living Room
What's better: modern built-in motherboard sound chip or old sound card?
superticker:
OK, I've reread your post a couple dozen times ...-skywalka (November 09, 2006, 04:34 PM)
--- End quote ---
My explanation isn't complete if you're not familiar with OS internals, and that discussion is really a separate thread. Briefly, every OS has two schedulers, one for the application layer and another for the driver layer. For Windows, the scheduler for the application layer time slices around every 200mS, and that's just too slow for real-time scheduling, so--in contrast to a regular real-time OS--nothing real-time can be scheduled by the Windows or Unix application scheduler. So we turn to the driver scheduler instead.
The driver schedule in Windows is really stupid (not resource aware), and it has only one priority. (Regular real-time OSes have 64 at the driver level.) We're pretty limited there too. But Microsoft makes due with a single driver process that performs real-time de-compression of audio and video when you provide the codec plug-ins.
However, some codec plug-ins are more powerful (and slower) than others. What you would like to do is select the simplest, fastest one that provides the sound/video quality you need. I would schedule the fastest one first, but if your audio player wants more sound quality than this codec can deliver, then the de-compressor engine needs to pick the next slower one down on the priority chain.
So at the top of the codec priority chain is the highest-speed quality-limited codecs and at the bottom of the chain are the slow-speed high-fidelity codecs. You want the de-compressor engine to pick the fastest, simplest one--but not too simple, otherwise, your sound quality will suffer.
Thanx superticker. Do you know how to set these priorities?
-skywalka (November 09, 2006, 04:34 PM)
--- End quote ---
That's the easy question. The hard question is how do you decide on these selection priorities such that the trade-off between performance and sound/video quality is best determined? That's well outside the scope of this thread. What sound card and multimedia application players do is provide the codecs as a "kit" with their priorities setup for you. What end-users do is install multiple kits for WMA, WinAmp, RealPlayer, etc such that these kits and their priorities conflict with each other. Now you got a mess because a codec that WinAmp might rate as a 4 in its kit might be rated as a 6 in ATI's Multimedia player.
Also, some of the better (more expensive codecs) are smarter and faster with higher sound quality. Sorting through this incompatibility mess is also beyond this thread.
Anyway, from an Administrator account, open up the sound control panel and click on the hardware tab. That should show you the codec kits. Open up a given kit; for example, open Audio codecs. Inside that kit is a listing of individual codecs. Double-click on one to show its properties and which priority it is, which you can change or disable. Now I've given you just enough information to be dangerous. I'm not responsible for what happens after this.
I would suggest you find another website of audiophiles that have spent hours playing with different codecs to determine how to balance the priorities within your own codec kits.
For me, I just disable everything except just what my system needs. That makes my system very deterministic as far as codec selection goes.
superticker:
superticker: I'd say that hardware has a good deal to do with it, once we deal with stuff more advanced than dumb raw audio playback-f0dder (November 09, 2006, 05:22 PM)
--- End quote ---
I agree, but if I'm understanding the original post correctly, this user is getting stutters with a single-stream playback. That's caused because the input FIFO buffer into the sound chip ran dry before the driver could fill it again.
As far as fancy effects, that all must be done in hardware--for Windows. Even the driver layer isn't fast enough to assemble real-time effects on the fly. However, even though the hardware is doing the effects, the driver is still responsible for keeping the chip's FIFO buffers full. You'll get stuttering if those buffers run dry regardless of the hardware you're using.
A software interrupt in the Windows driver layer can take as much as 50mS to get service from the OS. An application running at the highest priority can take as long as 250mS to get service. Some might find this funny, but counting the mouse pulses actually gets more priority than servicing software interrupts. :-) I think that's pretty sad.
Don't move your mouse if you're recording something really important on Windows. :D Edit: BTW I'm joking, the A/D converters (on the sound chip) have big enough output buffers to handle the 50mS delay for driver service, but if you really moved that mouse ... that 50mS might get stretched some. (And that's not a joke.)
f0dder:
Hrm, are "mS" referring to mili- or microseconds?
Your above post on scheduling etc. doesn't really sound like the Windows NT I'm familiar with, and described in "Inside Windows 2000" (think it's been renamed to "Windows Internals" for the XP+ version).
superticker:
Hrm, are "mS" referring to mili- or microseconds?-f0dder (November 10, 2006, 09:26 AM)
--- End quote ---
That would be in milliseconds. Microseconds would be uS. To clarify, what I'm saying here is that you may have to wait up to 50mS for someone else's drive to finish service before Windows gets to yours. If your driver was the only driver in the system, you wouldn't have to wait this long. In other words, you're not waiting on the OS (as you're thinking), but rather on another driver to complete service. The point is: Microsoft cannot guarantee how long someone else's driver will take to complete; whereas, in a real-time driver there is a guarantee because of the tiered driver design. What does this mean?
A conventional OS is only able to service about 30 interrupts a second before context switch overhead brings it to its knees. In contrast, a real-time OS (RTOS) commonly does 3000 interrupts a second and the service latency can be as short as 50uS with RTOSes such as ThreadX. RTOSes can achieve this because their driver model is designed differently. For example, the first tier of interrupt service is done strictly in hardware. The hardware interrupt is thrown, the modern-day processor grabs the status register of the device that threw it and pushes it onto the stack (That occurs automatically in some modern processors.). It may also stash (and set a point to) the data if there are any. The only software operation is the scheduling of a software interrupt and its priority (for later service) to service the data coming in.
In contrast, a conventional OS (like Windows) would now try to service the data on the hardware interrupt. That means daisy-chained services (devices sharing that interrupt) will not have any service requests honored until that driver finishes servicing the data--and who knows how long that could take? If that happened in a real-time application, your cruse missile would hit a tree.
What we try to do with OSes like Windows is nest the system design such that the RTOS is out front of the host OS. The RAID disk controller on your system is an example of this. When you flash the firmware on your RAID controller, you're updating its RTOS and its application layer that handles controlling the disk arrays. The host OS only directs disk activity; whereas, the RAID RTOS is in charge of the actual real-time disk operations. SCSI disks also work this way.
Your above post on scheduling etc. doesn't really sound like the Windows NT I'm familiar with, and described in "Inside Windows 2000" (think it's been renamed to "Windows Internals" for the XP+ version).-f0dder (November 10, 2006, 09:26 AM)
--- End quote ---
Microsoft sells a product called Real-time Windows NT, which is a "scalable" version of their Windows product, but the term "real-time" is a misnomer in this context. For an OS to be real-time in the computer-science sense, it has to garanttee service times--which includes deadline scheduling, and the Windows scheduler doesn't do any of that. Moreover, there's way too much context switch overhead to ever make Windows a real-time OS, and you wouldn't want to either.
Remember, we design the scheduling of a conventional OS to maximize application layer efficiency (average service time)--which is the correct goal. In contrast, we design the RTOS for deterministic scheduling where a hardware servicing operation must complete within 3mS otherwise the disk head will miss the targeted sector. One design goal is mutually exclusive of the other.
We can talk more about RTOSes, but we should start a different thread. You can also find more about them if you Google "embedded systems design". Warning, this is a popular topic. :)
f0dder:
I know NT isn't real-time, but 50ms for an IRQ to be handled sounds ludicruous. And AFAIK, data processing isn't done directly in the IRQ handler, instead some state information is saved and passed down as an IRP, and the IRQ handler itself finishes quickly. Iirc linux does somewhat the same by having "high" and "low" parts of their IRQ handlers.
Hadn't heard about real-time NT, are you sure you're not thinking of NT embedded? Just because something is embedded doesn't mean it has to be hard realtime :)
Iirc there's also just one scheduler in the whole of NT, used for both usermode and kernelmode stuff - although there's a distinction between usermode and kernelmode threads. The "scheduler" also isn't a separate modular part, it's interweaved in most of the NT kernel because of it's particular design.
As for priority levels, there's 32 of them, with one being REALTIME. While that priority isn't strictly "realtime" by computer science terms, it's good enought that you can lock up a single-cpu system if you don't manually relinquish control...
Btw., might be a good idea for a moderator to cut off these last few posts into a separat thread so as to not pollute the rest of the thread :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version