Messages

76

Living Room / Digital filtering for PC sound reproduction

« on: November 12, 2006, 02:15 AM »

... why do a lot of manufactures use simple R/C ?
It's easy to build cheap digital electronics (you really don't have to care about noise that much if it's digital anyways).
But it's hard and expensive to build low-noise analog devices.
They also tend to use up quite a bit of PCB real estate

-gjehle (November 11, 2006, 09:04 PM)

All the above is true, but there's a more important--theoretical--reason why a cheap first-order RC filter is used, and that has to do with distortion.  Any analog filer is a "causal filter" such that it can't know the future.  In contrast, digital FIR filters can be non-causal such that the value of the points are known before time zero and after time zero.  If we balance the filter coefficients across time zero, then we have a "zero-phase" filter across all frequencies.

Having zero-phase delay across all frequencies creates a distortionless filter for our application, so we really favor digital filtering over analog filtering when it's feasible.

For audio play back, the strategy is to oversample the signal by x4 (or better) using a first-ordered anti-aliasing analog filter (to minimize phase distortion) at ultrasonic frequencies, either 45K or 90KHz.  Then we run it through a zero-phase digital filter to achieve a "perfect" cut-off at whatever frequency we want, say 45/2 KHz.

Remember, for a non-causal filter, the cutoff can be perfectly sharp; whereas, for a causal filter (which includes any analog filter), there will always be a response roll off.  The higher the order, the sharper the roll off and phase delay (leading to more distortion).  So our cheap first-order RC filter produces less ultrasonic distortion than a higher ordered analog one.  But the assumption is standard audio equipment won't reproduce those ultrasonic frequencies (say at 90KHz) anyway.

I should add my area is in scientific instrumentation design, not sound card design.  Frankly, I couldn't tell you whether the PC sound chips are being design right or not.  But it wouldn't cost anymore to design them with x4 oversampling in mind and zero-phase digital filtering at their outputs.  I do know that some audio component CD players employ x4 and x8 oversampling and digital comb filtering, but I really can't speak for the sound-chip PC world.  Perhaps someone else knows for sure or has a link to a sound-chip spec sheet.

77

Developer's Corner / Re: Real-time OS drivers and their scheduling

« on: November 12, 2006, 12:27 AM »

In NT, a process is basically a container which holds one or more threads, various objects the process uses (files, sockets, pipes, mutexes, ...), the process memory map and some other stuff....

Each process has a process info block, and each thread has a thread info block.  So the scheduler only schedules threads, since that's the only schedulable entity in the system.

-f0dder (November 11, 2006, 11:40 AM)

I follow your point of view now, and it does make sense.  My only concern with this approach is that some processes (with fewer threads) may get starved for execution more than others (with many threads) since the scheduler fails to take the process membership of the threads into account when time slicing.  I'm wondering if that's a good thing or a bad thing?  Usually starvation is considered bad, but what about a scheduling bias favoring processes with more threads ready to run?  This is a harder question.     ... And I need time to think about this.  Perhaps as long as a process isn't totally starved, it's okay to give it less consideration if it has only one thread ready to run.

One of the requirements of an RTOS is the ability to substitute your own scheduler.  Some calls even let you pick the scheduler on their parameter list.  As a result, the scheduler needs to be autonomous from the rest of the OS.  Since the Windows scheduler is so intertwined with OS operations, I doubt you could replace it.

User-mode processes(!) are isolated against each other, and the kernel is isolated from user-mode processes as well.

-f0dder (November 11, 2006, 11:40 AM)

In most OSes, everything in "kernel mode" (which includes the drivers and the kernel/monitor) are mapped together such that execution can move from one place to another without the overhead a protection switch.  (Yes, that means a bad driver can crash the kernel.)  Does Windows work the same way?

I knows Microsoft signs drivers today, which means they shouldn't crash certain system parts.

BTW, Linux supports dynamic load/unload of drivers (or "kernel modules" as they call them) as well, and I'm pretty sure that other OSes do as well - I'd be very surprised if anything with a microkernel design doesn't, actually.

-f0dder (November 11, 2006, 11:40 AM)

Well, you run out of MMU register pairs for each separately protected module that must be constantly mapped into memory.  How many MMU mapping registers does the Pentium processor have?

Now daemon services, even if they are swapped in, don't necessarily always need to be mapped in if you're running out of mapping registers.  In other words, daemon services can share mapping registers.  But critical modules of the microkernel always need to be mapped in to avoid the overhead of protection switches.  So the question is, are there enough dedicated mapping registers for all the microkernel modules and dynamically loading drivers?  An you need to have a few "sharable" mapping registers left over for the application layer and its service daemons.

I haven't ported a protected-mode OS before, so I've never had to write any MMU management code before.  In the embedded systems world, we try to avoid protect mode if it's a small closed system (such as the engine controller in your car).

78

Developer's Corner / Re: Real-time OS drivers and their scheduling

« on: November 11, 2006, 11:01 AM »

Well, purge 9x from your mind - it's ancient and outdated, and is basically a DOS extender on steroids,...

-f0dder (November 11, 2006, 08:07 AM)

Yes, I agree.  I remember the lab supervisors griping about all the sporadic buffer overrun errors on the data acquisition boards when they pushed their Windows 95 machines.  The fundamental problem is that the driver service rates were too non-deterministic for their data streams.  I gave them two choices: (1) Buy new acquisition hardware with larger FIFO buffers ($1600 each) that would better withstand the bursty Windows service rates, or (2) replace the Win95 OS with Windows NT.  I was pushing solution (1) because I wasn't too sure solution (2) would work in the long run for them.

It doesn't pay to push a system up to its design limits; otherwise, reliability suffers.  They eventually understood that.

... there's at least one company that have real-time addons for NT.

-f0dder (November 11, 2006, 08:07 AM)

There's two companies.  One approach actually tries to preserve the Win32 API, but supplements its with additional scheduling calls.  If I'm remembering right, both approaches modify the driver model for those hardware devices that require real-time service.

Now as for scheduling... the NT scheduler schedules threads. Not "processes" or "drivers", but threads - although obviously it does deal with some process data, since thread priority is a mix of base process priority and thread priority, the process owning the current foreground window gets a slight boost, etc.

-f0dder (November 11, 2006, 08:07 AM)

Your terminology may be different than mine.  With my nomenclature, scheduling a process means doing a protection switch (Registers in the Memory Management Unit, MMU, are changed.  A process may even get mapped out of memory.).  In contrast, scheduling a thread requires no protection switch, so time slicing these have much lower context-switch overhead.

Servicing a software interrupt requires no protection switch either because all driver code remains mapped in addressable memory and is not protected from other drivers.  In other words, all drivers are mapped together with a single pair of mapping registers.  Now Windows NT can dynamically load drivers, which means the new driver (just loaded) won't be next to the others.  That's going to require an extra dedicated pair of mapping registers.  But most OSes can't do this and won't support hot-swapping of hardware.  Windows and VxWorks are the only exceptions.  (VxWorks is commonly used in communcations equipment because of its hot-swapping feature.)

But honestly, I don't know how the Windows NT scheduler works.  It may work differently than other OSes when it comes to threads and drivers.  Perhaps threads are protected from each other, but if so, then why call them threads and why have protection switch overhead if the "threaded" code doesn't need it?

Individual Windows processes are separately mapped from each other as expected.  So a protect switch is expected when time slicing between them.

There are kernel-mode threads as well as user-mode threads, for example the "lazy dirty-page writer" and "zero-page provider" are kernel-mode threads.

-f0dder (November 11, 2006, 08:07 AM)

Everything in kernel mode would use the same pair of MMU mapping registers, so no protection switch is needed.  As a result, it does make sense to use threads for all kernel task switching to reduce context-switch overhead.

Iirc an interrupt happens in the context of whatever active thread - which means that often a r3->r0->r3 context switch is needed, while a full register/state preservation and CR3 reloading isn't. This also means that at that IRQL, you can make very few assumptions on which operations are safe to perform.

-f0dder (November 11, 2006, 08:07 AM)

So you must write reentrant code for both levels of the Windows driver?  Does this mean that the completion routine (that's running as a real-time task in the application layer) is the only place non-reentrant code is allowed?

79

Living Room / Real-time OS drivers and their scheduling

« on: November 11, 2006, 03:46 AM »

This thread has now been moved to the programmer's area since it's about driver design.  I have a reply there.  https://www.donation...31.msg43263#msg43263

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....

-f0dder (November 10, 2006, 04:51 PM)

Continued on the new thread.

80

Developer's Corner / Real-time OS drivers and their scheduling

« on: November 11, 2006, 03:36 AM »

This is a continuation of another thread:  "What's better: modern built-in motherboard sound chip or old sound card?"

I know NT isn't real-time, but 50ms for an IRQ to be handled sounds ludicrous. 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.

-f0dder (November 10, 2006, 04:51 PM)

In a real-time driver, there is a high, middle, and low part.

The highest (hardware interrupt) part strictly services the hardware, and schedules the software interrupts and their service priorities (usually 0-63).  It may schedule several software interrupts since different parts (I/O initialization, I/O continued service, I/O completion) may require different priorities.  It will also grab the data and cache it if there are any. It's usually about 15 instructions or less.  Of course, its reentrant coding.

The middle tier routines will service the data.  This also must be reentrant coding, so 95% of the system calls can't be made from this level.  Obviously, no C library calls can be made from this level either since the C library isn't reentrant.  If necessary, this level will schedule a completion routine to be executed at the next level.

For the lowest tier (completion routines), the OS does save all processor registers automatically so there's high context-switch overhead entering this tier.  The good news is that your code does not have to be reentrant, so all the system calls are available to you as well as the C library.

It's interesting to note, but the service rates of each tier are highest, 3000 interrupt/sec; middle 300 interrupts/sec; and lowest 30 interrupts/sec.  Note that the maximun service rate of the lowest tier is the same in both the real-time OS as well as the conventional OS.  That's because both have the same context-switch overhead at this level because both are saving/restoring all the registers.

For (real-time) rate monotonic scheduling, we want each completion routine to have its own unique priority so there's deterministic (ordered) execution.  That's why real-time OSes (RTOSes) have so many priorities.

Windows is sluggish at handling interrupts.  I've had problems with National Instruments multifunction I/O cards giving me 50mS service rates and National says there's nothing they can do about it.  I admit these laboratory machines have a lot of I/O going on in them though.  That's why National offers a 486 processor with a Far-Lap OS (RTOS) for real-time control needs on Windows.  Edit: I just realized this was a driver-service problem with several Windows 95 machines.  The "native" Windows 2000 driver model should perform much better.

Hadn't heard about real-time NT, are you sure you're not thinking of NT embedded?

-f0dder (November 10, 2006, 04:51 PM)

We are definitely talking about the same product.  In 2000, it was called Real-time Windows NT, but now Microsoft is calling it Windows Embedded.  I just visited their website http://msdn.microsof...mbedded/default.aspx
It's a scalable version of Windows such that you can scale its memory foot print, which is important.  I think it's still over 500K though when really scaled down, but my information is old on this spec (1997).

Just because something is embedded doesn't mean it has to be hard real-time.

-f0dder (November 10, 2006, 04:51 PM)

I agree.  It is possible to do hard real-time in software, but I honestly believe hard real-time tasks are better done in hardware today because design tools for FPGAs are so easy to use now.  In addition, some SoC chips (Excalibur) incorporate both a processor as well as an FPGA all on the same chip, so doing both firmware and a gate array design does not increase chip count.

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.

-f0dder (November 10, 2006, 04:51 PM)

If that's true, then that's really bad design.  Please tell me that's not true.  In the application layer, you have two things to deal with you don't have in the driver layer.  One is protection switches (with the Memory Management Unit, MMU), and the other is semaphore testing and processing--which is really messy and big overhead--in a scheduler.  Some would also include resource awareness (what resources are tied up by awaiting processes), but I'm counting that case under semaphore management here.

In contrast, the driver scheduler has none of this overhead.  That makes it really lean and mean, which is something we really want in all OSes.  The typical OS implementation (and I think Linux works this way), is the let the high overhead application layer scheduler run as a driver-level task in the lowest priority, 63.  All other driver-level tasks run between priorities 0-62 such that when they complete, then the high-overhead scheduler runs.

As for priority levels, there's 32 of them, with one being REALTIME. While that priority isn't strictly "realtime" by computer science terms,...

-f0dder (November 10, 2006, 04:51 PM)

I follow what you're saying, but I wouldn't look at it that way.  All first tier (hardware interrupt) driver tasks must all complete first.  Afterwards, all second tier driver tasks must compete and there's no special priorities for these.  After that, then priories 0-31 for the main scheduler get attention where priority 0 is the real-time completion routine (which I "think" is swapable like anything else in the application layer, but maybe there's an exception here).  The point is Windows places it's completion routines in protected mode, which means more context-switch overhead (with the MMU) but they would be easier to write and debug than if they were in the driver layer.

Unlike Windows, most OSes require you to reload the entire OS if you enlarge the driver for any reason.  This makes developing in the driver layer inconvenient.  Although placing the completion routine in the application layer means more context-switch overhead (MMU register switches for protected mode), it is handier for development.

Most RTOS application designs don't even have MMU hardware, so doing completion routines in the third tier of the driver layer makes sense since the application layer isn't protected anyway.

81

Living Room / Real-time OS drivers and their scheduling

« on: November 10, 2006, 10:51 AM »

Hrm, are "mS" referring to mili- or microseconds?

-f0dder (November 10, 2006, 09:26 AM)

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)

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. 

82

Living Room / Re: What's better: modern built-in motherboard sound chip or old sound card?

« on: November 09, 2006, 06:10 PM »

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)

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.      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.)

83

Living Room / Re: What's better: modern built-in motherboard sound chip or old sound card?

« on: November 09, 2006, 05:37 PM »

OK, I've reread your post a couple dozen times ...

-skywalka (November 09, 2006, 04:34 PM)

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)

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.

84

Living Room / Re: What's better: modern built-in motherboard sound chip or old sound card?

« on: November 09, 2006, 12:02 PM »

On-board sound is more prone to stuttering when the CPU is busy.

-skywalka (November 09, 2006, 11:07 AM)

Whether your sound stutters or not has little to do with the hardware and everything to do the how the sound driver schedules its completion routines (driver scheduling).  Remember, Windows is not a real-time OS (RTOS); therefore, it lacks the proper multi-tiered driver model of a regular RTOS such as VxWorks, Nucules, MQX, etc.  To get around this shortcoming, Windows has a special encoder/decoder driver-level process for the real-time post-processing of the video and audio stream.  If you have stuttering and jitter, start by deleting the codecs you don't need or update them.  Chances are your codec mix is incompatible and/or their relative priorities are set wrong.  Set their priorities such that the fastest and most robust ones get chosen first.

If you have an early version of your sound driver, you should also update it.

85

Living Room / Re: What's better: modern built-in motherboard sound chip or old sound card?

« on: November 06, 2006, 07:02 PM »

... [3D] sound quality in games deteriorates with on-board audio even with basic EAX 2.0 standard. This is for sure ... from Realtek according to ... Analog Devices as reported by Techreport:  http://www.techrepor...ard-eax/index.x?pg=1

-Groetje (November 06, 2006, 11:39 AM)

Gee, I didn't even know what EAX-2.0 3D sound was until I read that very interesting article.  Your ears do tell you direction.  For example, if you're out hunting, and you hear a shot, you know which direction it came from if you were paying attention.

As the article points out, though, they can't say whether the failure of the Realtek-based solutions to support EAX occlusions and obstructions correctly is the fault of the Realtek sound chip or its driver.  (EAX occlusion effect is where the sound of a source in the 3D field diminishes when another 3D object passes in from of it.)  My guess is that this is a problem with its driver.  The driver isn't scheduling service of all the 3D effects as it should.

If you have a motherboard with a Realtek sound chip, I would go to their website and download their latest driver if your 3D game isn't behaving right.  Understand, manufactures are under pressure to get their latest technology out the door, so PC hardware typically ships with partially functioning drivers.  I think this audience already knows that.

Yes, if you're a bit of an audiophile or a gamer, a separate card is always better.  With the on-board sound chips you're playing the Russian roulette, you can have good results or you can end with a terrible sound ...

-Lashiec (November 06, 2006, 11:52 AM)

Are you sure that goes for an audiophile with Intel HD audio? I've only read the specs, but those do seem pretty good (8 channels at 192KHz/32bit, Dolby Pro Logic IIx...). Might not have super EAX support for the gamerz, but it seems decent enough.

-f0dder (November 06, 2006, 05:05 PM)

There's nothing wrong with the specs.  In fact, the spec are soooo good that engineers laugh at them.  Think about 32-bit sound for a moment.  10*log10(2^32)= 96 dB.  Ha, ha, now tell us your $4000 sound system can reproduce 96 dB correctly.  I would be impressed if it could reproduce 50 dB successfully (30 dB would be more realistic).  An analog FM radio station is limited to 15 dB per channel by the FCC; otherwise, it hogs the broadcast spectrum.

What the specs don't tell you about the motherboard (or daughter sound card)--and perhaps they should--is how much of that 96 dB is digital noise from the host computer.  If your motherboard's audio circuits are laid out correctly, noise won't appear until the 50 dB level, and your 30 dB sound system won't know the difference.  If the audio circuits are laid out poorly, noise might appear at the 30 dB level and a $2000 sound system will hear that.

When you build your system, always shoot for a balanced design.  If you spent thousands on your audio system, then why do any A/D conversion inside the host computer?  Will you hear a difference if you take the audio conversion outside "the box"?  Probably not, but your ears might be better than mine.  It's really about doing a balanced design; remember a chain is only as strong as its weakest link.

86

Clipboard Help+Spell / Re: Feature suggestion: search and replace

« on: November 06, 2006, 11:02 AM »

I'm wondering where one should draw the line between what AceText does and what a clipboard enhancer (like CHS) does?

-superticker (November 04, 2006, 08:54 PM)

I'm wondering too.

-rjbull (November 06, 2006, 06:09 AM)

This is where employing plug-ins to customize your own clipboard enhancer to suit your needs thereby avoiding software bloat is a really good thing.  It also empowers third-parties to write code for your application.

However Mouser is absolutely right; there's a lot of work in designing and documenting an extensible API.  Moreover, not every programmer welcomes the celebrity of becoming an open-source name in software design.  ... too many magazine editors calling.  Think how busy our Firefox plug-in API designer is, especially now that he's working for Microsoft.

... I'd like to be able to define a series of the actions that CHS can take, and have that group appear as a single menu item when you click CHS's icon, and have it apply them all in one pass.

-rjbull (November 06, 2006, 06:09 AM)

If I'm reading this right, you're suggesting a scripting language be developed for CHS?  Like designing an API, that's a really big job too!  I'm trying to think if there's some middle ground here?  For example, develop an easy way to call an external scripting engine from CHS, pass it the problem and let it crunch, then have it pass the solution back to CHS.  I guess that would be some kind of OLE or COM interface to CHS, and although that requires an API of sorts, Microsoft has already established some standard OLE calls CHS could implement for this.  (Understanding OLE is complex, though.)

Gee, a clipboard enhancer that supports OLE to other applications....  Sound like computer madness.  I'm wondering what I could do with such a utility?...  Would the end-user be clever enough to use this feature?

87

Living Room / Re: What's better: modern built-in motherboard sound chip or old sound card?

« on: November 05, 2006, 10:41 AM »

For generic stereo sound, the sound on the motherboard may be the best choice from a high-speed interface design prospective.  The "internal" PCI bus on the motherboard can have better throughput (perhaps even be 66 MHz instead of 33 MHz) than going through an actual PCI connector.  Also, the more cards you plug into the PCI bus, the more you digitally load that bus (which also increases the noise generated on the bus).

When laying out the motherboard, routing restrictions are placed on the analog/linear signal traces so they aren't running parallel to any digital traces.  That's why all the linear chips are grouped away from the digital chips.  I would agree some noise does creep in, but a real effort is made to minimize this with appropriate routing and layout.

In commercial instrumentation (such as the VXI instrument bus), the entire analog portion of the card is shielded with aluminum housing.  But VXI cards cost $2000 each and the digital noise must be kept to a minimum.  In the National Instruments SCIX bus, we place the analog cards (carrying mV signals) in an entirely separate subchassis from the host (digital) computer, which is the best solution.

If you're assembling a home entertainment center with 5.1 channels of sound, then you'll need a separate sound card.  In this case, try plugging the sound card as far away as possible from the other digital cards.  Use common sense when arranging the cards in your computer.  Your high speed DMA cards (SATA, SCSI, etc interfaces) should be placed in the fastest PCI slots closest to the RAM chips.  Any analog/linear cards should be placed as far away as possible from these high-speed cards to reduce switching noise from creeping into them.

Also remember, the filter capacitors in your power supply aren't getting any bigger as you add more cards to your computer.  As you load the power supply, its ability to filter noise will be reduced unless you install a bigger supply (with bigger capacitors).

88

Clipboard Help+Spell / Plug-in design thoughts

« on: November 04, 2006, 10:19 PM »

... what i think is wrong with plugins:  There is a fairly high overhead and significant amount of work to write a plug-in API, and then document it fully....

[In addition]... most programs can't support a significant community of plug-in writers, or *ANY* plug-in writers.

-mouser (November 04, 2006, 09:04 PM)

I agree 100%.  However, in high-usage applications such as e-mail clients, browsers, clipboard enhancers, CAD tools; there is indeed interest in supporting extensions.  AutoCAD is a good example.  There's a big vertical market for AutoCAD add-ons.  For example, there's one that lets you design a generic dress pattern, then the tool automatically generates different dress patterns to fit different sized women.  There's another tool for optimizing factory layouts such that the assembly steps/distance traveled for producing each product is minimized.  There are several traffic layout tools available in AutoCad.

AutoCAD simply provides a "generic" mechanical design environment, and it's totally customizable to specific mechanical design needs--and there are many.

Just looking at all the possible features and the number of clipboard enhancers out there tells us this is a high-use application and there are many possible features that can be included.  There's certainly interest in adding a variety of features to this type of application, and there's a big enough audience to support the effort.

In addition, I would agree Opera is a better web browser out of the box than Firefox, but I use Firefox because with about ten extensions (plug-ins), I can customize Firefox to be a somewhat better browser than Opera to suite my particular needs.

The hard part about designing any plug-in API is making it extensible so it enjoys a 20-year life expectancy.  This requires some developer experience with that application and some vision.  This is why the first web browser (remember Mosaic) didn't support plug-ins.  Designing and documenting an API for the open-source world is not a trivial task.

89

Clipboard Help+Spell / Re: Feature suggestion: search and replace

« on: November 04, 2006, 08:54 PM »

there is powerful search and replace within a single clip, but do you meant for a whole set of clips?

-mouser (November 04, 2006, 02:52 PM)

... I meant the ability to apply several search-and-replace pairs in one pass on one clip, so you could change many strings in one go.

-rjbull (November 04, 2006, 03:17 PM)

The existing Find and Replace function can change all instances of a lexical string.  But you would have to define a preset for each string replacement.

Are you saying you would prefer to have a glossary of established string replacements (equivalents)?  If so, AceText does this now.  Checkout its description at http://www.acetext.com/im.html

AceText goes one step further allowing multiple glossaries.  For example, DVM could be defined as:

dvm=Digital Volt-ohm Meter
dvm=Doctor of Vet Medicine

and depending on the most recent context, the appropriate glossary would be used.  This feature was really designed for use in Instant Messaging where abbreviations are common.

I'm wondering where one should draw the line between what AceText does and what a clipboard enhancer (like CHS) does?  In a perfect world, the clipboard enhancer would support plug-ins, and one could install an AceText plug-in (or even a glossary plug-in) if they really needed this feature.

I think the reason there are soooo many different clipboard enhancers is because the end-user's expectation of them is not clear.  The ideal solution would be to have just a few clipboard enhancers with many simple, compatible plug-ins for them.  Then the open-source community could concentrate on writing simple plug-ins rather than reinventing the clipboard enhancer.  Firefox extensions are an example of this.

The problem with plug-ins is that someone has to invent a COM or DLL API model for them and published it so open-source third-parties can download the SDK and develop them.  Who takes this leadership role is unclear.

90

General Software Discussion / Re: Repairing Windows XP (to restore AutoPlay)

« on: October 31, 2006, 11:32 AM »

BTW it's probably not svchost itself that's a problem - it's a relatively trivial service managing app, loading service DLL or EXE files.

-f0dder (October 31, 2006, 02:18 AM)

I got AutoPlay working.  You're right, it wasn't svchost.exe.  I did try renaming that executable only to find Remote Procedure Call (RPC) services died.  Apparently, Windows fails to replace it with a fresh version from a *.cab file.  Perhaps it's not important enough for auto cab-file replacement.

The problem is most likely registry setting based, as a corrupt .exe or .dll file would very likely give much worse problems...

-f0dder (October 31, 2006, 02:18 AM)

Right again.  This problem started after I uninstalled WinAmp two years ago.  I installed CCleaner today and it removed some obsolete CLSID registry entries (old Windows ActiveX controls for Windows Explorer).  I then compressed the registry.

Now AutoPlay works.  I can't understand why that would have made a difference (perhaps someone could explain) or why MS AutoFix didn't fix it, but I'm glad it's working again.

Well, back to my original problem (which I never mentioned).  I can't get launchU3.exe to continue running on my U3 Smart flash drive.  I thought it was because AutoPlay wasn't working (which could have been a factor), but launchU3 continues to quit.  Well, this is a new topic; let's not discuss it here.

91

General Software Discussion / Re: Repairing Windows XP (to restore AutoPlay)

« on: October 31, 2006, 01:24 AM »

did you disable any services?
it requires shell hardware detection.

-kimmchii (October 31, 2006, 12:42 AM)

The Shell Hardware Detection service is running.  A colleague suggested that it might be corrupted somehow.  Can I simply delete the svchost.exe executable in Safe Mode and have Windows decompress a fresh copy from a *.cab file?  My colleague was suggesting running a Win XP repair from the slipstreamed WinXP CD.

It's weird because when I plug a CD into the drive, ACCSee 7.0 does recognize it, but that's about all.  If I plug my U3 Smart flash drive into it, it detects and mounts it okay, but the launchU3.exe starts, but then quits.  It's almost like AutoPlay is working, but the executable image it invokes dies after 0.25 seconds.  Very strange.  I really need a debugger for looking at the OS events pertaining to this.  What OS-aware event-tracking debugger is most popular for Windows?

The log file of the MS AutoFix utility writes:

AutoFix [V5.2.3790.67]
Time [2006-10-27 12:54:19]
Microsoft Windows Version [5.1 (Service Pack 2) <2600>]
[Lines deleted]
Test [Drive Notification] - Instance [F:\, Drive Type: 0]:
    Result [Legacy Notification]: OK
    Result [AutoPlay V2 Notification]: Problems {
        Service (Silent)
        Shell (Deaf) }
    >> Repair << [Autoplay V2 Event]
      Step: No steps to take.
      Result: This AutoPlay setting cannot be fixed. Either the device is malfunctioning, or the wizard cannot determine the problem.
>> Required action: The wizard found problems but cannot fix them -> None

... which makes me think the svchost.exe service image is corrupted somehow.  It's like it isn't responding completely even though it's up and running.

92

General Software Discussion / Repairing Windows XP (to restore AutoPlay)

« on: October 30, 2006, 11:44 PM »

I've been desperately trying to get AutoPlay to work on my Windows XP SP2 system without success.  I tried the Microsoft AutoFix utility (search for "AutoPlay" on http://www.microsoft.com/downloads), and it acknowledges the problem, but says it can't fix it.  I then tried the Microsoft knowledgebase articles discussed at http://support.gatew...es/2-748931857.shtml without success.  I'm now down to item# 6 in their list, reinstall Windows XP.

My problem is that I'm running WinXP Pro SP2 (stand alone license), but the original distribution disk is SP0 for this system.  So what's my options?

A colleague told me I need to slipstream the original distribution CD to SP2, burn the slipstreamed image on a CD, then run a Windows XP repair from that burned CD.  Does this sound like the best plan of action?

BTW, if there's an easier way to debug AutoPlay to locate the exact failure in the Windows event chain, please suggest it.  Except for AutoPlay and the slow startup of .NET Framework 2.0 on login, this system is working well.

93

Mouser's Zone / Re: Windows Vista ready programs?

« on: October 30, 2006, 11:08 AM »

Today, Windows XP places your profile and application settings in the C:\Documents and Settings\%USERNAME%\Application Data folder, or more generally, the %APPDATA% folder which is inside %USERPROFILE%.  Vista will be moving user profiles such that %USERPROFILE% points to:

%USERPROFILE% == "C:\users\%USERNAME%\profile"

or something like that.  As long as the developer uses the logical names like %USERPROFILE% and %APPDATA% rather than the absolute path names for the installer and apps, you should be good.

Some of these changes are for security and disk backup reasons.  By placing everything that needs daily backup (and similar security settings) in the same directory tree, backups and disk-volume segregation can be managed more easily.

94

Clipboard Help+Spell / Solutions for structured e-mail templates

« on: October 28, 2006, 10:17 AM »

... have a submenu for email templates, then underneath that submenus for the various types of emails I send, with each template as a separate item.

-katykaty (October 26, 2006, 02:10 PM)

For e-mail templates that are "structured" (ordered) and somewhat "static", The Form Letter Machine utility is a much better solution.  Go to mouser's zone here on DonationCoder and download it.

You can create a pull-down menu of structured trees (templates) from which to select from.  You can also create a pull-down menu of symbolic variables from which automatic variable substitution within these static structures can be made.  It's a much better solution for canned templates.

As Mouser also pointed out to me, you can include any XML/XHTML codes in your templates at well, so you can get quite fancy.

I'm using The Form Letter Machine for an events announcement list I moderate with very good success.  Now I thought about going hog wild and setting up an RSS newsfeed for this announcements digest as well.  That requires generating some XML and conditional assembly, in which case the Help & Manual application maybe better, but that's really an overkill in most cases.

95

Living Room / Re: Comparison of online music services Pandora, Last.fm, and Yahoo Music

« on: October 24, 2006, 11:26 AM »

What really bothers me is when there are services with varying degrees of ads and intrusions and no option to opt out by means of cash payment.

-allen (October 24, 2006, 07:32 AM)

I wouldn't mind ads if I could pick their focus to fit my purchasing interests.

96

Clipboard Help+Spell / Re: Some clipboard clips not captured

« on: October 22, 2006, 09:16 AM »

There are options in CHS to set the size limit of clips that will be captured ...

-mouser (October 22, 2006, 12:11 AM)

That was the problem.  There's a parameter for the plain text byte limit with a grayed out check box.  But don't let the grayed out check box fool you; that limit parameter is really active, which is the way it should be--my oversight.

Also make sure you ... aren't in a different folder so that you are not seeing them being captured.

-mouser (October 22, 2006, 12:11 AM)

One of my suggestions on the Mantis Bug Tracker is to automatically switch to the New CHS folder whenever a new clip is captured so this mistake can't happen.

97

Clipboard Help+Spell / Some clipboard clips not captured

« on: October 21, 2006, 11:38 PM »

If I press the press the Copy to Clipboard button on The Form Letter Machine app (DonationCoder), that application indeed copies the active message tree to the clipboard as expected, but Clipboard Help+Spell never gets it.  I'm wondering if this is a problem with CHS capturing some clips?

98

Clipboard Help+Spell / Feature requests for Clipboard Help+Spell

« on: October 21, 2006, 03:07 AM »

I would appreciate anyone posting a list of top features they want added.

-mouser (October 19, 2006, 11:05 PM)

• Let Clipboard Help+Spell save a clip to a file.  This feature would let me write a clip to a network drive in order to update a website.
• Allow CHS to share user dictionaries with other applications such as The Form Letter Machine or Time & Chaos (PIM).  Both use the same spell checker.
• Address some of my requests/fixes posted on the Mantis Bug Tracker.

99

Clipboard Help+Spell / Quick Note hotkey feature

« on: October 21, 2006, 02:51 AM »

I've tried to get the Quick Note feature (Ctrl+Alt+A) in Clipboard Help+Spell to work without success.  I tried typing in a note, but it's not added to the New folder.  I tried selecting a folder out of the Group pull-down menu, but there's nothing in that pull-down menu.  What am I doing wrong?

The Quick Note feature is nice for replacing a scratch sheet of paper to jot something down.  Right now, I have to manually open CHS's main window, then press the New Note button to make a scratch note.  This works okay, but the HotKey for the Quick Note would be nicer.

100

Clipboard Help+Spell / Re: Discarding duplicate clips

« on: October 21, 2006, 02:25 AM »

there is a feature in CLCL that allows you to discard duplicate items when you do a copy. this is very useful because it keeps the Quick Paste menu neat and short.

-lanux128 (October 19, 2006, 11:23 PM)

Too many radio button options.  I would just retain the newest duplicate and automatically delete the others.  Why on earth would anyone want retain older historical duplicates in the first place?  I would apply this feature only to items the Quick Paste folder.

I just believe simpler is beautiful.  Too many features is a bad and confusing unless they can be folded into existing features well.