Home |
Search |
Today's Posts |
#41
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
thanks for all the insight guys. 64 bit word length would be a "true"
64 bit processor to me. but i'm not half as smart as many people around here. i'm excited about massive amounts of ram, so your drives can stay idle. they even have some cool stuff like you can put a usb mini storage stick into the computer and tell it to be ram. it's not as fast as the dedicated system ram, but i like where the future is headed (more cores, more bits, more based around ram) since i'm in the market for a new computer, as of jan 29, literally overnight, it all changed over to vista. i'm going to get a tablet pc unless i can be convinced otherwise, and that market is now instantly dominated by vista. |
#42
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
Emiliano Grilli wrote:
On 10 Feb, 15:58, "Mogens V." wrote: Thanks. I've cut the excess and kept your pointers for those who might be interested in following them. ALSA is powerful, but complicated to setup if you want to do something different from the default. OTOH, once your soundcard is supported it will work out of the box without installing drivers, and with ANY linux distro. That if you ask me is a _great_ benefit, and a warranty on your hardware purchase. I have soo bad experiences with closed source drivers (namely gadgetlabs wave 824 and opcode studio64) that I won't put my hard-earned money anymore into a peripheral that doesn't have an open source driver. Jack and realtime operation is even more demanding since it needs a patched kernel to achieve the best performance for the lowest latency. That's a minor problem for me, but might be for others, depending on their kernel experiences. Do give me a couple of pointers to the late progression using Linux for a DAW installation, i.e. distro, apps, audio routing deamon et al, and I'll take a fresh look. The most "audio friendly" and up to date debian based distro is 64studio: http://www.64studio.com They have both 64 bit and 32 bit versions. Use qjackctl to control jackd daemon and audio routing. Ardour as DAW. Rosegarden or muse as sequencer (synced via jack_transport), linuxsampler to play GIG files, zynaddsubfx as synth, jamin for mastering, audacity or rezound as audio editors. Need to do audio in batches? Try ecasound, sox, timidity, lame, oggenc, ... Then if you want to go experimental, try csound, puredata, supercollider. Apps are really not as mature as the windows commercial apps, but they do their work fairly well. Ardour has been rock solid for me, and more powerful than I ever needed. LADSPA plugins do not have the eye candy (in fact, they don't have a fixed GUI at all) but some are good sounding, and there are plenty of them. ...snip.. Open formats are one of the main advantages of free software, as you probably know. Ardour uses 32 bit broadcast wave files, and human readable XML for the project file. Moreover, the app is free so everyone can legally install it (it's also available for mac OS X) and use your projects without problems, including effects, automation, and so on. No windows version so far, though. Speaking of other session interchange formats, Paul Davis (ardour's author) said: "We are slowly working on support for AAF, which is about the only standard for session files worth paying attention to (OMF is widespread because of ProTools but its also proprietary and is hard for us to support)." ...snip.. Check http://ardour.org forums. They are plenty of people using ardour... maybe they're not high end professionals, but the community is growing, and the app in my opinion is well worth to keep an eye on. ...snip.. Try 64studio. You might be surprised :-) I'd missed that one. Thanks for all pointers. I'll take a fresh look sometime soon. Need to finish a new server, then my current combined server/workstation will be free for trying it out. -- Kind regards, Mogens V. |
#43
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
"Romeo Rondeau" wrote in message
t And this movie plays itself out every time a new OS is introduced... And it will again, but probably pretty slowly, becasue XP is far more competent than any *obsolete* OS we ever had before. There is a 64 bit flavor of XP on the market, BTW. I'll bet you it plays out exactly like it always has. When folks buy new PC's, they will have Vista on them. Right now they often have a choice. That in itself will take care of it... like it always has. There is nothing different about Vista than other operating systems. Some users will wait a long time, some will stand in line outside the store the night before the launch (like they did this time), it happens every time. Agreed. |
#44
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
wrote in message
wrote: Hello, This is sort of off-topic, but not. I'm in the market for a new computer with Vista. I can't for the life of me figure out if the Intel Core 2 Duo is a true 64 bit processor, a fake one, or nothing at all to do with 32 bit. Define "a true 64 bit processor" 64 bit datapaths? or greater. For example, 32 bit processors with 64 and 128 bit data paths are old hat. 64 bit addressing? An absolute must. But, I'm not sure that anybody has a compelling reason to go further for address space or main memory adressing with a mainstream processor. IPV6 uses 128 bit addresses, but they are something different. 64 bit functional units? or greater. For example, 32 bit processors with 64 and 128 bit functional units are old hat. |
#45
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
Arny Krueger wrote:
"Romeo Rondeau" wrote in message t And this movie plays itself out every time a new OS is introduced... And it will again, but probably pretty slowly, becasue XP is far more competent than any *obsolete* OS we ever had before. There is a 64 bit flavor of XP on the market, BTW. I'll bet you it plays out exactly like it always has. When folks buy new PC's, they will have Vista on them. Right now they often have a choice. It's only been out for a few days... |
#46
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
"Romeo Rondeau" wrote ...
Arny Krueger wrote: "Romeo Rondeau" wrote And this movie plays itself out every time a new OS is introduced... And it will again, but probably pretty slowly, becasue XP is far more competent than any *obsolete* OS we ever had before. There is a 64 bit flavor of XP on the market, BTW. I'll bet you it plays out exactly like it always has. When folks buy new PC's, they will have Vista on them. Right now they often have a choice. It's only been out for a few days... Thanks for the warning. if I'm going to get a new laptop, I'd better do it soon while they are still bundling XP with them. |
#47
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
On 9 Feb, 15:03, "Take Vos" wrote:
- Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. TWJ |
#48
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
"tonewheel" wrote in message ups.com... On 9 Feb, 15:03, "Take Vos" wrote: - Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Agreed. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. Win95 and Win98 did memory-mapped I/O. Memory-mapped I/O has major performance implications for executable code. |
#49
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
Hello TWJ,
- Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. Yes, memory mapped I/O is incredibly old, but I meant it would be more useful with a 64 bit address space when working on large audio files. In 32 bit, often 1 GB is already in use by the kernel, 1GB by audio buffers and other application data structures, and you only have 2 GB left for memory mapping the audio file(s). In 64 bit you can map a large audio file in memory (think a single 6 hour, 48 channel polyphonic recording) and have enough room free for the application itself. Cheers, Take |
#50
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
tonewheel wrote:
On 9 Feb, 15:03, "Take Vos" wrote: - Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. Actually I think the early VAX/VMS and MVS/XA systems did it on less than 32 bits... -- Aaron |
#51
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
Scott Dorsey wrote:
wrote: wrote: Hello, This is sort of off-topic, but not. I'm in the market for a new computer with Vista. I can't for the life of me figure out if the Intel Core 2 Duo is a true 64 bit processor, a fake one, or nothing at all to do with 32 bit. Define "a true 64 bit processor" 64 bit datapaths? 64 bit addressing? 64 bit functional units? None of the above. It's all defined by the marketing department. If the marketing department says the Z-80 is a 64-bit processor, it is. As someone who worked as a design engineer in the CPU field for several years I have to say: You're exactly right. -- Aaron |
#52
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
Mogens V. wrote:
Scott Dorsey wrote: wrote: wrote: Hello, This is sort of off-topic, but not. I'm in the market for a new computer with Vista. I can't for the life of me figure out if the Intel Core 2 Duo is a true 64 bit processor, a fake one, or nothing at all to do with 32 bit. Define "a true 64 bit processor" 64 bit datapaths? 64 bit addressing? 64 bit functional units? None of the above. It's all defined by the marketing department. If the marketing department says the Z-80 is a 64-bit processor, it is. --scott Not true, but I see your point I'd say a processor with 64bit registers, ALU and so forth AND 64bit addressing makes it 64bit, but without the bus and MMU it's pretty much useless. I'm pretty sure no such processor exists. As far as I know every 64 bit addressing processor is wider on the internal bus and MMU/FPU, and MAY be narrower in the integer ALUs. -- Aaron |
#53
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
anahata wrote:
wrote: Define "a true 64 bit processor" 64 bit datapaths? 64 bit addressing? 64 bit functional units? What the marketing department want it to be, of corse, but... To qualify as any sort of 64 bit processor, it should support the AMD/Intel 64 bit instruction set (which is different from x86.) Well, the Intel x86-64 parts (at least the early ones) had 64 bit addressing. Datapaths (depending on instruction) from 32-128 bits wide. Functional units 32-128 bits wide. etc. -- Aaron |
#54
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
Arny Krueger wrote:
wrote in message wrote: Hello, This is sort of off-topic, but not. I'm in the market for a new computer with Vista. I can't for the life of me figure out if the Intel Core 2 Duo is a true 64 bit processor, a fake one, or nothing at all to do with 32 bit. Define "a true 64 bit processor" 64 bit datapaths? or greater. For example, 32 bit processors with 64 and 128 bit data paths are old hat. ....as are 64 bit processors with 32 bit datapaths - depending on instruction. 64 bit addressing? An absolute must. But, I'm not sure that anybody has a compelling reason to go further for address space or main memory adressing with a mainstream processor. IPV6 uses 128 bit addresses, but they are something different. 64 bit functional units? or greater. For example, 32 bit processors with 64 and 128 bit functional units are old hat. ....as are 64 bit processors with 64bit functional units... -- Aaron |
#55
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
In article ,
wrote: tonewheel wrote: On 9 Feb, 15:03, "Take Vos" wrote: - Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. Actually I think the early VAX/VMS and MVS/XA systems did it on less than 32 bits... Actually, lots of S-100 machines did it with only eight bits. With varying degrees of success and reliability. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." |
#56
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
wrote:
I'm pretty sure no such processor exists. As far as I know every 64 bit addressing processor is wider on the internal bus and MMU/FPU, and MAY be narrower in the integer ALUs. Vax 11/780 with an Floating Point Systems FPS-64 vector pipe. The CPU itself does only 32 bit loads and stores, but the vector coprocessor has full 64-bit float operations on vectors, and addresses local vector memory in 64-bit chunks or the main memory over the 32-bit Unibus. You can argue that an array processor is part of the CPU since it takes over the memory buss and is controlled by the instruction decoder of the CPU. You can argue that it isn't part of the CPU at all, too, since it has no register access and isn't part of the CPU instruction set. Which argument you makes depends on whether you work for CDC or FPS. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." |
#57
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
wrote in message ... tonewheel wrote: On 9 Feb, 15:03, "Take Vos" wrote: - Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. Actually I think the early VAX/VMS and MVS/XA systems did it on less than 32 bits... There was a 24 bit addressing limit in MVS until they tweaked the hardware and software. I remember when it seemed ludicrously high! The MVS 16 meg barrier fell first for hardware real memory, and then for application address spaces. The letters "XA" were IBM's code for going fully 32 bit. VMS has been through a lot of changes. At one time it was restricted to 24 bit addressing, if I recall correctly. Appreantly there is now a VMS with 64 bit addressing. Hey, IBM's AS/400 and System 38 systems had 128 bit addressing. |
#58
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
On 10 Feb 2007 06:33:36 -0800, "JReynolds"
wrote: Any thoughts on audio software evolving into 64 bit architectures? That would probably kill the argument that you need to go analog to mix due to summing issues. The arise of 64 bit architecture has absolutely nothing to do with the difference in sound you get from analog summing. The two are completely unrelated. Analog summing is used, and will be used into the future, because electronic components have inconsistent irregularities that color the sound. Are you saying the "analog summing" sound results from the nonlinearities in resistors or similar components? If so, then I grant you that digital mixing won't sound the same, no matter how many bits are used. Until the nonlinearities are digitally simulated. I recall reading some of the "analog summing" threads a few years back, they were interesting. While more processing word length per clock would mean we can come up processes that work on a more precise level, this will not change the fact that analog summing will give you the color of the gear you are using. BTW... Pro Tools summing is already done in 48 bit. check out As this article demonstrates, 64 bit (or even 128 bit) audio processing can be done with 32-bit proccessors as "double precision" fixed-point operation. You don't need a processor with more bits just to do adds and multiplies with more bits of precision. There's a speed penalty because each operation with each sample takes more processor instructions and cycles to do more bits, but that only means the max real-time track count is something like 215 instead of 479 (your track count may vary). http://akmedia.digidesign.com/suppor...ixer_26688.pdf But as far as killing the argument for the analog mixing bus, only time, listening, and possibly changing attitudes will tell. |
#59
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
"JReynolds" wrote in message ups.com... Analog summing is used, and will be used into the future, because electronic components have inconsistent irregularities that color the sound. It has long been possible to make analog summers that would pass a straight wire bypass test. |
#60
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
On 12 Feb, 19:29, wrote:
tonewheel wrote: On 9 Feb, 15:03, "Take Vos" wrote: - Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. Actually I think the early VAX/VMS and MVS/XA systems did it on less than 32 bits... -- Aaron You are right about MVS/XA - that was 31 bit. Plain MVS was 24 bit but I don't remember if that offered this feature - I was only a trainee programmer at IBM at that time. VAX/VMS was 32 bit from the start, though, I am 99% sure. Maybe you're thinking of the earlier DEC os's that ran on PDP's and the like? Again they are before my time. TWJ |
#61
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
On 12 Feb, 20:16, "Arny Krueger" wrote:
The MVS 16 meg barrier fell first for hardware real memory, and then for application address spaces. The letters "XA" were IBM's code for going fully 32 bit. not quite, it was *31* bit. The top bit was a status bit.(reduced from 8 status bits on MVS) I remember quite clearly linking with "amode 31, rmode 31". Addresses were stored in 32-bit registers on both systems. VMS has been through a lot of changes. At one time it was restricted to 24 bit addressing, if I recall correctly. Appreantly there is now a VMS with 64 bit addressing. Yes 64 bit VMS running on Alpha AXP came out several years ago now, but I've never heard of 24 bit VMS, unless you are referring to some *very* bespoke installation created for a special case. Even microvms on the microvax 1 was 32 bit, wasn't it? Help me out here, I'm digging very deep into a very fading memory.... TWJ |
#62
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
On 12 Feb, 18:21, "Take Vos" wrote:
Hello TWJ, - Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. Yes, memory mapped I/O is incredibly old, but I meant it would be more useful with a 64 bit address space when working on large audio files. In 32 bit, often 1 GB is already in use by the kernel, 1GB by audio buffers and other application data structures, and you only have 2 GB left for memory mapping the audio file(s). eek, how big are your audio files? In 64 bit you can map a large audio file in memory (think a single 6 hour, 48 channel polyphonic recording) and have enough room free for the application itself. oh, that big. Cheers, Take cheers, TWJ :-) |
#63
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
Arny Krueger wrote:
"JReynolds" wrote in message Analog summing is used, and will be used into the future, because electronic components have inconsistent irregularities that color the sound. It has long been possible to make analog summers that would pass a straight wire bypass test. No matter how good your summing network is, I can add enough channels to it that it won't pass the straightwire test any more. The question is how many channels that is. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." |
#64
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
tonewheel wrote:
You are right about MVS/XA - that was 31 bit. Plain MVS was 24 bit but I don't remember if that offered this feature - I was only a trainee programmer at IBM at that time. That's addressing, not data. Data was full 32 bit. VAX/VMS was 32 bit from the start, though, I am 99% sure. Maybe you're thinking of the earlier DEC os's that ran on PDP's and the like? Again they are before my time. The Vax was 32-bit data from the start (although the 11/780 had a 16-bit compatibility mode so you could run your old RSX binaries). But, it did not have full 32-bit addressing in hardware, although the instruction scheme supported it. The actual width of the address buss depended on the model you bought.... --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." |
#65
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
tonewheel wrote:
Yes 64 bit VMS running on Alpha AXP came out several years ago now, but I've never heard of 24 bit VMS, unless you are referring to some *very* bespoke installation created for a special case. Even microvms on the microvax 1 was 32 bit, wasn't it? Help me out here, I'm digging very deep into a very fading memory.... Q-bus backplanes could be configured for 18 or 22 bit addressing. Lots of folks bought old 18-bit ones and did some wire-wrapping to put their microvax cards in. BUT, the instructions still had 32-bit addresses in them, even though the hardware didn't support the full space. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." |
#66
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
"Scott Dorsey" wrote in message ... Arny Krueger wrote: "JReynolds" wrote in message Analog summing is used, and will be used into the future, because electronic components have inconsistent irregularities that color the sound. It has long been possible to make analog summers that would pass a straight wire bypass test. No matter how good your summing network is, I can add enough channels to it that it won't pass the straightwire test any more. Agreed The question is how many channels that is. Agreed. |
#67
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
On 13 Feb, 14:51, (Scott Dorsey) wrote:
tonewheel wrote: Yes 64 bit VMS running on Alpha AXP came out several years ago now, but I've never heard of 24 bit VMS, unless you are referring to some *very* bespoke installation created for a special case. Even microvms on the microvax 1 was 32 bit, wasn't it? Help me out here, I'm digging very deep into a very fading memory.... Q-bus backplanes could be configured for 18 or 22 bit addressing. Lots of folks bought old 18-bit ones and did some wire-wrapping to put their microvax cards in. BUT, the instructions still had 32-bit addresses in them, even though the hardware didn't support the full space. --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis." ah, OK it becomes clear. You're talking about the physical hardware, fair enough. I was specifically referring to 'VMS' which is the operating system. cheers, twj |
#68
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
On 13 Feb 2007 06:12:03 -0800, "tonewheel"
wrote: On 12 Feb, 18:21, "Take Vos" wrote: Hello TWJ, - Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. Yes, memory mapped I/O is incredibly old, but I meant it would be more useful with a 64 bit address space when working on large audio files. In 32 bit, often 1 GB is already in use by the kernel, 1GB by audio buffers and other application data structures, and you only have 2 GB left for memory mapping the audio file(s). eek, how big are your audio files? In 64 bit you can map a large audio file in memory (think a single 6 hour, 48 channel polyphonic recording) and have enough room free for the application itself. oh, that big. Now that you mention it, I have to wonder - just how much RAM is that, and how much does it costs? Quick calculations: 44.1k/24bits is 132,300 bytes/second, *3600*6 hours 2857680000, * 48 tracks = 137,168,640,000 - let's call it 137 gigabytes. Let's say 2G is $120, 137G is $8,220. That's not outrageous for an upscale studio, but RAM is a depreciating investment. It better save a lot of time vs. hard disk, and hope no one hits the power plug near the end of a session. A good program would have a background task writing the files to disk while not recording. Cheers, Take cheers, TWJ :-) |
#69
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
"Ben Bradley" wrote in message ... On 13 Feb 2007 06:12:03 -0800, "tonewheel" wrote: On 12 Feb, 18:21, "Take Vos" wrote: Hello TWJ, - Able to do memory mapped I/O, this allows a programmer to use an audio file as if it was normal memory (64 bit address space allows us to do this). This is not a new feature of 64 bit architectures. Windows XP does it. Windows 2000 does it. Windows NT 3.1 did it. DEC VAX/VMS did it. IBM mainframes running MVS/XA did it, all on 32 bits. Yes, memory mapped I/O is incredibly old, but I meant it would be more useful with a 64 bit address space when working on large audio files. In 32 bit, often 1 GB is already in use by the kernel, 1GB by audio buffers and other application data structures, and you only have 2 GB left for memory mapping the audio file(s). eek, how big are your audio files? In 64 bit you can map a large audio file in memory (think a single 6 hour, 48 channel polyphonic recording) and have enough room free for the application itself. oh, that big. Now that you mention it, I have to wonder - just how much RAM is that, and how much does it costs? Quick calculations: 44.1k/24bits is 132,300 bytes/second, *3600*6 hours 2857680000, * 48 tracks = 137,168,640,000 - let's call it 137 gigabytes. Let's say 2G is $120, 137G is $8,220. That's not outrageous for an upscale studio, but RAM is a depreciating investment. It better save a lot of time vs. hard disk, and hope no one hits the power plug near the end of a session. A good program would have a background task writing the files to disk while not recording. That example illustrates one of the niceties of memory-mapped I/O. With memory-mapped I/O you don't load the whole file into RAM, just the parts you reference. Changes to memory can be queued back out to the disk, so it would only be running a few seconds worth of edits behind the file image in RAM. However, in the real world, you wouldn't ever alter the file. You'd do non-destructive editing which amounts to queuing just the edit commands out to disk. Those are almost always vanishingly small. And, since its a more-or-less one-shot affair, the only time you'd touch the whole file would be rendering, which doesn't need to be loaded to RAM in its entirety. Note that in the cosmic scheme of things, audio is small potatoes compared to video. Video editing is also done non-destructively, but you need partially-rendered files to provide an effective user interface. It turns out that storage of partially-rendered or lower-resolution rendered video files for the UI, can get iffy unless you have a large fast memory buffer at your disposal. I think the first people to really benefit from 4 GB RAM will be people doing video, not audio. |
#71
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
Arny Krueger wrote:
"JReynolds" wrote in message Analog summing is used, and will be used into the future, because electronic components have inconsistent irregularities that color the sound. It has long been possible to make analog summers that would pass a straight wire bypass test. No matter how good your summing network is, I can add enough channels to it that it won't pass the straightwire test any more. Agreed The question is how many channels that is. Agreed. Alright, I agree with what all of you are saying about mixers being able to be somewhat transparent. That really wasn't my point. The point here is, that even if we could mix 1,000,000 channels of audio in the box in a n-bit addressed space with absolute precision, I would rather mix 96 tracks on a decent analog desk that introduces some coloring, because it sounds good. I'm not behind the times either, 24 years old, pro tools expert, and have studied this stuff in depth, and truly believe that even if digital is perfect, it's not the best. I will admit that analog is cost prohibitive for some projects, and that you can make good music in the box, but I will always prefer an analog desk to sum through. |
#72
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
"JReynolds" wrote in message oups.com... Arny Krueger wrote: "JReynolds" wrote in message Analog summing is used, and will be used into the future, because electronic components have inconsistent irregularities that color the sound. It has long been possible to make analog summers that would pass a straight wire bypass test. No matter how good your summing network is, I can add enough channels to it that it won't pass the straightwire test any more. Agreed The question is how many channels that is. Agreed. Alright, I agree with what all of you are saying about mixers being able to be somewhat transparent. That really wasn't my point. The point here is, that even if we could mix 1,000,000 channels of audio in the box in a n-bit addressed space with absolute precision, I would rather mix 96 tracks on a decent analog desk that introduces some coloring, because it sounds good. You forgot the required qualifier: "to me." I'm not behind the times either, 24 years old, pro tools expert, and have studied this stuff in depth, and truly believe that even if digital is perfect, it's not the best. I guess your idea of best and my idea of best are two different things. BTW I'm 60, and edit on analog desks, digital desks, and on a DAW. No contest - I'll take the DAW. I will admit that analog is cost prohibitive for some projects, and that you can make good music in the box, but I will always prefer an analog desk to sum through. Enjoy! At least as long as analog desks are still available. Think they won't ever go away? Look where analog tape is headed. |
#73
Posted to rec.audio.pro
|
|||
|
|||
64 bit processing, etc.
In article , Romeo
Rondeau wrote: Richard Crowley wrote: wrote ... "Richard Crowley" wrote: Most knowledgeable people in my acquaintance are avoiding it like the plague. well, that's what is out there and time marches on. i'm sure it will settle in. I propose to migrate to Linux (or Mac?) by the time WinXP support ends. Good luck with that :-) Let us all know how that works for ya :-) Seesm to be working very, very well for more and more people, thanks for asking. |
Reply |
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
Multi-Band Dynamic Processing? | Pro Audio | |||
Mixing, Any additional suggestions? | Pro Audio | |||
Mixing, Any additional suggestions? | Pro Audio | |||
Some Mixing Techniques | Pro Audio | |||
Audio processing techniques for Amateur Radio | Pro Audio |