psycho-acoustic compression of audio was really devised as a band-aid for low bandwidth connectivity. its a tragedy that in 10 years time, when storage costs (disk + memory) and bandwidth have changed so dramatically as to render such compression as archaic, we will still have a couple of generations thinking that its the de facto standard for storing music on digital media. sigh. double sigh. triple sigh.
You know just enough about this topic to be dangerous, but not enough to be right. I don't of any serious, informed audio professionals who would even bother to mention DSD in this context - its not discredited, just forgotten. Your comments on double blind testing is the usual apologist side-tracking that the "audiophile" community offers in response to such tests demonstrating no discernible differences. I was suprised that you missed out the part about how "golden ears" still count even if 99% of the rest of the population don't fit such a profile. Your comments on 192/24 completely ignore two very salient facts: (a) the improvement comes mostly from using 24 bit samples instead of 16 bits (b) almost all of the tiny benefit of a 192kHz sample rate comes from the
brickwall filter design that is enabled by this higher rate BUT almost all of that benefit exists at 96kHz and there are still no double blind tests that show people able to differentiate 96/24 from 48/24.
prior art exceedingly likely, except .....
on
Music From DNA Patented
·
· Score: 4, Informative
i graduated with a bachelors in molecular biology & biochemistry in 1981. i had already read papers by that time which described audio/musical transcriptions of DNA, RNA and protein sequences specifically designed to take advantage of the greater perceptual bandwidth of the auditory system vs. the visual system.
the one thing that might be novel here (i don't have time to read a patent abstract at present) is if they have found some way to generate musically meaningful compositions that go beyond a simple (chemical unit) => (musical note) mapping. that could enhance the ability of the auditory system to recognize patterns in sequences, and might be worthy of a patent.
/. readers don't read Windows/OSX music forums
on
Linux as A Musician's OS?
·
· Score: 2, Insightful
Its clear from listening to the multitude of anecdotal, ignorant, out of date, always wrong, partially wrong and flat out whining comments that the posters here don't read Windows/OSX music forums (product specific and otherwise).
Is it really hard to get pro-audio working on Linux? Sometimes, yes. Sometimes, its basically impossible. Is it really hard to get pro-audio working on Windows? Sometimes yes. Forums are full of people for whom stuff just didn't work. Is it hard on OS X? Well, easier than Windows or Linux, for sure, but there's still a rich supply of problem cases on the product and general forums (e.g. gearslutz.com) many of which are replicated by the more substantive criticisms here.
It is frankly amazing that a community like Slashdot, which frequently yields many interesting technical insights and ideas (at least if you browse at +3), is so predictably ignorant when it comes to commenting on audio software on Linux. Every time Slashdot runs a story on this topic, the same stupid ignorant out of date and often simply wrong comments surface. And invariably, there are only a couple of people around to correct the nonsense. If there was a post on/. that criticized the kernel or Firefox or Apache or Python in the same inane and utterly ridiculous ways that people criticize audio stuff, there would be a flood of informed, witty, and incisive corrections to the point that frequently the original post is lost. But not audio... with this stuff, the ignorant get rated +5, the experienced post comments that receive little attention, and the misinformation continues to spread. Sigh.
its too bad that/. is still full of posters who manage to sound authoritative yet actually don't know anywhere near enough about the subject of their posts.
re: Ardour & MIDI: first, Ardour has support MTC and MMC along with MIDI CC for parameter control, for years, and these are the standards associated with "binding it all together. second, see http://ardour.org/node/855
second, re ALSA, MIDI & JACK: if you were following JACK development, you'd know that JACK supports inter-app distribution of MIDI now, and more and more apps are starting to support its use.
as for "a MODERN and powerful graphic interface", i think you've crossed over into the realm of the subjective. there are some very cool VST plugins, for example, whose GUI looks like a crayola version of an early 1990's X10 interface. what you consider "MODERN and powerful" is considered by some other people to be instrusive and ugly.
since about 2.6.18, the default kernel build is capable of supporting relatively low latencies for SCHED_FIFO tasks. Ingo's RT patch still takes the cake (on the right hardware, sub-msec latencies with almost hard real time reliability), and more and more of his RT patch makes it into the mainline kernel with each passing month or two.
Many of us would prefer to work on open-source projects if we could get paid a fair salary to do so (I certainly would). It wouldn't even need to match what I can get from any one of the companies listed. But it *would* need to be enough to pay my cost of living and allow me to put some cash in the bank...
dude, join the back of the queue! do you have any idea how many of the mentors that SoC2007 participants will be working with would love to find a way to fulfill what you've just described? finding a way to work and live from work on open source projects is high on a large number of developer's goals, but the vast majority of these projects do not make much, if any money. the ones that enable Red Hat and others to sell Linux - well divide up RH's profits among all those that could be said to contribute, and there isn't a lot to go around. The ones that make google, amazon etc. possible on an infrastructure level clearly leverage more financial return but hey, guess what? They've been around for a while, and there are others far more deserving than you or I of any living based on their financials.
In short: open source software development in the US doesn't really make a whole lot of sense anymore. Its not impossible, but its hard.
As an end-user why can't I extend applications by simply dragging and dropping features from one application to another? i.e. Dragging a search box from one app to another.
Could it be that the semantics of such an operation are so poorly defined, and so hard to define, that actually implementing something like this is close to pointless? What would it mean even in the single case you mentioned?
I have 1000s of photographs. How can these images be automatically categorized and displayed most effectively without having to manually add meta-data. It should be sorting images by looking at similarities between pictures, date taken and other automatically generated information.
I have 1000s of mp3s. How can these songs be automatically categorized by mood, tempo, etc without manually entering in meta-data? Think of it as Pandora with your own music collection.
Could it be that these are tasks that we actually don't know how to do yet, because they represent something beyond the frontier of our understanding of human intelligence and cognition? Pandora, for example, is fun and useful, but its fun and useful because thousands of people are effectively applying their own human judgement to the system. The computer is merely a data manager. And note that Pandora doesn't classify by mood, tempo etc., it classifies by "lots of other people who like this also like that" - associative classification, not content classification.
The Bush Administration is still the administration. Congress has very little control over the day to day actions of political appointees like the Vet Chief of the FDA who appears to be masterminding this unbelievably stupid action. They could call him in for a question and answer session, but given the insanity that the administration has and continues to bring us ov er the last 7 years, its hard to know where they should even start. I guess since we're all God's Children (those of us who are reborn, anyway), God will just take care of the details once the effectivness of even last-line antibiotics starts to fade.
"configured for realtime-lsm operation, lacking only Ingo's patches that aren't available in the standard kernel"
(1) realtime-lsm doesn't do anything performance related at all. It is an old solution to a permissions problem, namely allowing non-root users to run threads in the SCHED_FIFO scheduling class and allowing them to use mlock() to pin memory in physical RAM. how well a SCHED_FIFO thread performs is 100% orthogonal to the existence of realtime-lsm. it is also now a deprecated solution for 2.6 kernels, which support a LKML approved mechanism for granting these permissions that has finally made it up into user space for most distributions.
(2) nobody has ever claimed that a non-patched kernel can be used to get xrun-free behaviour. what is true is that recent 2.6 kernels have becomes good enough (mostly through including parts of Ingo's work) that with larger latencies most users will get acceptable behaviour whereas they used to get terrible behaviour. If you want to either go lower or get guaranteed behaviour or both, you *must* have Ingo's patches installed. We are not going to redesign JACK for a kernel that is acknowledged by its authors to be incorrectly implemented for JACK's purpose. Ingo's patches solve 99% of the mis-design and thus represent a kernel suitable for low latency, critical audio work. the standard kernel is not likely to ever do this, although we can always dream.
Objective measurements exist as part of Ingo's patches. The reason that using them cannot really solve this issue is that what is being measured is reflection of the system hardware, kernel build and occasionally user-space configuration. People have built systems that *never* fail to meet Ingo's goal. Contrarily, there are many systems that almost never fail to meet them, and many systems where even with his patches, kernel time delays occur too often. So what is one to make of this? I certainly do not conclude that the solution is to modify the design of JACK to incur more CPU overhead in the common case.
Most people do not understand what Ingo's patches actually do. They actually transform "Unix" into a hard-RT-like OS by effectively threading all interrupt handlers. Modulo errors in the scheduler, *nothing* except the lowest level IRQ ack to the APIC, can interrupt code that should be executing. It doesn't matter what other activity is happening on the machine - if the highest priority interrupts (e.g. audio and the system timer) are raised, then *that* code path executes no matter what and cannot be interrupted by other things. Coupled with correct handling of the related SCHED_FIFO tasks from user space and you basically have a system that isn't remotely "Unix" like at all, even though the regular Unix-like system is running next to it. Effectively Ingo has implemented the design of several hard-realtime operating systems.
Its a real question whether a system that was targetted at pro-audio, not consumer use, should be designed to work a wide range of machinery at all. Your comment: "I see only small-block time faults, and not failures to meet the hard realtime constraint at the end of the latency period" makes no sense to me at all. You cannot "see" small-block time faults. There are deadlines, and the required code either executes within the deadline, or not.
I'm not going to continue to discuss this here because its an inconvenient medium. If you want to talk about it more, use the JACK mailing list or find me on IRC. I suspect I know your nick already, and you can find me in #ardour most of the time.
This is all wrong. It takes A(nframes) + B cycles to process nframes of audio. This is an invariant, unrelated to period size or count (although period size may affect B). The only things that can really change A(nframes) + B are:
branch performance. an issue, but not a big one.
CPU cycle stealing by the kernel scheduling the task off the processor and back on, thus making the wallclock
time to process nframes longer than the number of cycles used to do it.
If you were slow on one of the blocks, perhaps you could make up for it in a later block by applying CPU muscle. But this just a band-aid over the problem. You should never have been slow in the first place.
Its not the job of application design to come up with band-aids around OS deficiencies, most of the time. The basic model of what is happening with audio i/o has already been made perfectly clear in this thread: every M msecs, you have to process N frames of audio. If the kernel is butting in and making that hard to do reliably, then its the kernel that need fixing. Your proposal that JACK subdivides the period so that if the kernel messed with us on sub-period 1, we somehow make it up while processing sub-periods 2-n is really just saying "use more CPU cycles in the hope that it might just work out". Its a false hope, IMHO.
The reality is that the app code has to be RT-safe, and the kernel has to get the hell out of the way. A deficiency in either one can't be solved by the other.
You apparently don't understand that realtime audio software has to be... well, realtime. The simplest definition of what that means for audio processing is:
T(nframes) = A(nframes) + B
that is: the time it takes to process nframes of audio is a linear function of nframes plus a constant.
As a result "applying more CPU muscle" is irrelevant because the time per nframes is essentially fixed. If you missed the deadline the first time (but had "breathing room") there are only two reasons why: either you code is badly written and doesn't meet the condition stated above, or the kernel interrupt you, took processor time away from you, and you were unable to get the job done.
Trying to fix the second situation by dividing the processing of nframes into even smaller chunks just increases processor overhead, and doesn't stand much chance of improving the situation.
Its a little wierd that if its a hobby toy, major mixing desk manufacturers like Solid State Logic, Harrison and others would support the development of the application. Even wierder that Harrison would demo Ardour on one of their latest high digital consoles at the National Association of Broadcasters last year.
As the author of Ardour, I tend to think that its an unreliable, cumbersome, hard to use and flaky piece of crap. And then I either actually get a chance to play with one of the proprietary DAWs in a high end studio or I get email from someone who has used both, and I'm struck by how much that description applies to them all. ProTools took nearly 8 years to add drag-n-drop!
The flexible routing that Ardour has had from its inception still doesn't exist in ProTools or Nuendo, and has been retro-actively added to Sonar and a couple of others as part of a major re-engineering effort.
The main reason to not use Ardour in a pro-audio situation right now has more do with session interchange than anything else, and this is caused by the dominant format (OMF) being controlled by ProTools/Digidesign in a way that makes it very hard for an open source application to offer it. We hope to change that in the next several months. As far as plugin formats go, we'd love to support more than just VST from the commercial world, but you'd have to talk the owners of the plugin APIs about that, since you cannot get docs for RTAS or others for an open source application. For some reason, the audio software world thinks that it is immune to the influence open source has had on operating systems, web servers and services and office software suites. Its a little short-sighted, but then I would say that, wouldn't I?
They say that a little knowledge can be dangerous. You either suffer from this, or you're a genius with an insight that many systems other than JACK should benefit from.
Your comment about what is effectively variable size buffers is either a superb insight, or you just totally missing the point.
Every M msecs, the audio interface expects to get N audio frames delivered to it, and makes available the same number of incoming audio frames. There is no way around this limitation. So the question becomes: is there way to process the N frames to meet the deadline that is more reliable than what JACK currently does?
If there is, it seems remarkable that no other system has implemented it. The overhead of calling the graph associated with the data flow for the frames is not insignificant, even on contemporary processors. Therefore, calling the graph the minimum number of times is of some significance, significance that only grows as the latency is reduced. Because of this, all existing designs, including ASIO and CoreAudio (with the proviso that CoreAudio is *not* driven by the interrupt from the audio interface) call the graph only once for every hardware buffer segment/period/whatever.
You are correctly identifying the major issue with JACK being occasional code paths in the kernel that prevent the graph from executing in time to meet the deadlines. However, I cannot see how adding overhead to processing N frames by executing the graph several times instead of once can possibly help. What we have been doing instead is encouraging and supporting the work of people like Ingo Molnar that get the kernel (and/or a patched kernel) closer and closer to actually being able to offer soft realtime that is close enough to what we need. On most hardware, Ingo's kernels now work phenomenally well, and only errant device drivers are capable of preventing the amazing good guarantee of service the kernel offers SCHED_FIFO tasks.
Paul Davis, Principal architect and author of JACK
if you think this is part of bill and his friends' "last gasps" at power, you've got a long decade or more ahead of you.
furthermore, just who would "our generation" be? or "his generation" for that matter? i'm 43. younger than bill, and i'm guessing older than you. am i the oppressor or the oppressed? you decide...
Ingo Molnar and Andrew Morton's original 2.4 patches for better soft-real-time performance were prompted by complaints from those of us in the linux audio (pro-audio/music) software community. Systems like JACK and applications like Ardour were written around this kind of functionality.
Ingo has picked up the ball and run with it for 2.6 to the point where a kernel patched with his most recent patches is basically hard-time except for cases where a badly written device driver screws it up. And increasingly parts of his work have become part of the vanilla kernel so that even a 2.6 kernel now works pretty well unless you need very low latency (as require for real-time monitoring and FX processing.
a simple google for "budget surplus clinton" makes it clear that by the end of clinton's time in office, the federal government was running an annual surplus. it is true that there was still an overall federal debt, but that's quite a different issue. its also not clear if we can really thank clinton or serendipity for the surplus, but denying it was there is ridiculous.
complaining about underfunding makes sense if you believe that there is massive overfunding of things that should not be high on our priorities list. military spending that exceeds that of the next 6-10 nations combined is the most commonly cited example.
you have to be kidding! you're claiming that the media covered Nader because he could not have won, but Badnarik could have won and so they didn't cover him? they didn't cover Badnarik because even if he was on the ballot in 150 states, he still could not have won. i agree - its a poor reason to avoid covering Badnarik and his party's ideas, but lets get serious about the reasons here.
but the telecommuters do not consume the type of services you're describing, mostly because US labor law sucks so badly when viewed from an employee perspective that its barely worth it. i just don't see much evidence for this claim you are making that telecommuters draw on services from the community in which their remote office is located. any services.
You're completely missing the point. I know the state of Jersey City. I park there most times I drive up to NYC from Philadelphia. What matters is not the absolute level of services offered by a given location, but the services that are utilized by a telecommuter working in a given location that differ from those in any other. I wouldn't choose to live in Jersey City, but if I choose to live in Manhattan, I will pay much more in city taxes to cover the massively increased city amenities I have available. However, if I work in Jersey City (regardless of where I live) the services I use in order to perform my job are essentially indistinguishable from the ones I would use in Manhattan (or any of the 5 boroughs).
Choice of where to live is important, and property and other local taxes will hopefully reflect (to some extent) the (service-centered) benefits of one location over another. But choice of where to work is orthogonal to this - as a telecommuter I need a space, a functional broadband connection and a way to get between that space and my home if they are not one and the same. You cannot be claiming that by writing software in NYC I am using more city services than doing the same job in Jersey City? Clearly, *living* in NYC I would do so, but as I've now said twice, other non-income based taxes reflect that particular reality.
Until Elliot Spitzer showed up, its hard to argue that NY or NYC offered services above or beyond those present in Jersey City on the other side of the Hudson. Telecommuting isn't suitable for positions where people make things using industrial infrastructure as offered by major cities and ports. Telecommuters use networking facilities that were (unfortunately, from many perspectives) built and maintained by private corporations (admittedly under city-granted monopoly conditions). Its hard to argue that a telecommuter who works from her home on 5th Avenue in NYC is using any more or less city/state/federal services for her work than one who works across the water in Hoboken.
Slashdot Mirror
it might even be as successful as the similarly revolutionary Kendall Square Research machine, just down the road from MIT.
i wouldn't hold my breath.
psycho-acoustic compression of audio was really devised as a band-aid for low bandwidth connectivity. its a tragedy that in 10 years time, when storage costs (disk + memory) and bandwidth have changed so dramatically as to render such compression as archaic, we will still have a couple of generations thinking that its the de facto standard for storing music on digital media. sigh. double sigh. triple sigh.
You know just enough about this topic to be dangerous, but not enough to be right. I don't of any serious, informed audio professionals who would even bother to mention DSD in this context - its not discredited, just forgotten. Your comments on double blind testing is the usual apologist side-tracking that the "audiophile" community offers in response to such tests demonstrating no discernible differences. I was suprised that you missed out the part about how "golden ears" still count even if 99% of the rest of the population don't fit such a profile. Your comments on 192/24 completely ignore two very salient facts: (a) the improvement comes mostly from using 24 bit samples instead of 16 bits (b) almost all of the tiny benefit of a 192kHz sample rate comes from the brickwall filter design that is enabled by this higher rate BUT almost all of that benefit exists at 96kHz and there are still no double blind tests that show people able to differentiate 96/24 from 48/24.
i graduated with a bachelors in molecular biology & biochemistry in 1981. i had already read papers by that time which described audio/musical transcriptions of DNA, RNA and protein sequences specifically designed to take advantage of the greater perceptual bandwidth of the auditory system vs. the visual system.
the one thing that might be novel here (i don't have time to read a patent abstract at present) is if they have found some way to generate musically meaningful compositions that go beyond a simple (chemical unit) => (musical note) mapping. that could enhance the ability of the auditory system to recognize patterns in sequences, and might be worthy of a patent.
Its clear from listening to the multitude of anecdotal, ignorant, out of date, always wrong, partially wrong and flat out whining comments that the posters here don't read Windows/OSX music forums (product specific and otherwise).
/. that criticized the kernel or Firefox or Apache or Python in the same inane and utterly ridiculous ways that people criticize audio stuff, there would be a flood of informed, witty, and incisive corrections to the point that frequently the original post is lost. But not audio ... with this stuff, the ignorant get rated +5, the experienced post comments that receive little attention, and the misinformation continues to spread. Sigh.
Is it really hard to get pro-audio working on Linux? Sometimes, yes. Sometimes, its basically impossible. Is it really hard to get pro-audio working on Windows? Sometimes yes. Forums are full of people for whom stuff just didn't work. Is it hard on OS X? Well, easier than Windows or Linux, for sure, but there's still a rich supply of problem cases on the product and general forums (e.g. gearslutz.com) many of which are replicated by the more substantive criticisms here.
It is frankly amazing that a community like Slashdot, which frequently yields many interesting technical insights and ideas (at least if you browse at +3), is so predictably ignorant when it comes to commenting on audio software on Linux. Every time Slashdot runs a story on this topic, the same stupid ignorant out of date and often simply wrong comments surface. And invariably, there are only a couple of people around to correct the nonsense. If there was a post on
Linux and open source is great and all that, but it can not be used for professional sound production
Oh really. Fascinating. How would you explain this then?
its too bad that /. is still full of posters who manage to sound authoritative yet actually don't know anywhere near enough about the subject of their posts.
re: Ardour & MIDI: first, Ardour has support MTC and MMC along with MIDI CC for parameter control, for years, and these are the standards associated with "binding it all together. second, see http://ardour.org/node/855
second, re ALSA, MIDI & JACK: if you were following JACK development, you'd know that JACK supports inter-app distribution of MIDI now, and more and more apps are starting to support its use.
as for "a MODERN and powerful graphic interface", i think you've crossed over into the realm of the subjective. there are some very cool VST plugins, for example, whose GUI looks like a crayola version of an early 1990's X10 interface. what you consider "MODERN and powerful" is considered by some other people to be instrusive and ugly.
since about 2.6.18, the default kernel build is capable of supporting relatively low latencies for SCHED_FIFO tasks. Ingo's RT patch still takes the cake (on the right hardware, sub-msec latencies with almost hard real time reliability), and more and more of his RT patch makes it into the mainline kernel with each passing month or two.
Many of us would prefer to work on open-source projects if we could get paid a fair salary to do so (I certainly would). It wouldn't even need to match what I can get from any one of the companies listed. But it *would* need to be enough to pay my cost of living and allow me to put some cash in the bank ...
dude, join the back of the queue! do you have any idea how many of the mentors that SoC2007 participants will be working with would love to find a way to fulfill what you've just described? finding a way to work and live from work on open source projects is high on a large number of developer's goals, but the vast majority of these projects do not make much, if any money. the ones that enable Red Hat and others to sell Linux - well divide up RH's profits among all those that could be said to contribute, and there isn't a lot to go around. The ones that make google, amazon etc. possible on an infrastructure level clearly leverage more financial return but hey, guess what? They've been around for a while, and there are others far more deserving than you or I of any living based on their financials.
In short: open source software development in the US doesn't really make a whole lot of sense anymore. Its not impossible, but its hard.
As an end-user why can't I extend applications by simply dragging and dropping features from one application to another? i.e. Dragging a search box from one app to another.
Could it be that the semantics of such an operation are so poorly defined, and so hard to define, that actually implementing something like this is close to pointless? What would it mean even in the single case you mentioned?
I have 1000s of photographs. How can these images be automatically categorized and displayed most effectively without having to manually add meta-data. It should be sorting images by looking at similarities between pictures, date taken and other automatically generated information.
Could it be that these are tasks that we actually don't know how to do yet, because they represent something beyond the frontier of our understanding of human intelligence and cognition? Pandora, for example, is fun and useful, but its fun and useful because thousands of people are effectively applying their own human judgement to the system. The computer is merely a data manager. And note that Pandora doesn't classify by mood, tempo etc., it classifies by "lots of other people who like this also like that" - associative classification, not content classification.I have 1000s of mp3s. How can these songs be automatically categorized by mood, tempo, etc without manually entering in meta-data? Think of it as Pandora with your own music collection.
The Bush Administration is still the administration. Congress has very little control over the day to day actions of political appointees like the Vet Chief of the FDA who appears to be masterminding this unbelievably stupid action. They could call him in for a question and answer session, but given the insanity that the administration has and continues to bring us ov er the last 7 years, its hard to know where they should even start. I guess since we're all God's Children (those of us who are reborn, anyway), God will just take care of the details once the effectivness of even last-line antibiotics starts to fade.
"configured for realtime-lsm operation, lacking only Ingo's patches that aren't available in the standard kernel"
(1) realtime-lsm doesn't do anything performance related at all. It is an old solution to a permissions problem, namely allowing non-root users to run threads in the SCHED_FIFO scheduling class and allowing them to use mlock() to pin memory in physical RAM. how well a SCHED_FIFO thread performs is 100% orthogonal to the existence of realtime-lsm. it is also now a deprecated solution for 2.6 kernels, which support a LKML approved mechanism for granting these permissions that has finally made it up into user space for most distributions.
(2) nobody has ever claimed that a non-patched kernel can be used to get xrun-free behaviour. what is true is that recent 2.6 kernels have becomes good enough (mostly through including parts of Ingo's work) that with larger latencies most users will get acceptable behaviour whereas they used to get terrible behaviour. If you want to either go lower or get guaranteed behaviour or both, you *must* have Ingo's patches installed. We are not going to redesign JACK for a kernel that is acknowledged by its authors to be incorrectly implemented for JACK's purpose. Ingo's patches solve 99% of the mis-design and thus represent a kernel suitable for low latency, critical audio work. the standard kernel is not likely to ever do this, although we can always dream.
Objective measurements exist as part of Ingo's patches. The reason that using them cannot really solve this issue is that what is being measured is reflection of the system hardware, kernel build and occasionally user-space configuration. People have built systems that *never* fail to meet Ingo's goal. Contrarily, there are many systems that almost never fail to meet them, and many systems where even with his patches, kernel time delays occur too often. So what is one to make of this? I certainly do not conclude that the solution is to modify the design of JACK to incur more CPU overhead in the common case.
Most people do not understand what Ingo's patches actually do. They actually transform "Unix" into a hard-RT-like OS by effectively threading all interrupt handlers. Modulo errors in the scheduler, *nothing* except the lowest level IRQ ack to the APIC, can interrupt code that should be executing. It doesn't matter what other activity is happening on the machine - if the highest priority interrupts (e.g. audio and the system timer) are raised, then *that* code path executes no matter what and cannot be interrupted by other things. Coupled with correct handling of the related SCHED_FIFO tasks from user space and you basically have a system that isn't remotely "Unix" like at all, even though the regular Unix-like system is running next to it. Effectively Ingo has implemented the design of several hard-realtime operating systems.
Its a real question whether a system that was targetted at pro-audio, not consumer use, should be designed to work a wide range of machinery at all. Your comment: "I see only small-block time faults, and not failures to meet the hard realtime constraint at the end of the latency period" makes no sense to me at all. You cannot "see" small-block time faults. There are deadlines, and the required code either executes within the deadline, or not.
I'm not going to continue to discuss this here because its an inconvenient medium. If you want to talk about it more, use the JACK mailing list or find me on IRC. I suspect I know your nick already, and you can find me in #ardour most of the time.
This is all wrong. It takes A(nframes) + B cycles to process nframes of audio. This is an invariant, unrelated to period size or count (although period size may affect B). The only things that can really change A(nframes) + B are:
If you were slow on one of the blocks, perhaps you could make up for it in a later block by applying CPU muscle. But this just a band-aid over the problem. You should never have been slow in the first place.
Its not the job of application design to come up with band-aids around OS deficiencies, most of the time. The basic model of what is happening with audio i/o has already been made perfectly clear in this thread: every M msecs, you have to process N frames of audio. If the kernel is butting in and making that hard to do reliably, then its the kernel that need fixing. Your proposal that JACK subdivides the period so that if the kernel messed with us on sub-period 1, we somehow make it up while processing sub-periods 2-n is really just saying "use more CPU cycles in the hope that it might just work out". Its a false hope, IMHO.
The reality is that the app code has to be RT-safe, and the kernel has to get the hell out of the way. A deficiency in either one can't be solved by the other.
You apparently don't understand that realtime audio software has to be ... well, realtime. The simplest definition of what that means for audio processing is:
T(nframes) = A(nframes) + B
that is: the time it takes to process nframes of audio is a linear function of nframes plus a constant.
As a result "applying more CPU muscle" is irrelevant because the time per nframes is essentially fixed. If you missed the deadline the first time (but had "breathing room") there are only two reasons why: either you code is badly written and doesn't meet the condition stated above, or the kernel interrupt you, took processor time away from you, and you were unable to get the job done.
Trying to fix the second situation by dividing the processing of nframes into even smaller chunks just increases processor overhead, and doesn't stand much chance of improving the situation.
Its a little wierd that if its a hobby toy, major mixing desk manufacturers like Solid State Logic, Harrison and others would support the development of the application. Even wierder that Harrison would demo Ardour on one of their latest high digital consoles at the National Association of Broadcasters last year.
As the author of Ardour, I tend to think that its an unreliable, cumbersome, hard to use and flaky piece of crap. And then I either actually get a chance to play with one of the proprietary DAWs in a high end studio or I get email from someone who has used both, and I'm struck by how much that description applies to them all. ProTools took nearly 8 years to add drag-n-drop! The flexible routing that Ardour has had from its inception still doesn't exist in ProTools or Nuendo, and has been retro-actively added to Sonar and a couple of others as part of a major re-engineering effort.
The main reason to not use Ardour in a pro-audio situation right now has more do with session interchange than anything else, and this is caused by the dominant format (OMF) being controlled by ProTools/Digidesign in a way that makes it very hard for an open source application to offer it. We hope to change that in the next several months. As far as plugin formats go, we'd love to support more than just VST from the commercial world, but you'd have to talk the owners of the plugin APIs about that, since you cannot get docs for RTAS or others for an open source application. For some reason, the audio software world thinks that it is immune to the influence open source has had on operating systems, web servers and services and office software suites. Its a little short-sighted, but then I would say that, wouldn't I?
They say that a little knowledge can be dangerous. You either suffer from this, or you're a genius with an insight that many systems other than JACK should benefit from.
Your comment about what is effectively variable size buffers is either a superb insight, or you just totally missing the point. Every M msecs, the audio interface expects to get N audio frames delivered to it, and makes available the same number of incoming audio frames. There is no way around this limitation. So the question becomes: is there way to process the N frames to meet the deadline that is more reliable than what JACK currently does?
If there is, it seems remarkable that no other system has implemented it. The overhead of calling the graph associated with the data flow for the frames is not insignificant, even on contemporary processors. Therefore, calling the graph the minimum number of times is of some significance, significance that only grows as the latency is reduced. Because of this, all existing designs, including ASIO and CoreAudio (with the proviso that CoreAudio is *not* driven by the interrupt from the audio interface) call the graph only once for every hardware buffer segment/period/whatever.
You are correctly identifying the major issue with JACK being occasional code paths in the kernel that prevent the graph from executing in time to meet the deadlines. However, I cannot see how adding overhead to processing N frames by executing the graph several times instead of once can possibly help. What we have been doing instead is encouraging and supporting the work of people like Ingo Molnar that get the kernel (and/or a patched kernel) closer and closer to actually being able to offer soft realtime that is close enough to what we need. On most hardware, Ingo's kernels now work phenomenally well, and only errant device drivers are capable of preventing the amazing good guarantee of service the kernel offers SCHED_FIFO tasks.
Paul Davis, Principal architect and author of JACK
if you think this is part of bill and his friends' "last gasps" at power, you've got a long decade or more ahead of you.
...
furthermore, just who would "our generation" be? or "his generation" for that matter? i'm 43. younger than bill, and i'm guessing older than you. am i the oppressor or the oppressed? you decide
once upon a time, this is what the "operating system" was for. sigh.
Ingo Molnar and Andrew Morton's original 2.4 patches for better soft-real-time performance were prompted by complaints from those of us in the linux audio (pro-audio/music) software community. Systems like JACK and applications like Ardour were written around this kind of functionality.
Ingo has picked up the ball and run with it for 2.6 to the point where a kernel patched with his most recent patches is basically hard-time except for cases where a badly written device driver screws it up. And increasingly parts of his work have become part of the vanilla kernel so that even a 2.6 kernel now works pretty well unless you need very low latency (as require for real-time monitoring and FX processing.
a simple google for "budget surplus clinton" makes it clear that by the end of clinton's time in office, the federal government was running an annual surplus. it is true that there was still an overall federal debt, but that's quite a different issue. its also not clear if we can really thank clinton or serendipity for the surplus, but denying it was there is ridiculous.
complaining about underfunding makes sense if you believe that there is massive overfunding of things that should not be high on our priorities list. military spending that exceeds that of the next 6-10 nations combined is the most commonly cited example.
you have to be kidding! you're claiming that the media covered Nader because he could not have won, but Badnarik could have won and so they didn't cover him? they didn't cover Badnarik because even if he was on the ballot in 150 states, he still could not have won. i agree - its a poor reason to avoid covering Badnarik and his party's ideas, but lets get serious about the reasons here.
but the telecommuters do not consume the type of services you're describing, mostly because US labor law sucks so badly when viewed from an employee perspective that its barely worth it. i just don't see much evidence for this claim you are making that telecommuters draw on services from the community in which their remote office is located. any services.
You're completely missing the point. I know the state of Jersey City. I park there most times I drive up to NYC from Philadelphia. What matters is not the absolute level of services offered by a given location, but the services that are utilized by a telecommuter working in a given location that differ from those in any other. I wouldn't choose to live in Jersey City, but if I choose to live in Manhattan, I will pay much more in city taxes to cover the massively increased city amenities I have available. However, if I work in Jersey City (regardless of where I live) the services I use in order to perform my job are essentially indistinguishable from the ones I would use in Manhattan (or any of the 5 boroughs).
Choice of where to live is important, and property and other local taxes will hopefully reflect (to some extent) the (service-centered) benefits of one location over another. But choice of where to work is orthogonal to this - as a telecommuter I need a space, a functional broadband connection and a way to get between that space and my home if they are not one and the same. You cannot be claiming that by writing software in NYC I am using more city services than doing the same job in Jersey City? Clearly, *living* in NYC I would do so, but as I've now said twice, other non-income based taxes reflect that particular reality.
Until Elliot Spitzer showed up, its hard to argue that NY or NYC offered services above or beyond those present in Jersey City on the other side of the Hudson. Telecommuting isn't suitable for positions where people make things using industrial infrastructure as offered by major cities and ports. Telecommuters use networking facilities that were (unfortunately, from many perspectives) built and maintained by private corporations (admittedly under city-granted monopoly conditions). Its hard to argue that a telecommuter who works from her home on 5th Avenue in NYC is using any more or less city/state/federal services for her work than one who works across the water in Hoboken.