600 bands a year shoved down your throat,
but each of them with some moderate chance
of being able to make a living from their
music if people like it.
100,000 bands available on a P2P network, with
almost no chance of making a living because
there are no effective social networks in
place to allow discovery to take place.
i'd much rather have (b), but neither you nor
anyone else has made any serious suggestions
how the discovery process is going to work.
mp3.com already has tens of thousands of bands
listed - no mechanism exists for me to decide
if i like any of them. the main mechanism i use these days is to listen to echoes (echoes.org) and check out the echoes website. what mechanism exists to get stuff "released" over p2p into
the "forums" or "contexts" where i'll believe
its even worth me trying a listening session?
i can't disagree with your characterization of the radio business, but almost nobody does! defining the radio business like this isn't the issue - finding a workable alternative to the way it currently works is. and frankly, all the alternatives i've seen (including one that i set up (Equal Area)) have the implication that the vast majority of musicians that don't draw large crowds to live performances can forget about making a living.
so what's the business model you suggest to
replace it? the current model has the attractive property that it allows WB and others to speculate on bands because of the subsidy offered by the successfull ones. are you suggesting that web-based distribution can remove the need for this subsidy?
the skipping in your mp3 player has nothing to
do with disk i/o. it has to do with scheduling latency. that is, unless your mp3 player has been poorly designed, which many of them have been.
also, 2.5/2.6 is still missing the better patches
for low latency (from andrew morton), and so its performance is still not as good as it could be.
2.6 doesn't beat windows at audio latency when using WDM drivers for windows. it (along with 2.2 and 2.4) beat windows with MME drivers. the WDM audio driver model is very fast, and windows has always done a better job of handling scheduling latency than linux (other than with andrew's patches). in 2.4 there are still places in a mainstream kernel that will stall the entire box for up to 1/10 second.
whatever the record company is making from
the sale of a CD, you can be sure that only
a very small fraction of its costs are related
to producing the CD itself. marketing, office staff, physical distribution, office costs, studio time,
lost money on flops,... the list goes on.
i'm not justifying any particular price for a CD, but demanding that because a CD is cheap to make means that recorded music sold in CD format should be sold for very little is incredibly naive. the price of the product is not just the price of making the final disc.
i'm also curious at the level of complaint about this particular consumer item, when exactly the same concerns and cost/price relationship exists for most other things that we buy, particularly clothes. i don't hear many people (especially on slashdot) talking this way about t-shirts and shoes, which cost very, very little to make but sell for at least as much as a CD.
This requires closed source software. You cannot have open source software restrict the rights of the user, that is the whole point of open source.
actually, no. you can have open source software, you just can't compile and run it yourself. the binary has to be signed by the appropriate authority. this is what is so insidious about palladium. it doesn't stop open source software from existing, it just makes it useless.
DXi: its crap because its API is clearly cobbled together on an as-needed basis. it doesn't represent any attempt to think about what a plugin API needs to look like - its just the usual case of a Microsoft API to which a new feature is added every time someone finds something missing in the old one.
There's nothing wrong with incremental development, but the starting point needs to show some sign of
intention and insight. People used to existing plugin APIs like VST, TDM etc. all make the same comments about DXi. DXi has been successful for the same reason that Office has: its on the machine.
As far as I know, neither Steinberg nor Emagic support DXi. You can use DXi plugins via an adaptor such as the one FXpansion sells.
Yes, I know how many people beat up ProTools because it was audio only. It still went on to rule the industry. Give Ardour some time, and we'll see what happens. The program hasn't even reached v1.0 yet, has managed to get the state claimed to take many man-years of development with about 3, and a first response is "it doesn't support MIDI yet!". what can i offer you that will encourage you?
If you think my responses are "defensive, knee-jerks", then you should read some of the stuff on the ProTools and Nuendo web sites. I'm relaying to you the perspective of people who work on the software side of the DAW world. You, as a user or potential user, don't like what we have to say. That's OK, but that doesn't make us defensive. DXi is a bunch of crap and most audio developers agree; VST is encumbered by a license that makes it hard to use with GPL'ed software. ProTools was audio only. I am being defensive, or do you not like the facts?
Documentation may, nor may not, form part of
the strategy for generating revenue with Ardour, just as it does with Blender (the online Blender manuals are basically inadequate - as this/. thread notes, you really need to buy the book for $50).
if this irritates you, consider that i've spent $35K or more on studio infrastructure to support the development of Ardour, and worked full time without pay on it for about three years. if you can come up with better schemes for generating a revenue stream from my work (other than prebuilt systems), please let me know.
some kind of manual will probably appear online in the future, but right now we are still debating exactly which internal objects to expose in the UI, and so it would be a bit premature to go and write a full manual.
i just read your comments on kuro5hin. they're a little off-base. first of all, i suspect you've never used protools, which is the dominant tool in the commercial studio world. protools has a pretty decent manual which the ardour README points to as a way to get started with the
concepts if nothing else. but the concepts in protools are not that close to those in soundfile editors and trackers. if thats the way you expect
a DAW to work, you're ignoring 8-10 years of history and development of these programs and the experience of studio users.
Support will start at $5K/year. For that, you will get dedicated 24/7 service from a set of the developers, accessed via a single number. you will have to run ardour on a system we build for you; if you run it on your own system, support will cost more. if this bothers you, consider that protools for windows is certified for only a single intel-based system, built and sold by IBM. run it on any other system, and there is NO support available.
let me know when you want to sign the contract. i suggest you at least wait till version 1.0 comes out, but don't let that stop you.
read the README for reasons why there is no
VST support. i have written VST support. DXi
is a bunch of crap. We already have at least
one commercial audio plugin company interested
in native support.
ProTools did not support MIDI when it
first came out. MIDI capture/sequencing is planned and has
been part of the design from the start. I'd
also like to point to the iZ RADAR as an
example of an expensive DAW system that
doesn't handle MIDI at all.
Who says there is no 24/7 support available?
Anyway, given that it hasn't even reached v1.0 at this time, no its not yet ready for general professional use. But it will be. Some studio users are experimenting with it already, however.
3 years of full-time unpaid labor, funded by income from
amazon.com, tested in a commercial recording studio,
aimed squarely at the high end market with low
end costs.
its massive, its complex, its very very very hard
for a novice to build, its only available from CVS at this time. do you think it will get better? you'd better believe it! package releases coming up within 6 weeks, v1.0 hopefully within 12 weeks.
scenario: a really complex threads package designed to work with Scheduler Activations under Mach. the thread context switch code has to
function more like a full kernel-level context
switch than a regular user-space one. i can't find my x86 handbook, and i conclude that some of the processor flags don't need restoring.
next thing i know, we get bugs like:
c = 0;
if (c != 0) then...
the test would fail. gdb would report that the memory location and the register containing the value of c was zero. but the test would fail.
eventually, i realized that the processor flags
i had skipped were the flags for conditional
tests, and yes, they did need to be restored.
as usual with these things, it seems so obvious in hindsight. but imagine how bizarre it is to have gdb tell you that the register contains the correct value and then discover that the test failed, apparently impossibly...
well, i'm a moderator today, so i could either
mod this down to "troll", or...
he refuses to supply tarballs because he
doesn't think the source is close enough to a
stable state that this distribution format makes sense. he (i) has never claimed that the program
is ready for users yet.
he also thinks that the majority of linux users, who use distros, are wrong and everyone should install Linux from scratch. I have NEVER said this, and I don't think it.
My own system started as RH5.2, but I don't
attempt to track RH or any other distribution
myself these days. That doesn't mean you
shouldn't. Ardour installs (from CVS) on several
current distributions without problems.
the only users he wants are those who will pay him for the priviledge of installing Ardour on custom hardware. Its true that having spent more than 2 years of my life working more or less fulltime without pay on Ardour that I would like to receive some financial compensation for it. But it is released under the GPL, and always will be.
have given up any hope of a stable documented and user-friendly application... its a good thing i don't see things this way.
By targetting the GPL, Microsoft has made it clear that they want to be able to take our work without any obligations whatsoever. They want to steal our work. A year ago, this would have been an absurd thing to say, but their new zeal for GPL-bashing makes it a workable slogan. We should be saying
to this everyone we can!
Except that in addition to selling it, you have to offer it for free, too.
this simply isn't true. whenever you distribute GPL'ed software, you must offer the source code as well. you can charge whatever you want for the
software, but either way, it must include
the possibility of getting the source. you are not giving the source away for free, you are giving the source code along with the executable, and you are free to charge for that if you want to.
the only difficulty arises because anyone you sell to can undercut your own price, creating a natural price point of zero, unless you believe in the
natural good of humanity.
you've clearly never tried to do anything
complex in real time in the audio software realm.
the model of "all data is a stream of bytes" and "we can hook it all together with pipes" misses one
critical dimension: time. the unix model of
interacting processes doesn't take time into account in any way, and as a result it fails to be useful for realtime manipulation of large streaming data sets.
Hear, hear... Your 'chair' metaphore is bang on. I'm no rabid capitalist, but if ever come up with something really innovative software-wise, it will be mine to share in whatever manner I choose. Give it away, sell it, whatever.
can we assume that if you write a book, you will reserve the right to prevent us from lending it to our friends? your attitude doesn't take into account that a product whose representation as a set of bits has some important qualitative differences with one that can only be represented by physical matter. as many have quoted, "trying to make bits uncopyable is like trying to make water not wet". your desire to give your software away in the manner you choose appears to overlook the fact that what you are giving away is quite different from a chair (or even a book, for that matter).
The software business would not go away, it would just be different.
Different how? Details! Tell me HOW I WILL GET PAID!
You could and go to work for a company that needs software to do something that has never been done before. They will pay you to do that work. If they never sell it to anybody else, RMS's ideas about the GPL are completely beside the point.
You're only in trouble if you work for a company whose primary business is selling existing software.
Re:Serial ATA could REALLY cut into SCSI sales
on
Serial ATA Coming
·
· Score: 3, Interesting
Third, Serial ATA--unlike SCSI--doesn't require you to load device drivers out of the wazoo to support devices on the bus. The only driver you'll probably need is the driver for the motherboard chipset that incorporates Serial ATA support.
this is an OS design issue. you don't have to do this with Linux. there is a single SCSI driver, based on the identity of your SCSI controller. All other SCSI devices attached to the bus are accessed using this driver. this has never really been true under Windows or MacOS, but it has nothing to do with SCSI itself, just the rather silly way developers of and for those platforms have gone about creating the driver architecture.
a brief clarification. Csound has source code available, but does not meet anyone's definition of "open source" except perhaps a few corporations trying to abuse the term. You are not permitted to redistribute the source, nor to use it for anything except educational and research purposes. Not that this has stopped lots of cool things from happening with Csound, but it pays to understand licenses, sometimes.
its still a cool program, at least for users
First of all, the focus of the article was indeed multimedia, from the
point of view of the average person who wants to use Linux to watch
DVDs and videos off the net.
if "multimedia framework for linux" has come to mean "a system
designed for and limited to consumer usage", then that's fine. i
consider that a useful system, but an inadequate one at the same
time. i think its possible to do better.
GStreamer is indeed an infrastructure for building multimedia
apps. Absolutely everything it does is under the auspices of the
elements that it loads and connects together. Claiming that GStreamer
has no means of inter-application communication is false, as there are
already numerous elements both for communication with sound servers
and other applications (network source/sinks, etc.). A set of Jack
elements are being written, as well.
such connections are not first class citizens in GStreamer's
world. you are not using GStreamer to connect apps, you are using a
GStreamer element that may obey GStreamer's semantics and design, but
operates via a wholly different mechanism than the connections between
GStreamer elements. the fact that GStreamer can talk to JACK, for
example, isn't as notable as the fact that unless one of them drives
the other, the two systems on each of the interconnect are not running
synchronously with each other. this discussion has all been played on
both LAD and jackit-devel. AFAIK, GStreamer does not currently allow
elements to drive its graph execution in the most fundamental sense.
GStreamer also has nothing to do with the GUI whatsoever. Elements are
GObjects that have no GUI in them at all, they focus on doing what
they're supposed to. Any GUI exists as a seperate entity on top of the
processing pipeline as managed by GStreamer.
my point was that if decide to write a really cool software audio
"device", its likely that part of my "device" will be a really cool
(G)UI too. if i write my device as a GStreamer element, then given
that my element will execute in the process context of the GStreamer
app that loads the element, what do i write the (G)UI with? this is
right back to the issues we've discussed on LAD for ever about the
incompatibilities of different GUI toolkits.
As for whether to sync to audio or video, you actually have it quite
backwards. First of all, the most difficult situation is not with
progressive video, but with field-based video (which both NTSC and PAL
are, BTW), where the vertical rates are 50 or 59.95Hz. Compare this to
as i understand it, they are refresh rates, not frame rates. frame
rates are lower than that. i may have this wrong - most of my
understanding of video refresh/frame rates comes from protools, which
is probably not the best place to start.
As for the "content" business somehow making video more important than
audio, you're ignoring the fact that video *is* more important than
audio when both are present together in the same stream. There are
several order of magnitude more bits in the video than than the audio,
anyway.
it depends on the work in question. there are some things for which
the audio is vastly more significant, other things where the video is,
and many where it can be hard to tell. i would agree you that for most
"video" its obviously the video that dominates. if you want a great
framework for video playback, then call it that, not "multimedia"
which has broader connotations.
1) 90+% of computers have sound cards with clocks that can be best
described as "kinda sorta correct".
There are (at least) two versions of "kinda sorta correct":
runs with low jitter, but absolute frequency is wrong
absolute frequency is correct, but jitter is poor
In the first case, there's not much we can do: the clock just isn't
really suitable for use. In the second case, the much greater
resolution/frequency of the audio clock means that we can have fairly
high jitter and not really affect the video refresh timing we generate
from it.
2) The quanta of video playout is much greater than that of audio, on
the order of 500+ times larger. The goal of any good video playback is
to synchronize the playout of a video frame (theoretical time unit) to
a vertical refresh (physical time unit). If at any point those become
desynchronized, you will have a discontinuity of at least one vertical
retrace, or on average about one 75th of a second. Specifically,
you'll have a video frame that is suddently displayed for between 50%
and 100% longer than it's supposed to be, in the middle of a bunch of
correct frames. This is *blatantly* noticable by anyone with a normal
visual cortex.
this isn't really the point. the idea of audio/video sync, as billy
pointed out before, is to decide which video frame should be blitted
at a given audio frame time. none of this has to interfere with the
video refresh rate. its just a matter of picking the correct frame
every time you do the refresh. no more or less, i think. you're going
to only ever either duplicate or drop a single video frame.
Audio, and the human ear, is much more forgiving. If the program
simply drops or duplicates a sample every once in a while to maintain
if only that was it. however, the video clock is updated at a very low
rate - you can only notice out-of-syncness 20-50 times a second, which
means that you will need to drop a lot more than a sample every second
or so to correct for drift unless you actually resample the audio.
So the decision is between locking to a highly variable audio clock
(think 3.6 seconds per hour per 0.1% off) and having video that jerks
the entire point of synchronization is that it doesn't matter
what's going on with the clock - all the slaves follow the clock. if
the audio is a little on the slow side, so is the video. and the video
doesn't have to jerk for reasons described above.
and sputters whenever the theoretical and physical frame times
disagree, or doing some resampling to the audio where necessary, with
the possibility of some loss of quality that is undetectable by 99% of
people watching videos on their computer with tinny speakers.
i don't want to see linux, an operating system with great promise in
this area, end up with a consumer-oriented multimedia API, when one
suitable for professional use will also serve consumers well.
Me, I don't like video-induced headaches, I'll resample the audio.
its a fair point. it would be a better point, i think, if video
induced headaches were inevitable from having the video follow the
audio. i don't think they are.
the slashdot headline is more accurate than the article's actual title. the author's approach comes almost entirely from a consideration of video. if he was starting from a primary interest in audio, he would have talked about many different issues, and mentioned different kinds of solutions.
gstreamer is a cool system, but it needs to be stressed over and over that gstreamer is an architecture for building applications. it does not offer any mechanisms for inter-application communication or synchronization. since most people want to do a lot more than write a particular plugin for gstreamer, gstreamer doesn't help us when the challenge is not providing an architecture for a single program, but one for multiple applications on the same (or even networked) system(s). when you want to run a cool video processor along with a really nice FX rack for audio, gstreamer can't help you unless the author of each component had decided to implement his stuff as a gstreamer plugin. since this cramps the GUI style rather considerably, its unlikely that many people will choose to do this.
finally, i would note that although it has become customary to sync audio to video, this actually makes very little sense when the temporal resolution of audio (22000-96000 frames/sec) is vastly greater than video (20-30 frames/sec). its really just an artifact of the way technological development has happened, of who has the most power in the entertainment "content" business, and of the fact that we generally consider visual data more significant than acoustic data. we'd be in much better shape is the conventional approach was to sync a video stream to audio, since we could easily and uniformly take advantage of the much better clock resolution that audio devices provide.
Re:Great... Content Control Features For Creators?
on
Photoshop for OS X
·
· Score: 2
a secure way of distributing electronic media is vital to publishers and authors
suppose i were to convince you that no such system exists? what then?
what makes you believe that such a system does, or could, exist?
Slashdot Mirror
lets restate those choices:
- 600 bands a year shoved down your throat,
but each of them with some moderate chance
of being able to make a living from their
music if people like it.
- 100,000 bands available on a P2P network, with
almost no chance of making a living because
there are no effective social networks in
place to allow discovery to take place.
i'd much rather have (b), but neither you nor anyone else has made any serious suggestions how the discovery process is going to work. mp3.com already has tens of thousands of bands listed - no mechanism exists for me to decide if i like any of them. the main mechanism i use these days is to listen to echoes (echoes.org) and check out the echoes website. what mechanism exists to get stuff "released" over p2p into the "forums" or "contexts" where i'll believe its even worth me trying a listening session?i can't disagree with your characterization of the radio business, but almost nobody does! defining the radio business like this isn't the issue - finding a workable alternative to the way it currently works is. and frankly, all the alternatives i've seen (including one that i set up (Equal Area)) have the implication that the vast majority of musicians that don't draw large crowds to live performances can forget about making a living.
so what's the business model you suggest to replace it? the current model has the attractive property that it allows WB and others to speculate on bands because of the subsidy offered by the successfull ones. are you suggesting that web-based distribution can remove the need for this subsidy?
the skipping in your mp3 player has nothing to do with disk i/o. it has to do with scheduling latency. that is, unless your mp3 player has been poorly designed, which many of them have been.
also, 2.5/2.6 is still missing the better patches for low latency (from andrew morton), and so its performance is still not as good as it could be.
2.6 doesn't beat windows at audio latency when using WDM drivers for windows. it (along with 2.2 and 2.4) beat windows with MME drivers. the WDM audio driver model is very fast, and windows has always done a better job of handling scheduling latency than linux (other than with andrew's patches). in 2.4 there are still places in a mainstream kernel that will stall the entire box for up to 1/10 second.
whatever the record company is making from the sale of a CD, you can be sure that only a very small fraction of its costs are related to producing the CD itself. marketing, office staff, physical distribution, office costs, studio time, lost money on flops, ... the list goes on.
i'm not justifying any particular price for a CD, but demanding that because a CD is cheap to make means that recorded music sold in CD format should be sold for very little is incredibly naive. the price of the product is not just the price of making the final disc.
i'm also curious at the level of complaint about this particular consumer item, when exactly the same concerns and cost/price relationship exists for most other things that we buy, particularly clothes. i don't hear many people (especially on slashdot) talking this way about t-shirts and shoes, which cost very, very little to make but sell for at least as much as a CD.actually, no. you can have open source software, you just can't compile and run it yourself. the binary has to be signed by the appropriate authority. this is what is so insidious about palladium. it doesn't stop open source software from existing, it just makes it useless.
As far as I know, neither Steinberg nor Emagic support DXi. You can use DXi plugins via an adaptor such as the one FXpansion sells.
Yes, I know how many people beat up ProTools because it was audio only. It still went on to rule the industry. Give Ardour some time, and we'll see what happens. The program hasn't even reached v1.0 yet, has managed to get the state claimed to take many man-years of development with about 3, and a first response is "it doesn't support MIDI yet!". what can i offer you that will encourage you?
If you think my responses are "defensive, knee-jerks", then you should read some of the stuff on the ProTools and Nuendo web sites. I'm relaying to you the perspective of people who work on the software side of the DAW world. You, as a user or potential user, don't like what we have to say. That's OK, but that doesn't make us defensive. DXi is a bunch of crap and most audio developers agree; VST is encumbered by a license that makes it hard to use with GPL'ed software. ProTools was audio only. I am being defensive, or do you not like the facts?
Documentation may, nor may not, form part of the strategy for generating revenue with Ardour, just as it does with Blender (the online Blender manuals are basically inadequate - as this /. thread notes, you really need to buy the book for $50).
if this irritates you, consider that i've spent $35K or more on studio infrastructure to support the development of Ardour, and worked full time without pay on it for about three years. if you can come up with better schemes for generating a revenue stream from my work (other than prebuilt systems), please let me know.
some kind of manual will probably appear online in the future, but right now we are still debating exactly which internal objects to expose in the UI, and so it would be a bit premature to go and write a full manual.
i just read your comments on kuro5hin. they're a little off-base. first of all, i suspect you've never used protools, which is the dominant tool in the commercial studio world. protools has a pretty decent manual which the ardour README points to as a way to get started with the concepts if nothing else. but the concepts in protools are not that close to those in soundfile editors and trackers. if thats the way you expect a DAW to work, you're ignoring 8-10 years of history and development of these programs and the experience of studio users.
Support will start at $5K/year. For that, you will get dedicated 24/7 service from a set of the developers, accessed via a single number. you will have to run ardour on a system we build for you; if you run it on your own system, support will cost more. if this bothers you, consider that protools for windows is certified for only a single intel-based system, built and sold by IBM. run it on any other system, and there is NO support available.
let me know when you want to sign the contract. i suggest you at least wait till version 1.0 comes out, but don't let that stop you.
Anyway, given that it hasn't even reached v1.0 at this time, no its not yet ready for general professional use. But it will be. Some studio users are experimenting with it already, however.
yes, and in fact the OSS community (in this case, myself and a small handful of others) already do!
ardour is my own contribution to this issue.
3 years of full-time unpaid labor, funded by income from amazon.com, tested in a commercial recording studio, aimed squarely at the high end market with low end costs.
its massive, its complex, its very very very hard for a novice to build, its only available from CVS at this time. do you think it will get better? you'd better believe it! package releases coming up within 6 weeks, v1.0 hopefully within 12 weeks.
well, i'm a moderator today, so i could either mod this down to "troll", or ...
he refuses to supply tarballs because he
doesn't think the source is close enough to a
stable state that this distribution format makes sense. he (i) has never claimed that the program
is ready for users yet.
he also thinks that the majority of linux users, who use distros, are wrong and everyone should install Linux from scratch. I have NEVER said this, and I don't think it.
My own system started as RH5.2, but I don't
attempt to track RH or any other distribution
myself these days. That doesn't mean you
shouldn't. Ardour installs (from CVS) on several
current distributions without problems.
the only users he wants are those who will pay him for the priviledge of installing Ardour on custom hardware. Its true that having spent more than 2 years of my life working more or less fulltime without pay on Ardour that I would like to receive some financial compensation for it. But it is released under the GPL, and always will be.
have given up any hope of a stable documented and user-friendly application ... its a good thing i don't see things this way.
absolutely fair point. i apologize for my misreading. if i could retract the post, i would.
DEC did not buy up AltaVista - they wrote it themselves. Sheesh, is history that recent vanishing into the dust of the collective memory already?
By targetting the GPL, Microsoft has made it clear that they want to be able to take our work without any obligations whatsoever. They want to steal our work. A year ago, this would have been an absurd thing to say, but their new zeal for GPL-bashing makes it a workable slogan. We should be saying to this everyone we can!
Except that in addition to selling it, you have to offer it for free, too. this simply isn't true. whenever you distribute GPL'ed software, you must offer the source code as well. you can charge whatever you want for the software, but either way, it must include the possibility of getting the source. you are not giving the source away for free, you are giving the source code along with the executable, and you are free to charge for that if you want to. the only difficulty arises because anyone you sell to can undercut your own price, creating a natural price point of zero, unless you believe in the natural good of humanity.
you've clearly never tried to do anything complex in real time in the audio software realm. the model of "all data is a stream of bytes" and "we can hook it all together with pipes" misses one critical dimension: time. the unix model of interacting processes doesn't take time into account in any way, and as a result it fails to be useful for realtime manipulation of large streaming data sets.
Hear, hear... Your 'chair' metaphore is bang on. I'm no rabid capitalist, but if ever come up with something really innovative software-wise, it will be mine to share in whatever manner I choose. Give it away, sell it, whatever. can we assume that if you write a book, you will reserve the right to prevent us from lending it to our friends? your attitude doesn't take into account that a product whose representation as a set of bits has some important qualitative differences with one that can only be represented by physical matter. as many have quoted, "trying to make bits uncopyable is like trying to make water not wet". your desire to give your software away in the manner you choose appears to overlook the fact that what you are giving away is quite different from a chair (or even a book, for that matter).
The software business would not go away, it would just be different. Different how? Details! Tell me HOW I WILL GET PAID! You could and go to work for a company that needs software to do something that has never been done before. They will pay you to do that work. If they never sell it to anybody else, RMS's ideas about the GPL are completely beside the point. You're only in trouble if you work for a company whose primary business is selling existing software.
Third, Serial ATA--unlike SCSI--doesn't require you to load device drivers out of the wazoo to support devices on the bus. The only driver you'll probably need is the driver for the motherboard chipset that incorporates Serial ATA support. this is an OS design issue. you don't have to do this with Linux. there is a single SCSI driver, based on the identity of your SCSI controller. All other SCSI devices attached to the bus are accessed using this driver. this has never really been true under Windows or MacOS, but it has nothing to do with SCSI itself, just the rather silly way developers of and for those platforms have gone about creating the driver architecture.
a brief clarification. Csound has source code available, but does not meet anyone's definition of "open source" except perhaps a few corporations trying to abuse the term. You are not permitted to redistribute the source, nor to use it for anything except educational and research purposes. Not that this has stopped lots of cool things from happening with Csound, but it pays to understand licenses, sometimes. its still a cool program, at least for users
- runs with low jitter, but absolute frequency is wrong
- absolute frequency is correct, but jitter is poor
In the first case, there's not much we can do: the clock just isn't really suitable for use. In the second case, the much greater resolution/frequency of the audio clock means that we can have fairly high jitter and not really affect the video refresh timing we generate from it. 2) The quanta of video playout is much greater than that of audio, on the order of 500+ times larger. The goal of any good video playback is to synchronize the playout of a video frame (theoretical time unit) to a vertical refresh (physical time unit). If at any point those become desynchronized, you will have a discontinuity of at least one vertical retrace, or on average about one 75th of a second. Specifically, you'll have a video frame that is suddently displayed for between 50% and 100% longer than it's supposed to be, in the middle of a bunch of correct frames. This is *blatantly* noticable by anyone with a normal visual cortex. this isn't really the point. the idea of audio/video sync, as billy pointed out before, is to decide which video frame should be blitted at a given audio frame time. none of this has to interfere with the video refresh rate. its just a matter of picking the correct frame every time you do the refresh. no more or less, i think. you're going to only ever either duplicate or drop a single video frame. Audio, and the human ear, is much more forgiving. If the program simply drops or duplicates a sample every once in a while to maintain if only that was it. however, the video clock is updated at a very low rate - you can only notice out-of-syncness 20-50 times a second, which means that you will need to drop a lot more than a sample every second or so to correct for drift unless you actually resample the audio. So the decision is between locking to a highly variable audio clock (think 3.6 seconds per hour per 0.1% off) and having video that jerks the entire point of synchronization is that it doesn't matter what's going on with the clock - all the slaves follow the clock. if the audio is a little on the slow side, so is the video. and the video doesn't have to jerk for reasons described above. and sputters whenever the theoretical and physical frame times disagree, or doing some resampling to the audio where necessary, with the possibility of some loss of quality that is undetectable by 99% of people watching videos on their computer with tinny speakers. i don't want to see linux, an operating system with great promise in this area, end up with a consumer-oriented multimedia API, when one suitable for professional use will also serve consumers well. Me, I don't like video-induced headaches, I'll resample the audio. its a fair point. it would be a better point, i think, if video induced headaches were inevitable from having the video follow the audio. i don't think they are.the slashdot headline is more accurate than the article's actual title. the author's approach comes almost entirely from a consideration of video. if he was starting from a primary interest in audio, he would have talked about many different issues, and mentioned different kinds of solutions. gstreamer is a cool system, but it needs to be stressed over and over that gstreamer is an architecture for building applications. it does not offer any mechanisms for inter-application communication or synchronization. since most people want to do a lot more than write a particular plugin for gstreamer, gstreamer doesn't help us when the challenge is not providing an architecture for a single program, but one for multiple applications on the same (or even networked) system(s). when you want to run a cool video processor along with a really nice FX rack for audio, gstreamer can't help you unless the author of each component had decided to implement his stuff as a gstreamer plugin. since this cramps the GUI style rather considerably, its unlikely that many people will choose to do this. finally, i would note that although it has become customary to sync audio to video, this actually makes very little sense when the temporal resolution of audio (22000-96000 frames/sec) is vastly greater than video (20-30 frames/sec). its really just an artifact of the way technological development has happened, of who has the most power in the entertainment "content" business, and of the fact that we generally consider visual data more significant than acoustic data. we'd be in much better shape is the conventional approach was to sync a video stream to audio, since we could easily and uniformly take advantage of the much better clock resolution that audio devices provide.
a secure way of distributing electronic media is vital to publishers and authors suppose i were to convince you that no such system exists? what then? what makes you believe that such a system does, or could, exist?