What is the "Background Service" option do with the audio sound quality, even with ASIO?
Are there any most details concepts to let us know?
Isn't ASIO just call up the audio hardware directly by native low-level C++ and load and owned by the software program itself?
then why is it related to the "Background Service" of "Processor Scheduling"?


--------------------
Cubase 5.1 + Foobar2000 -> ASIO + MMCSS + Windows7 -> SIIG TI chips 1394 PCIe -> Echo AudioFire 4 -> HH MX250 + Wharf Delta70
A native USA style contemporary R&B artist in HongKong

Quote Parco:

---

What is the "Background Service" option do with the audio sound quality, even with ASIO?

---

There is no such connection to sound quality mate - you worry too much. I recommend some beer or perhaps a night out with a lady to take your mind off your slightly obsessive interest in computer audio fairy dust.

--------------------
PC-Music.com hints, tips & reviews
Rain Computers UK - Creative Audio PC's

Quote Parco:

---

What is the "Background Service" option do with the audio sound quality, even with ASIO?
Are there any most details concepts to let us know?
Isn't ASIO just call up the audio hardware directly by native low-level C++ and load and owned by the software program itself?
then why is it related to the "Background Service" of "Processor Scheduling"?

---

I have always used "Background services" because it is recommended but I will have to admit that it did not make any perceptible improvement over "Programs" on the computers I had. I remember two stories about this:

s1 - In Windows language, the ASIO driver is a "Background service", not a "Program". Then giving more priority to the background services is a way to give more priority to the ASIO driver, somehow

s2 - When multiple programs are running (which is always the case, as the OS itself consists in many programs running together), each is executed one after the other so that you have the illusion of "multi task" operation. In "Background services" mode, the execution cycles are longer than in "Program mode". In "B s" mode, the audio is processed in longer chunks, so there are less risks for dropouts related to discontinuities between audio chunks (these discontinuities happen when there is not enough time or power for calculating an audio chunk properly)

Not sure which one is correct (if any), I never checked it. I am nearly sure there is a SOS article about this -- try to search "Background services" in the online articles.

Yep, I've written about it several times over in the years in SOS

Changing Processor Scheduling to 'Background Services' instead of 'Programs' CAN make a significant difference to the low-latency performance of ASIO drivers (although it makes absolutely no difference to 'audio quality' ). I say 'CAN', because although it's been proven to reduce CPU overheads and cure random audio crackles on many systems over the years, on others it seems to make no difference to performance, and in a few cases it has actually downgraded audio performance. So I suggest doing this tweak as a matter of course but then double-checking it when you're running a project that pushes your system close to the edge. If you start to hear the occasional drop-out, change the setting and see if it gets better or worse, then stick with the setting that works best on your system.


Martin

--------------------
YewTreeMagic

That's a bit pragmatic isn't it?

--------------------
Andi, www.thedustbowl.net Mixing, Mastering, Audio Editing at The Dustbowl Audio

Hi Andi!

I try to offer advice that will work sensibly for everybody


Martin

--------------------
YewTreeMagic

Quote:

---

s2 - When multiple programs are running (which is always the case, as the OS itself consists in many programs running together), each is executed one after the other so that you have the illusion of "multi task" operation.

---

Off tangent a bit. Are there any home/office/DAW type computers that utilise parallel processing, as opposed to task-switching which we apparently call multi-tasking, but as mentioned it is actually the CPU switching between tasks in rapid succession. Don't multi-processors use parallel processing, say an i7 with 4 cores? each core sort of operating independently of another?

And so if this does happen could for example Kontakt be running in one core, Reason in another and Cubase in another - operating system in the 4th?

Quote Martin Walker:

---

Hi Andi!

I try to offer advice that will work sensibly for everybody


Martin

---

--------------------
Andi, www.thedustbowl.net Mixing, Mastering, Audio Editing at The Dustbowl Audio

Nope, operation system may use both 4 cores at the same time, 'cause there so many services and processes are running at the same time which are the parts of your OS, and not any else other programs you've installed after OS installed.

1 software thread can only run inside 1 core, in 1 CPU physical thread, but 1 process may contain several or even thousands of software threads running at the same time that can completely use all of your CPU cores.
And, there are so many processes running at the same time inside your computer. You may see all them just in your windows task manager, 1 process can run in at least 1 to several cores.
So for programs, i'm so hard to believe that they can just only run in 1 core, as well as the OS nowaday. So the key point is not which program can run inside which CPU core, the key point is how good is the OS designed and support for SMP and parallel computing, and how good is the OS manage and allot the process or software threads to which cpu cores or physical threads.

i7 CPU which i am using now have 4 cores and HT too, so there are 8 CPUs recognized by my windows 7.

--------------------
Cubase 5.1 + Foobar2000 -> ASIO + MMCSS + Windows7 -> SIIG TI chips 1394 PCIe -> Echo AudioFire 4 -> HH MX250 + Wharf Delta70
A native USA style contemporary R&B artist in HongKong

Quote Parco:

---

So for programs, i'm so hard to believe that they can just only run in 1 core, as well as the OS nowaday.

---

Well, it is possible to write a program that uses only one core, but as you said this core will always be shared with other programs anyway. I don't see much application for this in the context of realtime audio.

There was an interesting article about multi-core processors in SOS sometime ago:
http://www.soundonsound.com/sos/jan08/articles/pcmusician_0108.htm

I have no idea if this is still valid today. Is there a more recent article about this?

Yes, things have moved on since since I wrote that feature back in SOS January 2008, but so have the number of cores found in modern CPUs

Most audio developers do pay more attention to scalability across multiple cores nowadays, but you can still find situations where a dual-core processor with a faster clock speed will outperform a quad core with more processing power overall - it’s all down to the sort of softsynths and softsamplers that you’re running and how you’re using them.


Martin

--------------------
YewTreeMagic

Martin,

Multi-threading of DAW multi-tracks processing, multi-plugin processing or multi-effecter processing
and
multi-threading of the same one audio in/out stream to the audio hardwares
are two different matters.

--------------------
Cubase 5.1 + Foobar2000 -> ASIO + MMCSS + Windows7 -> SIIG TI chips 1394 PCIe -> Echo AudioFire 4 -> HH MX250 + Wharf Delta70
A native USA style contemporary R&B artist in HongKong

Thing is, to do audio actually reliably (as opposed to works most of the time) requires that all the audio processing be treated as a hard realtime activity.

Hard realtime means that any task requesting processor time can give a requested amount of processor time AND a deadline, as in "Need 500us processor time, within 5ms of audio data becoming available", and the OS needs to be able to guarantee to schedule the task within those constraints, or tell the requesting task that the time is not going to be available.

This gets **REALLY** complicated when you have N tasks all giving different processing requirements and deadlines, and M cores, particularly when M < N, M > 1, and when some of those tasks have constraints more like "Within 5ms of audio becoming available and after task X has completed, or even "every 6th time audio becomes available and after task X & Y have completed for that cycle, 40ms, and must complete before the next 6th audio block comes in". Even just establishing if a requested load can be met gets into high end graph theory.

Hard realtime on a general purpose OS is still an area of active research on task scheduling, see papers on such things as 'deadline schedulers', further hard realtime and high throughput are actually very different aims, and usually the performance (measured in terms of mean CPU work done in a given time) is very much worse in a hard rt system (but there are guarantees that whatever is being done, will meet deadline).

The simplest approach is actually to decide the scheduling in advance and then if something does not use its entire allocated time, just idle the processor until it is time for whatever you scheduled next to run, works for RT, but has horrible effects on overall system performance as you have to assume worst case workloads for everything (But it is reliable), using processor affinity to lock one or more cores into just doing the RT processes helps some.

In terms of utilisation of a multi core machine, that too is a hard problem in general, as very often the things you would like to run in parallel do so very badly, sometimes it works and there are some tricks that allow it to work in some other cases, but there are still a broad range of problems where no parallel algorithm exists.

Putting this into concrete terms for audio:

Multiple soft synths all of which only output audio : potentially easy parallelism there, each instrument is not dependent on the state of any other. Channel strips can be similar but only as long as no insert connections exist between strips, adding something like a compressor side-chained to another strip and it gets hairy again. This is not quite the same thing as saying that establishing that those synths CAN be scheduled successfully is necessarily possible.

Multiple soft synths where the output of one is patched into the input on another : Hard problem, which can be solved only by either introducing some latency so both have data in parallel, or by cleverly breaking a periods worth of samples down into a few smaller blocks so that as soon as the first synth has finished one sub block, the second one can start work on that one while the first works on the next sub unit. Trouble is, with latencies below about 128 - 256 samples, the inefficiencies resulting from processing very small blocks (16 samples or so) tend to outweigh the advantages.

Then there is the problem caused by the fact that the processors are NOT really independent, main memory bandwidth is shared (usually), main memory is sometimes throttled for thermal reasons, SMI events can make a core (or even all cores) just go away from under you for an arbitrary time, any core doing a TLB flush causes stalls, as does contention on a cache line, as does the "lock" prefix on an instruction, graphics drivers are notorious for causing PCI bus stalls while massive DMA transfers run, the PC (And I include macs in that) is a horrid environment for running anything with short deadlines....

General purpose machines are horrible environments to try to do anything with critical timing constraints at the ms level, and I am frankly surprised that it works as well as it does (Which is to say most of the time).

Regards, Dan.

--------------------
Audiophiles use phono leads because they are unbalanced people!

I've often wondered that - it's a wonder they work at all considering we have record, playback, fx and soft sampler/synths all going at once!